Lucid Hydra on Smackover 2

[Shintai]

Why are most people getting hung up on the cross brand compatibility between an ATI and Nvidia card?

This things biggest bonus to me seems to be increased performance between 2-3 of the same cards working together in a better system then SLI or crossfire.

Doesn't this chip allow for all the cards to use their full ram instead of limiting the ram size of 1 card? Or was that false?

Should allow each card to use the memory to its full. Since the textures aint there (Black parts). But Lucid have been very poor to release any detail. So also could be limited. Tho it would be very unlikely.

However you need to hide it from the game etc somehow. Or override it. Else the games or DirectX might just say 512MB and not..1536MB forexample to the game engine.

[Decami]

While I understand your point, I have to say that you are wrong here. I'm not trying to come off as rude but your response is just a bit naive. Here is why...

First.. to compare the status quo of oil (mega corporations) to the state of multi-gpu is a bit of a non-sequitur. Basically that in itself is not comparable, because oil lobbies governments like crazy to get special interest wedges in place. That said, there is *absolutely no reason* why AMD and NVIDIA wouldn't have done this if it made sense and worked properly. It would give them 1 more chip (see relevance) in the average enthusiast system, which they could keep from Intel and hold over their heads. At some point you need to stop and realize that maybe it wasn't done because it doesn't make sound technical sense from the driver or latency or image quality perspectives... things aren't always about "evil corporations".

The analogies you make also fail in that in the tech industry... if you think you can just hold onto technology without changing for decades, you're gravely mistaken (in this industry more than any other). Look at what happened with hard disks... SSD's came to the marketplace and the hard disk manufacturers who were not prepared for/invested in this future tech were caught with their pants down. Now almost all the patents and technology they have spent years building are irrelevant. It's a vastly different business when the mechanical element goes out the window and flash memory comes into the picture. The smart guys hedged their bets and are now making SSDs with IP they invested in years ago. The slow guys who thought they could sit on their tech forever got burned, and are now making attempts to sell off their hard disk drive businesses, as the average price for a HDD plummets (no profitability left in the market).

Secondly, SFR (split frame rendering, what this Hydra technology uses) used to be the main method multi-gpus used... until AFR came along and became the standard. Now all default crossfire and SLI profiles use AFR. Why? Better scaling. If you take any NVIDIA GPU and test the default SLI profile, then compare to SFR scaling, you'll see my point (same goes for ATI but you can't force SFR on their products through their CP).

The way that 3d graphics work, you can't just arbitrarily chop up a frame and send it to two different cards and expect a proper image to come out of it. What about data that spans into both sub-frames? States get set in DX runtime calls, and you can't just round robin the draw calls.. you'd have to make each GPU fully aware of the rest of the frame also, meaning you have inherently duplicated work, even if they're not each computing the whole frame.. they're still overlapping, which is always a bad thing here. I have no doubts they've demo'ed the tech but I imagine they have some hacks in place to work around shortcomings. If you think you have driver problems now with SLI or CF, wait till you add more latency and another layer of software to the mix.

Last, as I mentioned before, the reason microstutter exists is the same reason Hydra can't effectively dole out work to arbitary GPUs... it has no way of knowing how long the different chips are going to take to process each of the frames, especially because framerates in realtime games can vary wildly from frame to frame, so you can't use knowledge from prior frames to offset the present of the new frame, because maybe that frame was way faster or slower than the 20 preceding it. Also, knowledge of each GPUs capabilities, let alone their speeds at different parts of the graphics pipeline are impossible to effectively asses, especially for 3rd party software with no access to the GPU/driver internals. It's hard enough for the chip to know definitively "Okay this chip is this fast relative to this chip, I need to send 20% of the frame to the slower chip", let alone the even more complex issue of "when I send 20% to the slower chip, how do I predict if that architecture of GPU will be quite bottlenecked for this particular piece of geometry vs. the other GPU architecture"

My final gripe would be the fact that Lucid is putting out beautiful marketing slides and getting peoples hopes up. They're promising 100% scaling no matter what. The sad truth is this will just not work the way they're selling it. Crossfire and SLI take a lot of flak for not always scaling to expectations. What people don't realize is that you can only scale up to the point where you are CPU bound and have no more graphics work to do, so many times this is why things don't scale further. Adding more graphics cards to the equation after the point of complete cpu-boundedness will only hurt framerates, not help. Also, there are issues around inter-chip communication. Currently you need SLI and Crossfire profiles to tell the driver "hey I know the game developer didn't clear this re-render this resource, or clear this to signal that they don't need you to retain any data, but you can safely discard this data and no corruption will occur". Lastly, if a game isn't scaling because of CPU/GPU synchronization, you won't see scaling either. Hydra won't fix that.. so much of this lies in the game developers ability to properly handle these cases (or a profile to exist for each game, as they do in NVIDIA and ATI drivers).

Without this, you either take the conservative route to avoid corruption and assume the game developer meant to have the present frame depend on the previous one (and transfer between GPUs, hurting scaling, which can't happen with the Hydra system), or you take the aggressive route and say "I don't care if the developer expected me to preserve some data between frames because they default to programming under the assumption of 1 GPU with an "untouched" set of memory from the last frame... kill the previous frame data and risk corruption anyway!"

The bottom line is if you have multiple GPUs they need to be able to talk via the driver and be aware of one another, and this isn't possible in the case of different manufacturers, or a non CF/SLI configured setup.

There are so many reasons this is a bad idea (though it's great in theory), you just may not realize it yet. It's a bit of a pipe dream in the long run IMO.

all that for no reason, first of all, i end my post with this...

Now this tech doesnt really fall under the same category, but you get my point.

second i never said anything about evil corporations, ever, I said market and money controls, which is hardly evil, its logical, and its what has to be done in the eagles eyes of the stock holders.

While things upgrade rather quickly, companies still try to hold onto things that are big money makers, its obvious, look how long Nvidia dangled around the G80, and SLI and Xfire now has been around for quite some time.


YOu wanna make this massive post about how you dont think this works, yet it has been demoed many times and without fail. You saying the demos are fakes? Now who's talking evil corporation.

Not trying to be offensive. Just it seems you are arguing something with no "direct points" I understand some of your points, but where do they lead?

Its like your almost using your points to say Hydra is bull. It doesnt exist and wont work.

When they are saying release is Q1, chip is done, and explain what it does and have showed what it does.

So they are lying about it all?

I too want to know some of the answers you are seeking, but you and I are different hear, you are asking the questions like the Hydra chip is a theory. When i want to ask the questions to know the answers that I know exist.

your coming off almost as a conspiracy theorist. Like its some big bull crap all made up to get people going.

I must say, you are one depressing cat.

[del_fuego]

Blah, blah, blah IMO.

Wow....just wow.....

Read the thread mate and the links posted too. Here's another one with explanations and original questions. http://www.pcper.com/article.php?aid=607

You need to understand how they're load balancing the gpu's buddy, there will even be situations when one gpu will be rendering ALL textures etc while the second gpu is running just the lighting passes or different effects. AFR and SFR will be used ONLY when it is the best option for that PARTICULAR frame as the Lucid Hydra will be CONSTANTLY changing the way it balances the load across gpu's. Thats the magic.

Thinking about an earlier concern regarding image quality across different generations of card, not sure if it will be a problem as the Lucid chip is recompositing the image on a per pixel basis and outputting via the one gpu connected to the monitor you're playing on, i.e: if i had a 260GTX paired with an 8800GT i'd be using the 260GTX to output to the monitor so iq should be moot. A concern i do have is how will AA and other filters be applied?

[Sr7]

all that for no reason, first of all, i end my post with this...




second i never said anything about evil corporations, ever, I said market and money controls, which is hardly evil, its logical, and its what has to be done in the eagles eyes of the stock holders.

While things upgrade rather quickly, companies still try to hold onto things that are big money makers, its obvious, look how long Nvidia dangled around the G80, and SLI and Xfire now has been around for quite some time.


YOu wanna make this massive post about how you dont think this works, yet it has been demoed many times and without fail. You saying the demos are fakes? Now who's talking evil corporation.

Not trying to be offensive. Just it seems you are arguing something with no "direct points" I understand some of your points, but where do they lead?

Its like your almost using your points to say Hydra is bull. It doesnt exist and wont work.

When they are saying release is Q1, chip is done, and explain what it does and have showed what it does.

So they are lying about it all?

I too want to know some of the answers you are seeking, but you and I are different hear, you are asking the questions like the Hydra chip is a theory. When i want to ask the questions to know the answers that I know exist.

your coming off almost as a conspiracy theorist. Like its some big bull crap all made up to get people going.

I must say, you are one depressing cat.

There's a difference between lying and inflating the truth while trying to get investors. I'm sure they have something they've shown as I alluded to already, but it's not as easy as you guys think to make this type of thing work, let alone work fluidly.

Come on, you honestly think you can have their 3rd party tech know how much work to send to each GPU? How can you get 100% scaling unless you perfectly divide the work? If the workload is different (one does geometry, one does textures) as you say, how could you possibly know the amount of time it would take to render each portion, to ensure you're getting maximum overlapped rendering (i.e. scaling)?

Not to mention the entire point of a graphics pipeline is you're bottlenecked somewhere in it... if you're bottlenecked by texturing, it won't do you any good to split off the geometry rendering phase to another GPU, because you'll STILL have that same texture bottleneck in the chip doing the texturing. Do you guys understand how bottlenecks work at all? You're only as fast as your slowest point in the chain.

Different generations of chips do operations at different precisions.. you'll end up with different colors running the same thing through each chip. You really want to combine those into 1 final image?

Clearly you guys are sold on this but I really think there is a lot of naivete here. I'm not accusing any corporation of lying, but I think you guys are just lapping this up. Clearly there are a lot of people posting here who don't understand how this stuff works, and that's okay.. but please don't try to flame someone who clearly has more knowledge on the topic.

[Manicdan]

Come on, you honestly think you can have their 3rd party tech know how much work to send to each GPU? How can you get 100% scaling unless you perfectly divide the work? If the workload is different (one does geometry, one does textures) as you say, how could you possibly know the amount of time it would take to render each portion, to ensure you're getting maximum overlapped rendering (i.e. scaling)?

by measuring latency of the workload sent and adjust accordingly. its really not too hard to have a monitor built into the chip that checks how long it takes to have the frame information of each gpu replied back. and who knows if the hydra chip will come with a benchmarking type program that measures the gpu(s) for performance, and uses that info to know which is better for which features.

[Manicdan]

Clearly you guys are sold on this but I really think there is a lot of naivete here. I'm not accusing any corporation of lying, but I think you guys are just lapping this up. Clearly there are a lot of people posting here who don't understand how this stuff works, and that's okay.. but please don't try to flame someone who clearly has more knowledge on the topic.

u should use your own advice, u talk as if you made the chip yourself, but dont believe its even possible.

try to think outside of what SLI and CF do, then u can talk to us about how the hydra works

[Sr7]

by measuring latency of the workload sent and adjust accordingly. its really not too hard to have a monitor built into the chip that checks how long it takes to have the frame information of each gpu replied back. and who knows if the hydra chip will come with a benchmarking type program that measures the gpu(s) for performance, and uses that info to know which is better for which features.

That wouldn't work, otherwise microstutter would be solved by now. You can't just "measure and adjust" because you don't know what the next frames frametime will be. Each frame can be wildly different, run fraps sometime to see your frametimes on a per-frame level, then look at it and ask yourself "what could a LUCID driver extrapolate on to ensure it knows how fast 1 gpu is relative to another?" Each chip will be faster or at different points, depending on clocks and arch bottlenecks. They can't just predict that kind of stuff.

If you did what you say, you'd end up slowing down potentially faster frames.

u should use your own advice, u talk as if you made the chip yourself, but dont believe its even possible.

try to think outside of what SLI and CF do, then u can talk to us about how the hydra works

Uh, I'm not talking about how Hydra works, I'm talking about general rendering... clearly many people have been swooned by the idea and have bought in full bore Call me a skeptic.

[Shintai]

People should be careful about Hydra hype sofar. it can turn out to be great. It can also turn out to be nothing than a turd.

[Tony]

2 week wait...I am sure we will all see this at CES

[Decami]

Sr7, you keep saying 100% scaling and they have never said thats constant, or even frequent, they have said "near" 100% scaling. Just to get that straight.

Who knows what near is, but obviously its better than SLI/CF, by atleast a good margin, or it wouldnt be going in to production, better is good.

oh and "inflating the truth to get invenstors" doesnt really make sense, this has been Intel backed for quite some time now, not much more investors are needed over that, and
incase you havent noticed, Intel delivers, most of the time, on what it promises, I very much dought they would invest and support something that isnt gonna do the same.

Ill admit, this could turn out to be something a lot less than what we hope, but I have no dought it will be a better alternative to SLI/CF.

[STEvil]

100% scaling is a possibility and given recent performance figures for SLI/X-Fire 100% (or very near) could be very doable in many situations given that you are using the proper hardware.



I suggest you guys all crack a cold one and sit back, there's no reason to be speculating like this when it could turn out to be another Bitboys... or Phantom.

[saaya]

im still very sceptical about hydra... if it would be that easy to get multiple gpus to scale almost linearily, youd think that ati, nvidia or intel or anybody else would have come up with something like this a loooooooooooong time ago.

[bonobo]

im still very sceptical about hydra... if it would be that easy to get multiple gpus to scale almost linearily, youd think that ati, nvidia or intel or anybody else would have come up with something like this a loooooooooooong time ago.

Do you have requested some sample for Hydra at Foxconn ? I am really curious to know if they really distribute the chips to customers ( aka hardware designers ) or if it is just words on a paper ...

[Xoulz]

Ehm..the Hydra system knows nothing of the GPU and its capabilities. Its simply a load balancer. Plus you need the graphics driver from nVidia, AMD etc to do anything.

The chip test each card on the subsystem, and does load balancing on the fly.

[Gilhooley]

Do we know how the "recombining" of the picture works? If you use a lot of different cards it seems like you also have to use a Y or W DVI connector, for I cant see SLI/Crossfire working that well over several generations.


BTW checkout the PDF if you havent, seems legit http://lucidlogix.com/files/hydra_100_product_brief.pdf

Hmm, it also reads a bit like "any gpu from any vendor" but they never state clearly that you can mix vendors at the same time..

[Levish]

even above 100% scaling is possible if it offloads some of the processing to the hydra chip as well :s

[Shintai]

The chip test each card on the subsystem, and does load balancing on the fly.

I think you honestly make it up

The chip would have no knowledge about the cards. And a new card would ruin it quickly.

Personally I think Hydra will be good for consoles with locked HW. On a PC it will flop so hard it hurts. And as someone else pointed out. It smell of bitboys.

Plus lag and shuttering issues got potential to be very bad. Also the Hydra chip as such doesnt do anything that AMD/nVidia couldnt do..if it worked. It would be much more elegant in drivers. Both for fixes and future compability with DX, OpenGl and OpenCL versions. And ofcourse new cards and such.

[STEvil]

Why cant the chip have knowledge of the capabilities of the GPU? Could be as simple as a GPU database with a gpu-z app running in the backend.

[Manicdan]

Why cant the chip have knowledge of the capabilities of the GPU? Could be as simple as a GPU database with a gpu-z app running in the backend.

also, who says this wont have its own capabilities to stress a system and find out for itself what the gpuz like results would be.

this chip wasnt created by a bunch of idiots, we should have more faith in their ability to know the most basic questions, then if they are going to production with it, we can assume they have solved them too.

just think, who would buy this if there was a noticeable 1/2 second lag, or had worse scaling than cf/sli, or wasnt compatible with any video card except the few they built their own drivers for. if they cant get past those simple obvious things, then they will only cause their own failure.

[Sly Fox]

Why cant the chip have knowledge of the capabilities of the GPU? Could be as simple as a GPU database with a gpu-z app running in the backend.

This guy knows what's up.

[Sr7]

Why cant the chip have knowledge of the capabilities of the GPU? Could be as simple as a GPU database with a gpu-z app running in the backend.

What?? so you have to profile for every GPU variant, each of which has different bottlenecks? Then they have to do GPU architecture profiling, and the drivers are constantly changing.. there's no way you can set this in stone and expect it to work correctly indefinitely.

They won't have the ability to look into the graphics driver and know exactly what its doing or what work its bottlenecked by. You can't just dole out work based on what *you* deem to be x% of a frame's workload, because you have no idea how generation of each chip (or driver) will handle the work. A database of GPUs doesn't tell you anything about the internals or arch bottlenecks. Just basic info. 1 generations "SP" might not be equivalent to the next architectures "SP". Database is a naive approach.

[shiznit93]

What?? so you have to profile for every GPU variant, each of which has different bottlenecks? Then they have to do GPU architecture profiling, and the drivers are constantly changing.. there's no way you can set this in stone and expect it to work correctly indefinitely.

that really wouldn't be that hard to do, processing units on gpus (simd, rop, texture units, bla bla) are not a secret and there are not that many models. They are already doing load balancing now so they obviously have a way to measure what a given gpu can do, a simple gpu-z type database could suffice. A new gpu comes out, Lucid updates the driver to tell it how much power and bandwidth the card has and you are back in busine ss.

[Manicdan]

What?? so you have to profile for every GPU variant, each of which has different bottlenecks? Then they have to do GPU architecture profiling, and the drivers are constantly changing.. there's no way you can set this in stone and expect it to work correctly indefinitely.

They won't have the ability to look into the graphics driver and know exactly what its doing or what work its bottlenecked by. You can't just dole out work based on what *you* deem to be x% of a frame's workload, because you have no idea how generation of each chip (or driver) will handle the work. A database of GPUs doesn't tell you anything about the internals or arch bottlenecks. Just basic info. 1 generations "SP" might not be equivalent to the next architectures "SP". Database is a naive approach.

why does it seem impossible for the chip to test the gpus itself?

[Shintai]

why does it seem impossible for the chip to test the gpus itself?

Because it would need complicated data to do so for each single chip and generation. In short, it would need to have the latest driver to do so. And no, it cant just extract it from the GFX driver.

People are starting to overhype this to make it "fit".

[Jamesrt2004]

im still very sceptical about hydra... if it would be that easy to get multiple gpus to scale almost linearily, youd think that ati, nvidia or intel or anybody else would have come up with something like this a loooooooooooong time ago.

I think its due to the fact that this solution means you can run AMD + Nvidia... etc.... and the companies don't want that!!! they only want you to buy their own products which is understandable so they didn't "try" is how I look at it