Lucid Hydra on Smackover 2

[RaZz!]

read more guys. How this works is it supports any cards, as many as can fit on the mother board supposedly that are supported by the same driver, so no ATI and Nvidia until hacked drivers from where ever can do that, the "one" driver has to support the cards used together.

Supposedly, what Lucid said, it will be "near" 100% scaling, so the card you add, will add as much performance (almost) as the performance it gives by itself.
If you dont know, SLI or Xfire, DOES NOT do this, not even close.

by the way, reading some of these posts, i never remember Lucid saying anything, ever, about mix matching companies, what i said above, is what they have said many times, in the demos, so I dont know where some of you guys are getting your stuff, maybe i havent seen it yet, or maybe its rumor.

with different cards i didn't mean ati/nvidia, but also cards of different generations from the same vendor... still, this doesn't answer my question: will lucid use it's own drivers and one still needs the gpu drivers installed? how do these 2 devices (the lucid chip and the gpu) work together in the os? etcetc...

lucid DOES NOT use SLI or Crossfire and wont enable it, it uses a CPU like chip that intersects the lanes and "re-adjusts" information accordingly.


when you think of Hydra, put SLI and Xfire out of your mind, it does not work anyway like it.

i think you misread what i wanted to say. i said "sli/crossfire like functions", and not that it'll use sli/crossfire. and with "sli/crossfire like functions" is just mean mutlitple graphics cards at a time...

[Aberration]

with different cards i didn't mean ati/nvidia, but also cards of different generations from the same vendor... still, this doesn't answer my question: will lucid use it's own drivers and one still needs the gpu drivers installed? how do these 2 devices (the lucid chip and the gpu) work together in the os? etcetc...




i think you misread what i wanted to say. i said "sli/crossfire like functions", and not that it'll use sli/crossfire. and with "sli/crossfire like functions" is just mean mutlitple graphics cards at a time...

They had a video of a demo of the system, and IIRC it had to different nV cards in it? The demo showed 2 screens of what each GPU was rendering. And so each screen had black or empty textures. So somehow the Lucid chip is delegating rendering of individual textures within a frame?

I dont know, but I cant wait to see it.

[Shintai]

They had a video of a demo of the system, and IIRC it had two different nV cards in it? The demo showed 2 screens of what each GPU was rendering. And so each screen had black or empty textures. So somehow the Lucid chip is delegating rendering of individual textures within a frame?

I dont know, but I cant wait to see it.

Nopes. Itw as 2 8800GT cards. And from the same maker etc.



The Lucid chip is doing OpenGL/DirectX kind of intercepting in the chip I think (or OS via a driver that tags the framesetups). I´m just guessing. But its pretty limited what it can do if its hardware locked. One thing is sure, it collects the framebuffer resutls from both cards and send it back to 1 for display in the end.

Some facts is that the Hydra 100 chip is PCIe 1.1 and support DX10.1 and OpenGL 2.1. It doesnt support OpenGL 3.0, OpenCL, DirectX11 or PCIe 2.0.

It honestly look to be very very ugly for the PC scene. But it would be nice on consoles etc that you control the HW on.

http://www.lucidlogix.com/files/hydr...duct_brief.pdf

I fear that there has gone too much PR/hype in the Hydra chip.

[del_fuego]

"So, how do the multiple GPUs connected to a HYDRA ASIC relate to the host system? The Lucid HYDRA Engine is capable of bringing together dissimilar cards to work on rendering tasks - however, there is one limitation: All GPUs must be able to share the same software driver. That means you can forget mixing and matching cards with ATI and NVIDIA GPUs in the same HYDRA configuration. Cards from both makers can theoretically be present in the same system, however - you could have a HYDRA array of ATI Radeon HD 4870s handling the video rendering, with a low-end NVIDIA GeForce 8600GT handling PhysX acceleration, for example."

http://techgage.com/article/lucid_hy...u_technology/1

Heres a good article that breaks it down a bit more. It also throws up some interesting questions as i get the impression that Lucids driver is probably gonna need specific game profiles to make sure the right algorithms are used. There is some interesting multi-gpu ideas too in there. I'd love to know what nvidia et al think of this to be honest?

[Manicdan]

the fact that its rendering only partial sections of the environment is great.
were so use to CF and SLI that alternate frames or do half a screen each, end up costing the same memory for each one. if the lucid can keep half the textures on each, it would be killer to see 2x 4870 512MB do just as good as the 4870x2 2GB at any resolution/setting.

the scariest thing seems to be latencies, but we cant argue that this thing is just a great concept that we all hope brings new ideas to how gpu scaling can really should work.

and for the console idea, i wonder if this would help make the nextgen system use many inexpensive gpus, and let the programmers decide which one gpu handles which environment pieces.

[Decami]

with different cards i didn't mean ati/nvidia, but also cards of different generations from the same vendor... still, this doesn't answer my question: will lucid use it's own drivers and one still needs the gpu drivers installed? how do these 2 devices (the lucid chip and the gpu) work together in the os? etcetc...




i think you misread what i wanted to say. i said "sli/crossfire like functions", and not that it'll use sli/crossfire. and with "sli/crossfire like functions" is just mean mutlitple graphics cards at a time...

YES, it can use cards from different generations, as stated many times, ANY CARD supported by one driver, so obviously looking at the NV card support list on some of the drivers, you will be able to use cards from different generations with them.

To answer about working together with drivers in the OS, not sure exactly how that will be handled, but this I know, Lucid intercepts the lanes before they ever reach the video cards and then sends the information accordingly, so there might be some software used inside the OS, but I expect not much, and for it not to be a conflict with drivers much at all, since the information they recieve is still the same, just on a different pay load scale.

Also as for SLI/Xfire functions, not sure exactly what you mean by that. As stated before, put SLI/Xfire out of your mind, this chip, again, intercepts info before ever reaching the GFX cards, so multi gpu functions wont be needing to be "enabled" or anything of the sorts.

sorry for mis interpreting what you said.

i would suggest reading this http://www.anandtech.com/tradeshows/showdoc.aspx?i=3379 to understand exactly whats going on.

[Decami]

the fact that its rendering only partial sections of the environment is great.
were so use to CF and SLI that alternate frames or do half a screen each, end up costing the same memory for each one. if the lucid can keep half the textures on each, it would be killer to see 2x 4870 512MB do just as good as the 4870x2 2GB at any resolution/setting.

the scariest thing seems to be latencies, but we cant argue that this thing is just a great concept that we all hope brings new ideas to how gpu scaling can really should work.

and for the console idea, i wonder if this would help make the nextgen system use many inexpensive gpus, and let the programmers decide which one gpu handles which environment pieces.

2x , imagine 4, or 6, supposedly, lucid said it supports up TO 16!!!

Put it this way, if Hydra works the way they say it is going to, anyone with money will be able to have 100 FPS constant in any game they choose, at any resolution and settings. The only hold back, will be how many PCIe slots are available on the board.

The crazy thing is too, that this will be achievable with the cards we have now, and those will still be usable with cards that come in the future!!!! Imagine what PC gaming will be like in another 5 years, if this all goes as well as we hope.....just wow!!!

[Chruschef]

I do not believe that only intel will have this on their smackover board, Lucid would have contracted with other manufacturers like Asus, Gigabyte(the usual suspects).

Pics or it didn't happen as well.

[Salavat23]

This seems to good to be true, and ATI and nVidia will probably do everything they can to stop this technology from coming out.

[STEvil]

2x , imagine 4, or 6, supposedly, lucid said it supports up TO 16!!!

Put it this way, if Hydra works the way they say it is going to, anyone with money will be able to have 100 FPS constant in any game they choose, at any resolution and settings. The only hold back, will be how many PCIe slots are available on the board.

The crazy thing is too, that this will be achievable with the cards we have now, and those will still be usable with cards that come in the future!!!! Imagine what PC gaming will be like in another 5 years, if this all goes as well as we hope.....just wow!!!

You forgot the CPU limiting things.. and ram.. and etc...

[BababooeyHTJ]

If ATI and Nvidia who have been in this market forever still have problems with drivers then I have my doubts about Lucid.

[DX_Medic]

Directly from Lucids Site............http://lucidlogix.com/technology/distributed.html


The HYDRA real-time distributed processing engine can:

Deliver cost-effective graphics performance with a near-linear to above-linear performance.
Operate in an adaptive, dynamic, real-time manner.
Eliminate bottlenecks that exist in typical 3D graphics applications.
Provide interoperability with all GPUs and chipsets.
Work with the latest versions of DirectX and OpenGL

I love this image because nvdia appears to be getting less load in the actual gif !!!

[STEvil]

uh... k..

[Sr7]

I love this image because nvdia appears to be getting less load in the actual gif !!!

errr wtf are you talking about?

NVIDIA and AMD have a hard enough time making their multi-chip solutions work without issues. They have the ability to design their hardware and software however they want for this to work well, and there are always still issues with it. This should tell you something.

If the masters/creators of the technology can't make it work flawlessly, what makes you believe some random no-names with no history of making anything will be able to stick in an extra layer of hardware and software and have everything work perfectly, if at all?

And as Shintai said, you can't have 2 drivers active at the same time with the LDDM/WDDM: http://en.wikipedia.org/wiki/Windows...y_Driver_Model

Therefore you can't run an ATI with an NVIDIA board. Even if you could.. why in the hell would anyone want to? You really want to open the door to all the chaos that can ensue at the software level? You know both drivers have been designed under the assumption that they would have full control over the systems resources at runtime with a 3d application.

Also, why would you want to run a slower and faster card together? Do you really want to invite micro-stutter into your gaming experience with every odd numbered frame rendering fast on a faster GPU and every even numbered frame rendering slower?

What is the point of having a high framerate average if it's not smooth when you play it, and therefore feels like a lower framerate? The most important thing in the end is your experience. No one wants the framerate for the sake of it.. if you do you're missing the point, or you're just a benchmonkey who doesn't game

I don't know about you guys but if someone tried to stick this chip that probably won't pan out to be what it's said to be onto my motherboard, and it's sucking up power, I'd probably want to smack the people who thought it would be a good idea. Maybe that's just me though

[shiznit93]

Sr7 you make some good points but I think you got it a bit twisted when it comes to not using identical cards. Hydra doesn't use AFR, each frame is analyzed and the rendering required is divided between the two cards. A weaker card can be assigned less work in the same frame proportionally to its power, its not SFR either where they just draw a line and assign sides to cards, if you look at the demo screenshot you will see that while one card is rendering the floor the other one is rendering the wall in front of the player. I'm not saying that it would work perfectly with cards of unequal power but with Hydra both cards render all the frames together so there should be no microstutter due to sync latency (although I wonder if the Hydra chip will introduce some latency when it's figuring out how to divide the load).

[Sr7]

Sr7 you make some good points but I think you got it a bit twisted when it comes to not using identical cards. Hydra doesn't use AFR, each frame is analyzed and the rendering required is divided between the two cards. A weaker card can be assigned less work in the same frame proportionally to its power, its not SFR either where they just draw a line and assign sides to cards, if you look at the demo screenshot you will see that while one card is rendering the floor the other one is rendering the wall in front of the player. I'm not saying that it would work perfectly with cards of unequal power but with Hydra both cards render all the frames together so there should be no microstutter due to sync latency (although I wonder if the Hydra chip will introduce some latency when it's figuring out how to divide the load).

Ah yes, okay, so microstutter may not be an issue, but really.. how would the hydra chip know how much work to give each chip each frame? It can't know the chips bottlenecks or general performance and account for them in realtime.

There are all kinds of quality issues that would come into play too.. say 1 frame an older NVIDIA 6-series renders, the window or some texture. Then the next frame it's done by a newer 9-series. You'll get different image quality each frame? This is still totally not feasible.

If it were worth it, it would've been done by now. And you're right. Adding more latency into the process is a bad idea. Mouse lag ftl.

[Decami]

You forgot the CPU limiting things.. and ram.. and etc...

as of recently though, there hasnt really been that much of a problem with bottlenecking in those areas, if you can afford it.

[Decami]

Ah yes, okay, so microstutter may not be an issue, but really.. how would the hydra chip know how much work to give each chip each frame? It can't know the chips bottlenecks or general performance and account for them in realtime.

There are all kinds of quality issues that would come into play too.. say 1 frame an older NVIDIA 6-series renders, the window or some texture. Then the next frame it's done by a newer 9-series. You'll get different image quality each frame? This is still totally not feasible.

If it were worth it, it would've been done by now. And you're right. Adding more latency into the process is a bad idea. Mouse lag ftl.

I see what your getting at, but it does work, has been demoed quite a few times, and tested by reviewers, its not like there no proof here. They have tested it with many different types of cards.

You do bring a good point about image quality on said card, and I for one am also curious about this.

But one thing you are hugely mistaken on.

If it were worth it, it would've been done by now.

not true at all, there are SO SO many things taht are hard to adapt to because of the market or pure greed.

Think about it...if your were a corporate company with share holders staring at you, would you choose SLI, or work on a tech like Hydra? The money would be in SLI, but only if the Hydra chip isnt in existence. Nvidia and ATI didnt want a better solution, casue to have SLI and Xfire you sell more new series cards, rather than giving the consumer a chance to use old ones already bought for multi GPU, which makes total sense on Intel funding this, they are just breaking into the market with GPU and need something to combat SLI/Xfire, to the grave, and this is it. Whether they will end up making decisions ultimately with the project is yet to be determined.

The quote you said is what we wish was reality, but in reality, its not true. Money controls market, not accommodation, or simplicity, or efficiency.

Honda jsut recently finally made a Hydrogen car that is no different than a normal car, an accord, top speed 125, 0-60 in 9 seconds, blah blah blah, same as any other car, but runs on Hydrogen, they are the first to do it, now how long do you think this will take to become the normal car? Im guessing damn near till oil runs out.

Hell cars that fly are closer than you think if some scientists would take the time to do it, but they are in no hurry, cause it would crush alot of market, tires for instance and other things.

Same goes for the Hydrogen car, one moving part, no oil changes, less maintenance=mechanics out of work, and so on.

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

[Sr7]

I see what your getting at, but it does work, has been demoed quite a few times, and tested by reviewers, its not like there no proof here. They have tested it with many different types of cards.

You do bring a good point about image quality on said card, and I for one am also curious about this.

But one thing you are hugely mistaken on.



not true at all, there are SO SO many things taht are hard to adapt to because of the market or pure greed.

Think about it...if your were a corporate company with share holders staring at you, would you choose SLI, or work on a tech like Hydra? The money would be in SLI, but only if the Hydra chip isnt in existence. Nvidia and ATI didnt want a better solution, casue to have SLI and Xfire you sell more new series cards, rather than giving the consumer a chance to use old ones already bought for multi GPU, which makes total sense on Intel funding this, they are just breaking into the market with GPU and need something to combat SLI/Xfire, to the grave, and this is it. Whether they will end up making decisions ultimately with the project is yet to be determined.

The quote you said is what we wish was reality, but in reality, its not true. Money controls market, not accommodation, or simplicity, or efficiency.

Honda jsut recently finally made a Hydrogen car that is no different than a normal car, an accord, top speed 125, 0-60 in 9 seconds, blah blah blah, same as any other car, but runs on Hydrogen, they are the first to do it, now how long do you think this will take to become the normal car? Im guessing damn near till oil runs out.

Hell cars that fly are closer than you think if some scientists would take the time to do it, but they are in no hurry, cause it would crush alot of market, tires for instance and other things.

Same goes for the Hydrogen car, one moving part, no oil changes, less maintenance=mechanics out of work, and so on.

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

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.

[Xoulz]

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.

Bro..

The GPU is now thee Hydra chip, when you mount a new video card to the subsystem, it knows what it's those card's capabilities are, and then the Hydra chip sends tasks to it.... except now, the Hydra chip uses as many ROP/Texture Units/Stream Processors as you have...!

How hard is it to understand, that the Hydra chip is a microprocessor that control the PCIe bus and ferret out's the hardware and makes it it's b!tch..!


You simply cannot understand, because you have not look at this objectively, but as a naysayer, like always..!





.

[Manicdan]

i dont think the hydra uses SFR, split frame is the idea of rendering half the pixels (top half vs bottom half), not half the work. no CF or SLI idea seems to do anything like what the hydra is doing. and i wouldnt be too worried about latency issues. its not trying to send gigbytes of bandwidth of textures to each card, it just tells the card which to render. the end result after AA and AF is applied can quickly be moved around with almost no lag. and besides who says there wont be driver updates so the hydra knows what its working with better. i am 100% for this idea over any CF or SLI solution, im tired of throwing away my old cards

[Shintai]

Bro..

The GPU is now thee Hydra chip, when you mount a new video card to the subsystem, it knows what it's those card's capabilities are, and then the Hydra chip sends tasks to it.... except now, the Hydra chip uses as many ROP/Texture Units/Stream Processors as you have...!

How hard is it to understand, that the Hydra chip is a microprocessor that control the PCIe bus and ferret out's the hardware and makes it it's b!tch..!


You simply cannot understand, because you have not look at this objectively, but as a naysayer, like always..!

.

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.

[bonobo]

The HYDRA 100 Series is available now for customer validation with volume delivery expected in Q4 2008. Consumer level devices are expected to reach the market in the first half of 2009.

from the august Lucid news

If this is true, intel may be able to deliver or announce a new board soon.

I hope so ...

[bonobo]

Were can i find a video from this demo ?
I am really curious to see how the load is balanced and if the object are redistributed often ...

[Zaskar]

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?