First off, ATI and Nvidia have understood the concept of gen-locking for ages, and some of their ultra-high-end boards have provided this capability. They've been used in research and high-end visualization setups where you've got multiple projector output and gen-locking is required.
Second, Alienware is not exactly using generic off-the-shelf hardware. Can you find a PCI Express video card on any shelf? I'm sure they've worked with their vender in order to find out how to gen-lock the cards, in addition to discussing how to modify the display drivers.
Finally, did you look at the pictures that accompanied the article? If so, you'll see that there's an extra cable that goes from each video card to the combiner card. I'll wager that's the gen-lock cable.
(Actually, one of their setups appears to be running without a combiner card. It's driving two separate screens, so they may indeed have a sync problem with that setup.)
It really depends upon the amount of rasterization work compared to the amount of geometry work being done. If you take a game that uses lots of long pixel shaders and bump up the resolution, I'm sure you won't have that much trouble achieving a good speedup. On the other hand, if you have highly-detailed geometry, simple pixel shaders, and not-so-high resolution, this probably won't help you much (assuming that you don't have efficient culling in your APIs).
Also, a 4-way screen-subdivision system will typically be half as efficient (regarding the geometry work) as a 2-way system. It has twice the border length, and therefore twice the number of primitives that straddle the borders (on average, depending on the application).
That's why gen-locking or some other form of synchronization is needed. Essentially, there's just one master clock, and its signal is sent to both (or however many) cards.
Two cards are not twice as fast as one. The two cards are indeed faster than one, but not twice as fast. That's because screen-space subdivision cannot be 100% efficient; there's always duplication of work for geometry that falls across the border. And indeed, if your APIs don't support efficient culling, then perhaps all of the geometry may have to be processed twice, degrading your efficiency even more. As well, the more borders you have (by having more graphics cards), the worse your efficiency gets.
Rendering is indeed inherently parallelizable, but most of the "efficient" parallelization is already being done on a single graphics cards. They've got multiple processors working on the geometry vertices, and multiple processors working on the pixels. (Still probably just one tiler working in between those two steps, though.)
The further "up" the pipeline you go, the less efficient parallelization tends to be. Of course, it all really depends upon how you subdivide the work. People have written PhD theses on this problem, in fact. Just do a google search on "sort-first, sort-middle, sort-last" to see some ways of going about the problem.
The problem with SLI is that it only subdivides the rasterization work. Both cards must still process all the geometry (and lighting calculations). (Actually, the 3dfx cards which could do SLI did not have a geometry transform engine; regardless, the triangle-setup work is still all duplicated.)
Screen-space subdivision (ala Alienware) can subdivide the geometry work as well as the rasterization work. However, there will still be a lot of geometry work being duplicated, since you don't know where a polygon will end up until you've transformed it.
If the APIs supported it, you could cut down on some of this duplication (say by using bounding boxes on groups of geometry, and only sending the groups to the necessary cards based upon the bounding box tests). Even so, it's impossible to eliminate some duplication, and thus no system using screen-space subidivision will be 100% efficient.
I would wager it's done by changing the viewport setting on each card. The viewport controls the mapping of the viewing frustum onto the screen.
The compositor card is just a video switch. At the horizontal retrace interval where the subdivision is, it switches from one card's output to the other's. It's probably setup to count retrace intervals and do the switching itself, rather than being interrupt-driven. (I don't think horizontal retrace interrupts are supported by most video cards.)
They are using gen-locked video compositing, so there's no pixel traffic at all. The video outputs from both cards go into a combiner card, which switches between the two at the horizontal retrace interval where the screen division is.
There was a picture of the setup at some other site where this system was mentioned a couple weeks ago.
If a product is just a small incremental improvement over the current one, why would you buy it? What percentage of current GameBoy owners would buy a product that's just a bit thinner with with just a bit larger screen?
(Granted, Nintendo did this once with "GameBoy Pocket". But the SP is already pretty small.)
When I first read the "prop" part, I imagined those prop computers you see in furniture stores. You know, those plastic computer shells that resemble a generic computer (though lately Ikea seems to be using actual gutted computer cases).
In any case, I thought it would be hilarious to take something that was designed to look like a computer but not be one and make it into a computer. Or a toaster. Or anything functional.
You know that ATM machines are pretty reliable and generally difficult to hack. After all, if it handles money, you can pretty much guarantee that there's a large vested interest in making it hackproof. Casino slot machines also fall into this category.
Given that, then instead of making "voting machines that are as easy to use as ATM machines", why not just make "ATM machines that you can vote with"? ATM machines already have paper trails built in. To make the voting part (of the software) secure, just tie a big enough financial incentive to it.
Anyway, just another idea to throw onto the pile. Perhaps if Diebold were unquestionably financially liable for their goofs, we wouldn't be in this mess in the first place. Why isn't it that tampering with one of our most fundamental institutions isn't a bigger crime than it is? I suppose that that would fill the jails with all the lobbyists and their corporate sponsors and their personal politicians.
I agree. Around that time I (my father, actually) spent $100 to do the same upgrade (8 4116 chips) for an Apple II (not II+ or IIe). I believe the original Apple price for the 16K upgrade was $400. Third parties were initially selling the chips for $200. I held off until the $100 price point.
The use of the 10MB of EDRAM is shown in the picture. It contains the back framebuffer (including Z and alpha). Main memory contains the textures and the (front) buffer being scanned out. This last fact is also shown in the picture (the video output scalar reads from the Northbridge).
So the only thing that might be "virtual" is texture memory. Obviously there must be an undocumented texture cache in the GPU (to do the 16 bilinear texture fetches per cycle from).
"Prepare to be assimilated. We will add your biological and technological distinctiveness to our own. You will adapt to service us. Resistance is futile."
Okay, so I could do without some of the grandstanding that goes on, but I like to see the various robot designs and how they stack up against each other. Maximum carnage!
Here's my idea for a killer robot design: make a 2-wheeled "stinger" type design that can move around while still spinning. You'd need some computer control to modulate the motors, and perhaps some kind of tracking system such that the robot can tell which way it's facing. But this would overcome the biggest weakness of this design: the fact that it can't move while executing a spin attack.
Slashdot Mirror
You need more than 10 reasons to reject it?
I only need one: it's dumb as hell!
First off, ATI and Nvidia have understood the concept of gen-locking for ages, and some of their ultra-high-end boards have provided this capability. They've been used in research and high-end visualization setups where you've got multiple projector output and gen-locking is required.
Second, Alienware is not exactly using generic off-the-shelf hardware. Can you find a PCI Express video card on any shelf? I'm sure they've worked with their vender in order to find out how to gen-lock the cards, in addition to discussing how to modify the display drivers.
Finally, did you look at the pictures that accompanied the article? If so, you'll see that there's an extra cable that goes from each video card to the combiner card. I'll wager that's the gen-lock cable.
(Actually, one of their setups appears to be running without a combiner card. It's driving two separate screens, so they may indeed have a sync problem with that setup.)
You didn't look at the downloads page:
> This is realtime speed for a virtual intel CPU with about 36 GHz (to be more precise: a cluster with 20 AMD XP1800 was used).
It really depends upon the amount of rasterization work compared to the amount of geometry work being done. If you take a game that uses lots of long pixel shaders and bump up the resolution, I'm sure you won't have that much trouble achieving a good speedup. On the other hand, if you have highly-detailed geometry, simple pixel shaders, and not-so-high resolution, this probably won't help you much (assuming that you don't have efficient culling in your APIs).
Also, a 4-way screen-subdivision system will typically be half as efficient (regarding the geometry work) as a 2-way system. It has twice the border length, and therefore twice the number of primitives that straddle the borders (on average, depending on the application).
That's why gen-locking or some other form of synchronization is needed. Essentially, there's just one master clock, and its signal is sent to both (or however many) cards.
Two cards are not twice as fast as one. The two cards are indeed faster than one, but not twice as fast. That's because screen-space subdivision cannot be 100% efficient; there's always duplication of work for geometry that falls across the border. And indeed, if your APIs don't support efficient culling, then perhaps all of the geometry may have to be processed twice, degrading your efficiency even more. As well, the more borders you have (by having more graphics cards), the worse your efficiency gets.
Rendering is indeed inherently parallelizable, but most of the "efficient" parallelization is already being done on a single graphics cards. They've got multiple processors working on the geometry vertices, and multiple processors working on the pixels. (Still probably just one tiler working in between those two steps, though.)
The further "up" the pipeline you go, the less efficient parallelization tends to be. Of course, it all really depends upon how you subdivide the work. People have written PhD theses on this problem, in fact. Just do a google search on "sort-first, sort-middle, sort-last" to see some ways of going about the problem.
Or, for a real-time version:
http://www.cs.princeton.edu/~rudro/sketch00.pdf
The problem with SLI is that it only subdivides the rasterization work. Both cards must still process all the geometry (and lighting calculations). (Actually, the 3dfx cards which could do SLI did not have a geometry transform engine; regardless, the triangle-setup work is still all duplicated.)
Screen-space subdivision (ala Alienware) can subdivide the geometry work as well as the rasterization work. However, there will still be a lot of geometry work being duplicated, since you don't know where a polygon will end up until you've transformed it.
If the APIs supported it, you could cut down on some of this duplication (say by using bounding boxes on groups of geometry, and only sending the groups to the necessary cards based upon the bounding box tests). Even so, it's impossible to eliminate some duplication, and thus no system using screen-space subidivision will be 100% efficient.
I would wager it's done by changing the viewport setting on each card. The viewport controls the mapping of the viewing frustum onto the screen.
The compositor card is just a video switch. At the horizontal retrace interval where the subdivision is, it switches from one card's output to the other's. It's probably setup to count retrace intervals and do the switching itself, rather than being interrupt-driven. (I don't think horizontal retrace interrupts are supported by most video cards.)
They are using gen-locked video compositing, so there's no pixel traffic at all. The video outputs from both cards go into a combiner card, which switches between the two at the horizontal retrace interval where the screen division is.
There was a picture of the setup at some other site where this system was mentioned a couple weeks ago.
If a product is just a small incremental improvement over the current one, why would you buy it? What percentage of current GameBoy owners would buy a product that's just a bit thinner with with just a bit larger screen?
(Granted, Nintendo did this once with "GameBoy Pocket". But the SP is already pretty small.)
Yes, I too thought that we were one step closer to real-life Transformers!
When I first read the "prop" part, I imagined those prop computers you see in furniture stores. You know, those plastic computer shells that resemble a generic computer (though lately Ikea seems to be using actual gutted computer cases).
In any case, I thought it would be hilarious to take something that was designed to look like a computer but not be one and make it into a computer. Or a toaster. Or anything functional.
Cool. I wasn't aware of that.
I suppose then that you can only count on the slot machines to be "unhackable".
You know that ATM machines are pretty reliable and generally difficult to hack. After all, if it handles money, you can pretty much guarantee that there's a large vested interest in making it hackproof. Casino slot machines also fall into this category.
Given that, then instead of making "voting machines that are as easy to use as ATM machines", why not just make "ATM machines that you can vote with"? ATM machines already have paper trails built in. To make the voting part (of the software) secure, just tie a big enough financial incentive to it.
Anyway, just another idea to throw onto the pile. Perhaps if Diebold were unquestionably financially liable for their goofs, we wouldn't be in this mess in the first place. Why isn't it that tampering with one of our most fundamental institutions isn't a bigger crime than it is? I suppose that that would fill the jails with all the lobbyists and their corporate sponsors and their personal politicians.
I'd be happy if all the former TechTV staff go and put together their own TV network for nerds. They could probably do a better job than Comcast.
I agree. Around that time I (my father, actually) spent $100 to do the same upgrade (8 4116 chips) for an Apple II (not II+ or IIe). I believe the original Apple price for the 16K upgrade was $400. Third parties were initially selling the chips for $200. I held off until the $100 price point.
The use of the 10MB of EDRAM is shown in the picture. It contains the back framebuffer (including Z and alpha). Main memory contains the textures and the (front) buffer being scanned out. This last fact is also shown in the picture (the video output scalar reads from the Northbridge).
So the only thing that might be "virtual" is texture memory. Obviously there must be an undocumented texture cache in the GPU (to do the 16 bilinear texture fetches per cycle from).
"Prepare to be assimilated. We will add your biological and technological distinctiveness to our own. You will adapt to service us. Resistance is futile."
I did it with even less code using my browser:
It was a given that the solution would appear.
So I can play the game on the cellphone while I drive? :-)
Okay, so I could do without some of the grandstanding that goes on, but I like to see the various robot designs and how they stack up against each other. Maximum carnage!
Here's my idea for a killer robot design: make a 2-wheeled "stinger" type design that can move around while still spinning. You'd need some computer control to modulate the motors, and perhaps some kind of tracking system such that the robot can tell which way it's facing. But this would overcome the biggest weakness of this design: the fact that it can't move while executing a spin attack.
Of course, Dish Network is now charging a "VOD fee" for their DVRs (unless you subscribe to the high-end package).
Naw, Tivo won't die. But eventually, only lawyers will be left at the company.
Ah, but remember the Morris Worm of 1988? A time when (BSD) Unix was king among servers (and clients), and one program made them all bow down.