Moving Machine Code Around

Lastly, there is another elephant in the room. It takes in API calls, but what does it send out to the GPUs? It can't send the hardware itself API calls, cause it doesn't know what to do with these. It must send machine code generated by the graphics driver. So all the difficult analysis of API calls and grouping of tasks and load balancing has to happen in software in the driver.

We really don't have any idea how this would work in the real world, but it seems like they'd have to send batches of either tagged or timed API calls to the driver and tell their chip which GPU is going to get the set. The silicon would then send the newly generated machine code down the pipe to the appropriate driver until it was told otherwise or something. And of course, the chip would also request and composite the pixel data and send it back to the display device.

But that would have to have a CPU load right? We really want and need more details before we can truly understand what is happening in this software and hardware combination. It is absolutely certain though, that the only practical way to do this is for the hardware itself to be switching machine code rather than API calls. And since the hardware also has almost no memory, it can't be doing analysis either.

The progression has to be: game -> Hydra software -> graphics card driver -> Hydra 100 hardware -> multiple graphics cards. Managing this seems like it would be a bit cumbersome, and it seems like they'd have to either set register on the hardware to tell it which direction to send the next set of commands or they would have to embed something in the commands being sent to the GPUs that would help the hardware figure out where to send the data. Or maybe it can trick the graphics driver into thinking the destination of the one graphics card it is rendering to changes multiple times in a frame. We don't know, but we really want to.

We do also get the added benefit that it offers a dedicated set of two x16 PCIe lanes to graphics hardware. This means that it can be very efficient in handling the data movement between the two and it can do full up and downstream communication with both at the same time. Since it doesn't have a memory, to composite the frame, it needs to do two reads and then a write while its doing the next two reads. It's gotta keep things moving. Which it can do very quickly and efficiently with all the PCIe lanes available to it and both graphics cards.

Also note that this really does dedicate all the graphics resources available (memory, geometry, pixel, etc.) to the processing of the scene. Each card even sees full PCIe x16 bandwidth (when the Hydra 100 is talking to it anyway), and the switching back and forth can actually act as another way to hide latency (one card continues to process data while the other is receiving and then back again).

What Does This Thing Actually Do? Barriers to Entry and Final Words
Comments Locked

57 Comments

View All Comments

  • TonyB - Friday, August 22, 2008 - link

    but can it play crysis?
  • Googer - Sunday, August 24, 2008 - link

    Please let that 3 year old former inside engadget joke die. It's starting to get old, send it to the joke graveyard; it's past it's prime.
  • TonyB - Sunday, August 24, 2008 - link

    F YOU, two of my friends died trying to run Crysis.
  • UnlimitedInternets36 - Saturday, August 23, 2008 - link

    I got one better Crysis:Warhead all setting Maxed @ 120fps @ 2560x1600 FTW!
  • InuYasha - Saturday, August 23, 2008 - link

    but does it blend?
  • PrinceGaz - Saturday, August 23, 2008 - link

    Yes, it blends.
  • Lightnix - Friday, August 22, 2008 - link

    At 40-60FPS at 1920x1080.

Log in

Don't have an account? Sign up now