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

  • pool1892 - Saturday, August 23, 2008 - link

    i think it is possible to build a solution like this, but this thing has a lot to do, on-the-fly qos and scheduling and optimizing and so on. with data in the gigabits/s. sounds like a heavy duty cisco switch.
    i can imagine this working, but the chip will be a heavyweight - and it will be power consuming and expensive.
    and it only has potential in the marketplace if the price premium for a mainboard with hydra beats the faster graphics you can buy for this premium. that will be tough.
    larrabee is as usual a totally different animal, hydra could very well be a software feature for it (esp. with qpi in gen 2)
  • pool1892 - Saturday, August 23, 2008 - link

    gotta correct myself - after a little diggin: the hydra is a tensilica diamond based programmable risc controller with custom logic around it running at 225mhz. it uses about 5watt. this is a tiny chip, it might be affordable. (but how is liquid going to earn money? and: they have to optimize their driver and the the programmable parts of the chip for different rendering techniques in different games - who is paying for that?)
  • Goty - Saturday, August 23, 2008 - link

    I don't see this as a bad thing for GPU makers, personally. Since ATI no longer has anything like the "master card" for crossfire, as long as they're selling two GPUs to people running multi-card systems, they're not losing out. Sure, they may lose a bit of money on the mainboard side of things since consumers will be able to use any chipset they want with this technology, but the margin on the GPU silicon is probably higher than that on the chipset side, anyhow.
  • yyrkoon - Saturday, August 23, 2008 - link

    "Lucid also makes what seems like a ridiculous claim. They say that in some cases they could see higher than linear scaling. The reason they claim this should be possible is that the CPU will be offloaded by their hardware and doesn't need to worry about as much so that overall system performance will go up. We sort of doubt this, and hearing such claims makes us nervous. They did state that this was not the norm, but rather the exception. If it happens at all it would have to be the exception, but it still seems way too out there for me to buy it."

    Come now guys . . . if a CPU dependent game such as World in Conflict could offload the CPU 10%, would it not make sense that the CPU could do an additional 10%, thus offering more performance ? I am not saying I believe this is possible myself, but taking Lucid at their word, this just makes sense to me.

    "The demo we saw behind closed doors with Lucid did show a video playing on one 9800 GT while the combination of it and one other 9800 GT worked together to run Crysis DX9 with the highest possible settings at 40-60 fps (in game) with a resolution of 1920x1200. Since I've not tested Crysis DX9 mode on 9800 GT I have no idea how good this is, but it at least sounds nice."

    Just going from this review, and assuming you meant a 9800GTX/GTX+: 47-41 FPS average with 16x AF/ 0x AA.

    "An explanation for this is the fact that the Hydra software can keep requesting and queuing up tasks beyond what graphics cards could do, so that the CPU is able to keep going and send more graphics API calls than it would normally. This seems like it would introduce more lag to us, but they assured us that the opposite is true. If the Hydra engine speeds things up over all, that's great. But it certainly takes some time to do its processing and we'd love to know what it is."

    Wait a minute . . . did you not just mention on a previous page somewhere that the number of cards implemented were limited due to latency implications ? . . .

    "Of course, while it seems like an all or nothing situation that would serve no purpose but to destroy the experience of end users, NVIDIA and ATI have lots of resources to work on this sort of "problem" and I'm sure they'll try their best to come up with something. Maybe one day they'll wake up and realize (especially if one starts to dominate over the other other) that Microsoft and Intel got slammed with antitrust suits for very similar practices."

    OR, they could just purchase the company outright, which seems to me what Lucid may have been aiming for to begin with. After that the buying company could do whatever they please, such as kill the project. or completely decimate the opposite camp *if* the hardware truely does what it claims. At least where gaming is concerned . . . and we all know that IGP's make up for a very large portion of home systems.

    Now what I have to say is that this totally smells like the gaming Physics "fiasco". Buy the hardware now, and the hardware is dead in a year or two. Sure a few games implemented features that leveraged these cards, but do you think developers are going to write code for hardware that has gone way of the dodo ? Probably not.

    The idea is interesting yes, but I will believe it when I see the hardware on sale at the egg . . .
  • DerekWilson - Saturday, August 23, 2008 - link

    it was not 9800 gtx cards -- they were GT cards ... lower performance, single slot.

    also game devs wont have to optimize for it, so there is no problem with them ignoring the situation -- if it works it works
  • yyrkoon - Saturday, August 23, 2008 - link

    9800GTX/GTX+ benchmarks ---> http://www.guru3d.com/article/geforce-9800-gtx-512...">http://www.guru3d.com/article/geforce-9800-gtx-512...
  • JarredWalton - Saturday, August 23, 2008 - link

    http://www.newegg.com/Product/ProductList.aspx?Sub...">9800 GT FTW!

    Basically, performance is closer (identical) to that of 8800 GT. You know, this goes along with the whole "let's rename 8800 GT and 8800 GTS 512MB to 9800 parts, because after all G92 is GeForce 9 hardware." Why the 8800 GT was ever launched with that name remains something of a mystery... well, except that performance was about the same as 8800 GTX.
  • yyrkoon - Saturday, August 23, 2008 - link

    So basically just a 8800GTS with fewer ROPs ? nVidias naming convention definitely leaves a lot to be desired : /
  • Lakku - Saturday, August 23, 2008 - link

    Who are nVidia and AMD/ATi supposed to strong arm in this situation? I don't think they would be in any kind of position to strong arm ANYONE, if this works as advertised. Why? Because they'd have to strong arm Intel (apparently a very big investor into this tech and company) to do so, and that's just not going to happen. Intel only need put this on their own Intel branded gaming or consumer boards, and/or Intel can strong arm Asus and the others into putting this chip onto their motherboards if they want Intel chipsets, still by far the best selling PC chipsets. If this works as advertised, it's probably Intel who will be the biggest winner... and maybe us end users in some way, provided Intel and this company don't charge outrageous prices for this tech.
  • djc208 - Monday, August 25, 2008 - link

    Easy, like the author stated nVidia just writes in some code that looks for the Hydra software or hardware and shuts down parts of the driver. Therefore you can't use their hardware on a system running or equiped with Hydra. If it was a unified front then Intel will have only Larabee to use with this for gaming.

    Problem I see is that it could upset the market if the boycot isn't universal. If ATI let their hardware work with this and nVidia didn't then it could seriously hurt nVidia, as there would be even less reason to go with their chipsets or graphics cards at the high end, where nVidia likes to play.

    More likely is that ATI/nVidia will quickly push out something along the same lines and now we'll have three competing solutions, and then ATI and nVidia will lock out Hydra since they offer an alternative, just like now.

    All this assumes that Hydra works the way it's said to, if not then all bets are off.

Log in

Don't have an account? Sign up now