More Details About Lucid's Hydra Revealed - Object Based Rendering, RISC, 4w TDP

[AuDioFreaK39]

More details about Lucidlogix Hydra revealed

http://img23.imageshack.us/img23/7682/lucidlogovz8.jpg

Uses object based rendering


Last night we had an interesting chat with Nir Cohen who is the senior product marketing manager at Lucidlogix, as he was vistiing Taipei to talk to some potential customers and he gave us a few more details about the Hydra chip and what it can do.

Although he wouldn't go into too much detail, we did find out some new and interesting aspects on what Hydra can do. First of all, the implementation done by ELSA Japan is not the same setup as that which will be found on consumer motherboards, as the Hydra chip can function in two different modes. To make a replacement for SLI or CrossFireX, the Hydra chip has to be configured to run in graphics performance mode, but ELSA's implementation doesn't work like this, as ELSA is using the chip as a PCI Express controller with some additional functionality.

The Hydra chips have a built in RISC processor which makes it a much more flexible solution than your average PCI Express controller. ELSA's implementation is said to be cheaper than using a Tesla server with four cards from Nvidia, but we'll have to wait and see what ELSA's official pricing will be until we know this for sure. In non graphics performance mode up to four cards can be used, but in graphics performance mode you're limited to two cards at the moment, but Lucidlogix is working on allowing for up to four cards.

We also found out that the interface on the ELSA solution that connects to a workstation or server is using an external PCI Express x1 connection, although as this is only used for transferring data to be computed and already computed data between the CPU and the Tesla cards, this is meant to be more than enough for the intended usage scenarios. We're not sure how this works with other solutions, such as using Quadro cards.

Another interesting aspect is that its possible to cascade multiple Hydra chips, although at the moment this is limited to two chips, but this would allow for more cards to be used. This could at least in theory allow for four GPU graphics cards, but Nir suggested that in the future up to 8 GPU's per Hydra chip could be possible, in theory at least.

For those that are worried that this will be another nForce 200 chip, there's no need to worry as Nir assured us that the Hydra has a TDP of a mere 4W and as such it shouldn't even need a heatsink, although we expect motherboard makers to add one just in case.

The reason why Hydra scales so well is because its the Hydra chip that controls the rendering and Lucidlogix is doing it quite different than the way AMD and Nvidia are doing things. Using multiple graphics cards have so far meant alternate frame rendering, split screen rendering or tile based rendering. Lucidlogix on the other hand is going for object based rendering which is an entirely new approach which means that each GPU get allocated parts of an object of the scene that's being rendered and then the Hydra chip pieces together the small parts into the final frame which is then displayed on the screen.

The proof is still in the pudding so to say, as Lucidlogix has yet to show a running demo of its Hydra chip, but with a bit of luck this should happen during CeBIT which kicks off early next month. So far we're only hearing whispers about potential consumer partners, but again, there's a chance that more details will be revealed during CeBIT.

Source (http://www.fudzilla.com/index.php?option=com_content&task=view&id=12128&Itemid=1)

[XSAlliN]

If CUDA is the reason, then it will work same as FASTRA.

[Mr Roboto]

I want to believe the Lucid is real and can perform similar to what they claim. However, this is something that's revolutionary as far as the gamer\enthusiast goes yet we barely hear anything about it not to mention a working demo. Why aren't they shouting from the rooftops showing off this technology even if they have yet to make any deal with motherboard manufacturers? If it can perform half as good as what they claim they won't have to worry about selling it, motherboard manufacturers will be lining up to be the first to feature the Lucid Hydra. They need to be hyping this up and showing some benchmarks to back up their claims.

If they did this any motherboard that's released with this chip would be back ordered for months! Plus they have Intel capital behind them. It just doesn't make a whole lot of sense to me. I patiently await some benchmarks, until then label me a skeptic.

[dirtypop]

Can anyone explain in basic terms why object-based rendering should be faster than every-other frame rendering for multiple cards? It doesn't make sense to me.

[clonez]

i dont think its faster most of the time (>2 gpus should be managed better, however)

its simply a very good way to split workloads on gpus with different perfomance and vendors (and microstuttering shouldnt be a big issue, if its done right and hydra splits the workloads fast enough, no matter how many objects are displayed)

[Aberration]

Can anyone explain in basic terms why object-based rendering should be faster than every-other frame rendering for multiple cards? It doesn't make sense to me.

Because this allows asymmetric cards with regard to ability.

If you had a 280 and a 9600 and did AFR you can obviously see there would be issues.

But with object based the 9600 could a few objects in the frame while the 280 took the bigger objects.

Then you take into account differing RAM per card and what each one would be able to handle.

[trinibwoy]

Object based rendering huh? I'd love to see that work with rendering something even as simple as a cubemap or with Carmack's proposed voxel based terrain renderer. This also renders a Z-only passes a moot point since that requires running all objects through the transform and rasterization stages. Hogwash!

If it was easy to just parcel out individual objects to be rendered to different GPUs AMD and Nvidia would have done it ages ago. How can Lucid do this so easily when they have a lot less information than the graphics guys do about their own hardware?

In terms of RAM, there's no win there. How would Hydra know which objects are more expensive (like which ones are going to be tessellated, or which have the most demanding shaders) or which textures need to go to which card? Some algorithms also rely on maintaining the drawing order of primitives. They're making it sound like you can just split up the objects that belong to the scene and delegate them to different cards without worrying about any dependencies. Sounds like a pile of bull until they offer up some proof that it works.

[geo]

^^ maybe thats why there isn't public demo yet?.. one would have thought, ATI with their X2 cards woul have come up with this tech

[RaZz!]

i've read about their plans to use object based rendering earlier, but i still can't imagine how that works. especially if different cards are used where one card is considerably faster than the other. another thing is: what if one card is heavily overclocked and would produce artifacts on a regular frame based rendering - what would be the effect on object based rendering?

it's definately a nice approach though, but i think if lucid really succeeds with this technique, ati and nvidia will do the same. it's just that ati and nvidia don't feel the need for something like that as the customers are paying for their crap sli and crossfire anyways. so why bother doing so when it's not "necessary" for them? but that's just my pov.

[EniGmA1987]

Why would anyone run a card for gaming or whatever that produces artifacts? That is when you turn your OC down...

[trinibwoy]

^^ maybe thats why there isn't public demo yet?.. one would have thought, ATI with their X2 cards woul have come up with this tech

Yep, I'm still trying to understand why people are falling for Lucid's so-far-empty promises and a few slides. SLI and CF aren't perfect but there are very good reasons for that. And those reasons don't go away when somebody puts some pretty pictures up in powerpoint.

[RaZz!]

Why would anyone run a card for gaming or whatever that produces artifacts? That is when you turn your OC down...

it's not about whether i do game like that or not (however, i never mentioned gaming anyways ;)), it was more of food for thought on what WOULD happen.

[BababooeyHTJ]

Object based rendering, sounds like a can of worms driverwise. I really cant see a company without a working product being able to write solid drivers when Nvidia and ATI which are obviously well established and very weathy have driver issues of their own.

Pics/benchmarks or it didn't happen.

[ToTTenTranz]

Object based rendering huh? I'd love to see that work with rendering something even as simple as a cubemap or with Carmack's proposed voxel based terrain renderer. This also renders a Z-only passes a moot point since that requires running all objects through the transform and rasterization stages. Hogwash!
Indeed, there was a time in the videogame industry to which we could call the "Carmack Age". That age is long gone, now. Carmack is more interested in rockets now, so let him be.
Between something Carmack proposed and something else that would allow for near-perfect multi-GPU scaling, guess which one I'd choose?


If it was easy to just parcel out individual objects to be rendered to different GPUs AMD and Nvidia would have done it ages ago. How can Lucid do this so easily when they have a lot less information than the graphics guys do about their own hardware?
And who said it was easy? Or are you assuming it must be easy because a new company came up with the concept? Assuming that all the great minds must be already in Intel, nVidia and AMD? I find that hard to believe.


In terms of RAM, there's no win there. How would Hydra know which objects are more expensive (like which ones are going to be tessellated, or which have the most demanding shaders) or which textures need to go to which card?
Some algorithms also rely on maintaining the drawing order of primitives. They're making it sound like you can just split up the objects that belong to the scene and delegate them to different cards without worrying about any dependencies.
Wait and see. Maybe they can do it, maybe not.



Sounds like a pile of bull until they offer up some proof that it works.
Do you think Intel would invest in something that "sounds like a pile of bull"?



EDIT:
To all those "superskeptics" around, here's an image from a 6 month old article (http://news.cnet.com/8301-17938_105-10021005-1.html):

http://img3.imageshack.us/img3/6862/picture006540x405lr0.jpg (http://imageshack.us)

It is object based. There are even videos showing it.

[Xenogias]

I imagine this will have a lot of caveats and limitations when it finally emerges. Like every other revolutionary, "why didn't I think of that before?", tech.

[trinibwoy]

Between something Carmack proposed and something else that would allow for near-perfect multi-GPU scaling, guess which one I'd choose?

Carmack's proposal is rooted in existing technologies that work and are based on reality (The terrain design process in Crysis is voxel based along with many medical imaging applications). You would take vaporware over the musings of one of the 3D graphics world's most prominent pioneers?


And who said it was easy? Or are you assuming it must be easy because a new company came up with the concept? Assuming that all the great minds must be already in Intel, nVidia and AMD? I find that hard to believe.

It doesn't have anything to do with being smarter than Intel, nVidia and AMD. It's about understanding how graphics rendering works and why Lucid's claims are ludicrous on the surface. All of the fancy algorithms they claim to have will be running on the CPU. The Hydra chip is nothing but a fancy PCIe bridge like N200.


Do you think Intel would invest in something that "sounds like a pile of bull"?

Who knows what Intel's motivation is here. Hydra supports good old SFR and AFR as well. They could simply want a solution that isn't tied to any IHV's chipset or technology and free themselves of a dependency there.


To all those "superskeptics" around, here's an image from a 6 month old article

Yes, we've all seen the PCPer article. So a missing piece of the floor in UT is proof now? They need to do a lot better than that to validate their claims. The reason we're skeptical is because we have some basic understanding of how this stuff works.

[Solus Corvus]

So a missing piece of the floor in UT is proof now? They need to do a lot better than that to validate their claims.
It's a lot more then just a missing piece of the floor. Most of the objects missing in one scene are present in the other. Some of the objects are rendered in both scenes (the gun, for example), probably as a way to avoid the dependency conflicts you mentioned earlier.

[Xel'Naga]

I can't believe people have doubts about Lucid Hydra.
Do you realize who is behind this? George T. Haber who built the UltraSPARC FPU, Moshe Steiner the leader of the team that built the first MMX unit for Intel. And so on...
The people behind Lucid Hydra are the dream team of digital circuits, people who could get a seven figure salary at any company they wanted to and they all put there money and next years of their life in Lucid.

[jmke]

seeing is believing as with most things in this industry ;)

[NapalmV5]

how about a hydra for raid cards: areca arc1231 sli/tri/quad :)

[russian boy]

IMO too much hype.

I can't believe people have doubts about Lucid Hydra.
Do you realize who is behind this? George T. Haber who built the UltraSPARC FPU, Moshe Steiner the leader of the team that built the first MMX unit for Intel. And so on...
The people behind Lucid Hydra are the dream team of digital circuits, people who could get a seven figure salary at any company they wanted to and they all put there money and next years of their life in Lucid.Are we seeing birth of first ever Lucid fanboy?

[trinibwoy]

It's a lot more then just a missing piece of the floor. Most of the objects missing in one scene are present in the other. Some of the objects are rendered in both scenes (the gun, for example), probably as a way to avoid the dependency conflicts you mentioned earlier.

Yeah there are a lot of fallbacks including synchronization points, reverting to SFR or AFR etc. But that's exactly the point, all of these contingencies lower performance far below the holy grail of linear scaling.

AFR is the simplest approach and the easiest to get close to linear speedups. However, we've seen how hard it's been for Nvidia and AMD to consistently get near that with most applications. For AFR to work perfectly there has to be no inter-frame dependencies or synchronization points. Both will go up dramatically with a so-called object based approach.

Given that, we are now to believe that an intra-frame approach with vastly greater and more complex dependencies and synchronization points will achieve even better scaling than AFR? Even if you have no knowledge of graphics rendering your logical conclusion should be obvious.

The point is that Lucid will only scale linearly in applications with very simple rendering engines. But then AFR will too so what's the point? People seem to think Lucid is offering some magic bullet that removes the problems plaguing existing methods. But all it does is make all the problems even harder to solve.

[grimREEFER]

breakthrough for supercomputing, but i predict nothing for the gamers will come out of this unfortunately

[Manicdan]

this is just the next step in the design of SLI/Xfire. to obtain every bit of performance out of the cards, more complex designs are needed. i however am ashamed that neither AMD or NVidia came up with this first. an X2 card would be perfect to squeeze in a high bandwidth chip thats built to run off one set of drivers and do it right for their own brand. i do remember rumors of the 4870x2 using shared memory, but even they backed down for the same old simple solution.

im still using just one card in my pc, cause i know that when i plan to upgrade to a new one, the old one will not be compatible. i still feel very strongly that both companies really need to look into a universal solution (for their own chips) to keep people upgrading.

also isnt it possible that Lucid can offer better than linear performance? if im bottlenecked when it comes to running 2560x1600 4xAA, then wouldnt i see a huge increase in fps (like more than double, but probably less than triple) if only 60% of the RAM was needed per card? i know my example may not make much sense, but if a card is trying to pack too much into its ram, then having to work with a little more than half the textures may really help it more than AFR ever could?

[LordEC911]

this is just the next step in the design of SLI/Xfire. to obtain every bit of performance out of the cards, more complex designs are needed. i however am ashamed that neither AMD or NVidia came up with this first. an X2 card would be perfect to squeeze in a high bandwidth chip thats built to run off one set of drivers and do it right for their own brand. i do remember rumors of the 4870x2 using shared memory, but even they backed down for the same old simple solution.
Who is to say this is the right step that was needed to take in the industry... As mentioned many times already, this has yet to be proven/shown.


also isnt it possible that Lucid can offer better than linear performance? if im bottlenecked when it comes to running 2560x1600 4xAA, then wouldnt i see a huge increase in fps (like more than double, but probably less than triple) if only 60% of the RAM was needed per card? i know my example may not make much sense, but if a card is trying to pack too much into its ram, then having to work with a little more than half the textures may really help it more than AFR ever could?
Better than linear is possible, even taking into account margin of error, though only in very rare situations.


breakthrough for supercomputing, but i predict nothing for the gamers will come out of this unfortunately
Why?
Supercomputing doesn't really need this, it already scales linearly in most situations.


It doesn't have anything to do with being smarter than Intel, nVidia and AMD. It's about understanding how graphics rendering works and why Lucid's claims are ludicrous on the surface. All of the fancy algorithms they claim to have will be running on the CPU. The Hydra chip is nothing but a fancy PCIe bridge like N200.
Hmmm... I thought there was a basic processor, RISC, built into their chips that did all the load balancing?

[ToTTenTranz]

also isnt it possible that Lucid can offer better than linear performance? if im bottlenecked when it comes to running 2560x1600 4xAA, then wouldnt i see a huge increase in fps (like more than double, but probably less than triple) if only 60% of the RAM was needed per card? i know my example may not make much sense, but if a card is trying to pack too much into its ram, then having to work with a little more than half the textures may really help it more than AFR ever could?

Yes, in this case. Since the Lucid engine loads different data for each gpu, and if memory was a bottleneck, it's possible to get more than 100% increase.

[saaya]

performance is one thing, quality of gameplay is another...
when you use quadsli or quadxfire your gpus are rendering 8 frames or so ahead... so any input to the game that isnt scripted, like movements of the main character, shooting, jumping etc, will be delayed by those 8 frames, or, if they get flushed, causes a lag and drop in frames since for a short time there are no new frames to display.

at 160fps 8 frames mean 5% of a second or 0.05s or 50ms
at 80fps 8 frames mean 10% of a second or 0.1s or 100ms
at 40fps 8 frames mean 20% of a second or 0.2s or 200ms

aks anybody whos playing a lot if they can see and feel if their ping jumps 100ms higher than normal or even more...
im pretty sure even a non casual gamer will feel and see the difference.

thats all theory, and i dont know THAT much about this tech, so if im wrong let me know...
but thats a quality thing that hydra might bring over sli and xfire which sem to rely almost entirely on afr.

another thing is micro stuttering which is caused by frametime problems. one frame will be harder to work on that the next, so the gpus will not fire frames at an even rate but might overlap each other which means that for some times both gpus fire their frames at almost the same time, which means you do see double the fps, but actually its basicaly the same as showing each frame twice and the game is stuttering and doesnt feel fluid even though the fps are high.

again, hydra is supposed to solve this since they split each frame so the gpus cant get out of sync and the frametime should be pretty much like what it would be if one gpu was working on the scene.

[XSAlliN]

performance is one thing, quality of gameplay is another...
when you use quadsli or quadxfire your gpus are rendering 8 frames or so ahead... so any input to the game that isnt scripted, like movements of the main character, shooting, jumping etc, will be delayed by those 8 frames, or, if they get flushed, causes a lag and drop in frames since for a short time there are no new frames to display.

at 160fps 8 frames mean 5% of a second or 0.05s or 50ms
at 80fps 8 frames mean 10% of a second or 0.1s or 100ms
at 40fps 8 frames mean 20% of a second or 0.2s or 200ms

aks anybody whos playing a lot if they can see and feel if their ping jumps 100ms higher than normal or even more...
im pretty sure even a non casual gamer will feel and see the difference.

thats all theory, and i dont know THAT much about this tech, so if im wrong let me know...
but thats a quality thing that hydra might bring over sli and xfire which sem to rely almost entirely on afr.

another thing is micro stuttering which is caused by frametime problems. one frame will be harder to work on that the next, so the gpus will not fire frames at an even rate but might overlap each other which means that for some times both gpus fire their frames at almost the same time, which means you do see double the fps, but actually its basicaly the same as showing each frame twice and the game is stuttering and doesnt feel fluid even though the fps are high.

again, hydra is supposed to solve this since they split each frame so the gpus cant get out of sync and the frametime should be pretty much like what it would be if one gpu was working on the scene.

Good post. :up:

[STEvil]

I dont understand why people are ragging on lucid.

There's no point in telling us or them that their method is bad or wont work or that they are the next bit boys in multiple paragraphs and posts, in fact doing anything more than that is really fanboy/trolling and to be quite frank i'm getting a bit tired of it.

[Aberration]

Dont worry about it. There is always going to be the armchair guy that thinks he knows better.

No EE degree. No software degree. But somehow he 'knows' that it wont work, or that it will suck.

[trinibwoy]

It's one thing to analyze a process and understand the potential for it to work. It's a whole other story to just swallow promises from some random company without even trying to figure out for yourself whether what they're touting is even feasible. Notice that nobody actually responded to skepticism about certain algorithms being accelerated by this thing. There's a reason for that.

And where did you get that crystal ball that tells you about people's academic and professional background? Maybe there are more CS and EE guys running around than you think ;)

[trinibwoy]

Hmmm... I thought there was a basic processor, RISC, built into their chips that did all the load balancing?

Yeah that's what I thought as well at first. But if you think about it, Lucid can't communicate directly with the graphics hardware and it has to go through Nvidia's and AMD's drivers. Now those are running on the CPU and so are all of Lucid's dependency analysis and load-balancing algorithms. The chip just seems to be a PCIe hub that supposedly helps with compositing the final image. How it retrieves those intermediate buffers from the hardware without assistance of the graphics driver is a mystery.

But take a look at something simple like AMD's CFAA. The final AA resolve happens in the shader core. Obviously running the resolve on partial images before compositing will produce incorrect results. So Lucid would have to find a way to access all the partial unresolved sample buffers, pass them all to the compositing engine, then pass the composed multi-sampled buffer back to one of the cards and ask it to resolve it before displaying. All without help from AMD's graphics driver. And we shouldn't be skeptical?

[Shintai]

Anyone remember BitBoys? :p:

[STEvil]

The Hydra chips have a built in RISC processor..

taken from the first post in this thread...

[LordEC911]

taken from the first post in this thread...

Yes... thank you...
Where does it say what tasks it actually does? That is what we were discussing.
I'm going to have to go re-read the AnandTech articles, though most of the info seemed to just be speculation.

Edit- so re-reading this (http://www.anandtech.com/video/showdoc.aspx?i=3385&p=4) more closely, it looks like you are right trinibwoy.

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.

[Solus Corvus]

And we shouldn't be skeptical?

Of course we should be skeptical. They are making some big claims and we should use what we know here and now to analyze those claims. But being skeptical isn't mutually exclusive with hoping they can make their claims come to fruition. I am personally interested in seeing how well this works or doesn't work. I would definitely opt for a multi-GPU rendering method that has slightly reduced absolute FPS in return for smoother rendering and faster response times. But recognizing those as potential strengths of this technology doesn't mean dismissing that there may be potential drawbacks such as less then perfect scaling and serious questions about how it will render certain scenes/effects.

But you are correct that we should be skeptical by default when companies are making big claims. Even if the technology is viable there are tons of reasons why it may never come to market or come to market as a sub-par product. This is true no matter the past performance, age, or reputation of the company. We should be just as skeptical of this as we should be of Intel's Larrabee or AMD's Buldozer, etc. But that doesn't mean that we can't also hope that these technologies end up being successful.

[LordEC911]

Of course we should be skeptical. They are making some big claims and we should use what we know here and now to analyze those claims. But being skeptical isn't mutually exclusive with hoping they can make their claims come to fruition. I am personally interested in seeing how well this works or doesn't work. I would definitely opt for a multi-GPU rendering method that has slightly reduced absolute FPS in return for smoother rendering and faster response times. But recognizing those as potential strengths of this technology doesn't mean dismissing that there may be potential drawbacks such as less then perfect scaling and serious questions about how it will render certain scenes/effects.

But you are correct that we should be skeptical by default when companies are making big claims. Even if the technology is viable there are tons of reasons why it may never come to market or come to market as a sub-par product. This is true no matter the past performance, age, or reputation of the company. We should be just as skeptical of this as we should be of Intel's Larrabee or AMD's Buldozer, etc. But that doesn't mean that we can't also hope that these technologies end up being successful.

I think we are all hoping the same thing, that their claims are realistic and we can come to those conclusions in the near future.
The problem is, they talked to a part of our community that should have our trust, and back-tracked on their word...

That causes more second thoughts than any questions on their actual ability to validate their claims.

[STEvil]

Yes... thank you...
Where does it say what tasks it actually does? That is what we were discussing.
I'm going to have to go re-read the AnandTech articles, though most of the info seemed to just be speculation.

Edit- so re-reading this (http://www.anandtech.com/video/showdoc.aspx?i=3385&p=4) more closely, it looks like you are right trinibwoy.

I'm going to bet the graphics rendering mode is based on scene culling. I think everyone is reading far too much into the capabilities required to do what Hydra does.

[Sr7]

Yeah there are a lot of fallbacks including synchronization points, reverting to SFR or AFR etc. But that's exactly the point, all of these contingencies lower performance far below the holy grail of linear scaling.

AFR is the simplest approach and the easiest to get close to linear speedups. However, we've seen how hard it's been for Nvidia and AMD to consistently get near that with most applications. For AFR to work perfectly there has to be no inter-frame dependencies or synchronization points. Both will go up dramatically with a so-called object based approach.

Given that, we are now to believe that an intra-frame approach with vastly greater and more complex dependencies and synchronization points will achieve even better scaling than AFR? Even if you have no knowledge of graphics rendering your logical conclusion should be obvious.

The point is that Lucid will only scale linearly in applications with very simple rendering engines. But then AFR will too so what's the point? People seem to think Lucid is offering some magic bullet that removes the problems plaguing existing methods. But all it does is make all the problems even harder to solve.

Glad to see another knowledgeable skeptic here :)

I agree entirely, and I would also point out that the lack of scaling in games today with multi-gpu often can't be attributed to any fault of AFR/SFR... many times there simply isn't enough graphics work to do and you get CPU-bound. This would affect hydra the same it would affect AFR.. if there isn't graphics work to be done, hydra can't improve framerates.

[junkmonk]

IMO too much hype.
Are we seeing birth of first ever Lucid fanboy?

so it's okay for everyone to be negative and skeptical, but as soon as someone speaks positive about it its fanboyism? quit your trolling.

[Decami]

It doesn't have anything to do with being smarter than Intel, nVidia and AMD. It's about understanding how graphics rendering works and why Lucid's claims are ludicrous on the surface. All of the fancy algorithms they claim to have will be running on the CPU. The Hydra chip is nothing but a fancy PCIe bridge like N200.

----

The reason we're skeptical is because we have some basic understanding of how this stuff works.

hmmm...


Its basically smart to just not post in Lucid news posts if you have any positive thought, or hope in the product they are going to provide. But when you see things like this above, you have to point them out...

If you think all the work is done on your CPU, then how do you have a basic understanding of how all this stuff works again?

To add, this post is nothing we didnt know already, in fact, it isnt news at all. We already knew it ran at 4w, we already knew it was object based rendering, we already knew all of this, aside from it only able to carry 2 cards in graphics mode, according to Lucid before, it was like 16 or something retarded.

[Greg83]

imho technology like this is what many of us want.

Since we all would want it and can't have it, it raises our suspicions about the validity of the technologies claims, every day that passes without proof.

But at the same time, this technology can make or break the future of multi gpu's for ati , intel or nvidia if the claims hold true and all the manufacturers do not adopt hydra and only 1 or 2 did.

Then if none of them adopt hydra and it becomes exclusive to a few motherboard manufacturers.

or it becomes too large of a threat, that each new driver package for the gpu's try to break it.


I don't know much about hydra, other then I want it to be true.

[trinibwoy]

To add, this post is nothing we didnt know already, in fact, it isnt news at all. We already knew it ran at 4w, we already knew it was object based rendering, we already knew all of this, aside from it only able to carry 2 cards in graphics mode, according to Lucid before, it was like 16 or something retarded.

We don't know what Hydra can do. We only know what they claim it can do. And their claims are highly doubtful when subjected to the common sense test. The positive people are just swallowing empty promises seemingly without putting any thought into them at all. So positive isn't the right word there, more like gullible. Why can't any of those folks come up with a logical explanation for how this could work given our knowledge of the opengl/directx pipeline and the operation of modern graphics hardware?

Like I asked before, why hasn't anyone been able to address the concerns of the skeptics? Some folks have raised specific technical reasons why their claims make no sense (even some of the press that are hyping it have raised the same concerns). The forthcoming response was simply "well they said it works so therefore it does". If this pans out and it works I'll be as impressed as anyone. It's fine to be hopeful and excited about the possibility that one day we will get this kind of scaling but that's not a good enough reason to give them the benefit of the doubt. Their claims have been completely unsubstantiated thus far.

Look at some of the nonsense that's out there now. Claims of sending machine code to the graphics hardware directly and bypassing the driver? So now Lucid has reverse engineered the ISA's of all Nvidia and AMD GPUs and have detailed information on their inner workings? Hopeful is one thing, but that's heading into the realm of the supernatural right there.


If you think all the work is done on your CPU, then how do you have a basic understanding of how all this stuff works again?

The stuff I'm referring to is the existing process of rendering a frame in opengl/directx. That's pretty common knowledge. And in terms of running on the CPU, does the Hydra chip have some sort of large embedded memory that we don't know about? Because you need memory to store all of those profiles, libraries and algorithms that Lucid claims to be using.

[Talonman]

I still have one simple question:

Will it work on my X38 mobo, or does Hydra require an entire new mobo?

I want a Hydra card to stick in my PC, to let me run 2 Nvidia GPU's GPU's in Hydra mode. :up:

[grimREEFER]

another thing is micro stuttering which is caused by frametime problems. one frame will be harder to work on that the next, so the gpus will not fire frames at an even rate but might overlap each other which means that for some times both gpus fire their frames at almost the same time, which means you do see double the fps, but actually its basicaly the same as showing each frame twice and the game is stuttering and doesnt feel fluid even though the fps are high.


i tried encoding videos with divx (almost maxing out a quad core) and playing l4d, and i can get the same effect on a single gpu.
so maybe its reflective of some type of cpu limitation. cause the vast majority of sli and crossfire users dont observe this effect, and the technology is several years old.

[ToTTenTranz]

I still have one simple question:

Will it work on my X38 mobo, or does Hydra require an entire new mobo?

I want a Hydra card to stick in my PC, to let me run 2 Nvidia GPU's GPU's in Hydra mode. :up:

Supposedly, one of the expected products from Lucid is an add-in card.

[Decami]

We don't know what Hydra can do. We only know what they claim it can do. And their claims are highly doubtful when subjected to the common sense test. The positive people are just swallowing empty promises seemingly without putting any thought into them at all. So positive isn't the right word there, more like gullible. Why can't any of those folks come up with a logical explanation for how this could work given our knowledge of the opengl/directx pipeline and the operation of modern graphics hardware?

Like I asked before, why hasn't anyone been able to address the concerns of the skeptics? Some folks have raised specific technical reasons why their claims make no sense (even some of the press that are hyping it have raised the same concerns). The forthcoming response was simply "well they said it works so therefore it does". If this pans out and it works I'll be as impressed as anyone. It's fine to be hopeful and excited about the possibility that one day we will get this kind of scaling but that's not a good enough reason to give them the benefit of the doubt. Their claims have been completely unsubstantiated thus far.

Look at some of the nonsense that's out there now. Claims of sending machine code to the graphics hardware directly and bypassing the driver? So now Lucid has reverse engineered the ISA's of all Nvidia and AMD GPUs and have detailed information on their inner workings? Hopeful is one thing, but that's heading into the realm of the supernatural right there.



The stuff I'm referring to is the existing process of rendering a frame in opengl/directx. That's pretty common knowledge. And in terms of running on the CPU, does the Hydra chip have some sort of large embedded memory that we don't know about? Because you need memory to store all of those profiles, libraries and algorithms that Lucid claims to be using.

I typed out all this crap, and said screw it, people dont like to listen when they have it figured out already.


The cold hard truth is, none of us know a damn thing about this thing, and have no real knowledge to comment on the possibility of their claims. Most likely this thing will end up performing at around 80% of what they claim it will do if not less, if it ever releases. Cause lets face it, if it has no chance at going against SLI/Xfire, it wont last long at all. Which is why i think theres truth in what they claim, why would they stir this hype and have a supposed backer being Intel and just be blowing smoke up our ass?

...and seriously, did you need 3 paragraphs to comment on...


To add, this post is nothing we didnt know already, in fact, it isnt news at all. We already knew it ran at 4w, we already knew it was object based rendering, we already knew all of this, aside from it only able to carry 2 cards in graphics mode, according to Lucid before, it was like 16 or something retarded.

...?

Oh and Hydra intercepts the Lanes and distributes data, memory onboard? well we dont know that do we. But they have said this does NOT run on the CPU, lol its not another dang N200 chip. obviously far from such a thing.

[Talonman]

Supposedly, one of the expected products from Lucid is an add-in card.

Thanks for the reply. Just what I wanted to hear...

Now we just need to hear from Lucid!! :up:

Update... I just found this onfo on the add in Hydra board.

http://www.lucidlogix.com/technology/technologies.html

http://www.gamespot.com/pages/unions/forums/show_msgs.php?topic_id=26778531&union_id=11552

[LordEC911]

I typed out all this crap, and said screw it, people dont like to listen when they have it figured out already.


The cold hard truth is, none of us know a damn thing about this thing, and have no real knowledge to comment on the possibility of their claims. Most likely this thing will end up performing at around 80% of what they claim it will do if not less, if it ever releases. Cause lets face it, if it has no chance at going against SLI/Xfire, it wont last long at all. Which is why i think theres truth in what they claim, why would they stir this hype and have a supposed backer being Intel and just be blowing smoke up our ass?

...and seriously, did you need 3 paragraphs to comment on...

...?

Oh and Hydra intercepts the Lanes and distributes data, memory onboard? well we dont know that do we. But they have said this does NOT run on the CPU, lol its not another dang N200 chip. obviously far from such a thing.


If you don't understand where he is coming from with the many valid points/questions/reasoning he posted then you need to re-think telling other people "you [don't] have a basic understanding of how all this stuff works again?."

[trinibwoy]

I typed out all this crap, and said screw it, people dont like to listen when they have it figured out already.

Everything I've said is based on simply trying to analyze the data we have. Of course we don't know anything about Hydra. But we do know a lot about the process they claim to accelerate. So yes, we are in a position to do some level of analysis and comment on the probability of their claims. We aren't lemmings.


But they have said this does NOT run on the CPU, lol its not another dang N200 chip. obviously far from such a thing.

Heh, thanks for proving my point :) So they have data intensive processes that run on a chip that has no memory. Wow they have just revolutionized computer science!

And what does "Hydra intercepts the lanes and distributes the data" even mean? Can you be a tad more specific about what is being intercepted and distributed? You know what DirectX sends to the driver and you know what the driver sends to the hardware. Where does Hydra do its intercepting exactly?

I'm not trying to piss off anybody you know. Just playing devil's advocate and trying to get some sort of lively discussion going. But so far it's just been "shut up you dumb skeptic and stop dashing my hopes" :(

[Talonman]

Everything I've said is based on simply trying to analyze the data we have. Of course we don't know anything about Hydra. But we do know a lot about the process they claim to accelerate. So yes, we are in a position to do some level of analysis and comment on the probability of their claims. We aren't lemmings.



Heh, thanks for proving my point :) So they have data intensive processes that run on a chip that has no memory. Wow they have just revolutionized computer science!

And what does "Hydra intercepts the lanes and distributes the data" even mean? Can you be a tad more specific about what is being intercepted and distributed? You know what DirectX sends to the driver and you know what the driver sends to the hardware. Where does Hydra do its intercepting exactly?

I'm not trying to piss off anybody you know. Just playing devil's advocate and trying to get some sort of lively discussion going. But so far it's just been "shut up you dumb skeptic and stop dashing my hopes" :(

We do hope it is a big success... There is truth in that!! :)

[STEvil]

Everything I've said is based on simply trying to analyze the data we have. Of course we don't know anything about Hydra. But we do know a lot about the process they claim to accelerate. So yes, we are in a position to do some level of analysis and comment on the probability of their claims. We aren't lemmings.



Heh, thanks for proving my point :) So they have data intensive processes that run on a chip that has no memory. Wow they have just revolutionized computer science!

And what does "Hydra intercepts the lanes and distributes the data" even mean? Can you be a tad more specific about what is being intercepted and distributed? You know what DirectX sends to the driver and you know what the driver sends to the hardware. Where does Hydra do its intercepting exactly?

I'm not trying to piss off anybody you know. Just playing devil's advocate and trying to get some sort of lively discussion going. But so far it's just been "shut up you dumb skeptic and stop dashing my hopes" :(


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.

I think you need to pick your bone with the guy who wrote that: http://www.anandtech.com/video/showdoc.aspx?i=3385&p=4

Honestly I have no idea about machine code but i'm willing to bet he has more knowledge in the area than you by the way you construct your arguments.

[Solus Corvus]

I'm not trying to piss off anybody you know. Just playing devil's advocate and trying to get some sort of lively discussion going. But so far it's just been "shut up you dumb skeptic and stop dashing my hopes" :(
Sorry but I just don't think we have enough information yet for a lively discussion.

Based on the screenshot posted I hypothesized that some objects (and probably some effects too, come to think of it) would have to be duplicated on both cards. You countered that such a method would have less then perfect scaling - and I agree so I didn't respond to that point. You didn't elaborate any further and cite examples where this method of duplicating certain objects wouldn't work at all.

You are never going to get linear scaling or greater with any method, think Amdahl's law. There may be corner cases where a confluence of factors other then the number of GPUs and the scene being rendered meet to result in greater then linear scaling - but it's rare. I don't know if Lucid is promising linear scaling - but if they are I would definitely see it as marketing hype that is out of touch with reality.

To me the question is what will the rendering characteristics be like. How smooth will it be? How much latency will the process have? What will the scaling be like compared to AFR? Will inter-object dependencies have a greater effect on scaling then inter-frame dependencies have on AFR (a highly scene/engine dependent question)? But frankly I don't think we have enough information to deeply discuss those issues objectively.

[trinibwoy]

Honestly I have no idea about machine code but i'm willing to bet he has more knowledge in the area than you by the way you construct your arguments.

And what way is that? He raised the same exact point I did which is that Lucid can either work with API calls or directly with the hardware ISA. The difference is that he dismissed the possibility of intercepting API calls and is guessing that it's working directly on GPU microcode. Whereas I dismissed both for the obvious reasons I've given before.


You didn't elaborate any further and cite examples where this method of duplicating certain objects wouldn't work at all.

I'm quite sure I raised specific examples of Z-only passes and deferred shading earlier in this thread. Shadow mapping is another example. Basically any technique that requires access to all geometry in the scene will not work with a so-called object based distribution. I also brought up the AA buffer resolution problem. Nobody has responded on why any of that would be feasible even if Lucid had full access to all stages of the rendering process. Which they don't.

[Solus Corvus]

I'm quite sure I raised specific examples of Z-only passes and deferred shading earlier in this thread. Shadow mapping is another example. Basically any technique that requires access to all geometry in the scene will not work with a so-called object based distribution. I also brought up the AA buffer resolution problem. Nobody has responded on why any of that would be feasible even if Lucid had full access to all stages of the rendering process. Which they don't.
Well that settles it I guess. Since it's impossible for them to work around those issues we should probably just label this as vaporware and move on.

[STEvil]

So how could this work, Trini?

[trinibwoy]

That's what I'd like to know. Let's take a look at the claims in the Anand article as a basis for the proposed approach. Now I'm not sure if this is actually Lucid talking here or if the Anand guys are just guessing in order to fill the rather big holes in the process.


From a high level, Lucid's technology intercepts DirectX or OpenGL API calls, analyzes them, organizes them into distinct tasks, and based on the analysis combined with the historical performance of various cards handling of previous frames' workload, it evenly distributes the tasks across all the GPUs in the system.

I can give them the benefit of the doubt on the first part about intercepting API calls. Now I don't even know how this is possible since that means they will have to fool Windows into sending DirectX calls to their software and not to the registered graphics driver. Since Vista doesn't even allow multiple graphics drivers to be registered I have no clue how this will be done. I have a bigger problem with the second part because there are some tasks that cannot be cleanly broken up prior to reaching the GPU and will be faster running on a single GPU compared to parceling it out and recombining afterward.


After the workload is distributed, the buffers are read back to the Hydra chip and composited before the final scene is sent to the proper graphics card for display. Looking a bit deeper, here is a block diagram of the process itself from Lucid's whitepaper.

This one is iffy too. They would need to instruct the GPU to write its partially completed buffer back to system memory as Hydra obviously can't directly inspect the local framebuffer. So besides the fact that they have to usurp AMD's and Nvidia's control over their own hardware, where's the bandwidth coming from to handle all this data transfer? If PCIe was enough those guys wouldn't have bothered with CF and SLI bridges in the first place.


In theory, tracking and adjusting to dependencies on the fly will completely avoid the issues that keep NVIDIA and AMD from running AFR in all games. And they even claim that this can help give you higher than linear scaling when using their hardware with more than one card.

This is the biggest piece of hogwash in that article IMO. AFR suffers from a single inconvenience which arises when a game engine reuses buffers or other resources generated during the prior frame. This dependency is pretty straightforward to evaluate and understand yet we see how much AMD and Nvidia struggle to get AFR scaling well in some titles depending on the amount of inter-frame sharing going on.

Lucid doesn't even attempt to address this problem since they're presumably distributing the workload of a single frame across multiple GPUs. Even if they were 100% successful at that task they would still be subject to the same inter-frame dependencies as AFR. As a matter of fact, if they had all of this talent it would be best applied trying to solve the AFR problem instead of mucking around with vastly more complicated and overhead intensive intra-frame distribution. I'm really disappointed in the seeming lack of technical insight by the people who wrote that Anand article. In the end, even if Lucid's claims pan out and they were able to engineer software to do all the things they claim they can do intra-frame it would require such a high level of synchronization, CPU intervention and inter-GPU bandwidth in addition to the existing bandwidth needs for inter-frame resource sharing that there's no way they can prove their BS claims of adding no latency to the process or perfect scaling.

[Aberration]

This chip appears to sit between the Chipset and the GFX cards. How does the GFX card get the data to process? Is it possible that this chip intercepts the data before it gets the the GFX card.

[Talonman]

Any new news... ?? :)