All the objects are already loaded into directX/openGL, only a few tweaks to tell it to render some extra pieces would be necessary
Most games/3d apps do view frustum culling of geometry before sending the geometry to OpenGL/DirectX. This means that not all the geometry required to render a 360 view is available without tweaking the application itself; which I may add is non-trivial.
both Xbox and Wii were designed/manufactured by ATI... Correction. ATI didn't design the XBox, nor the Wii. They designed the graphics processors within Xbox and Wii. Furthermore, ATI licensed the IP for these designs, so they don't manufacture the processors. Microsoft and Nintendo handle this themselves.
you see how PS3 is selling? nVidia got the short straw this round. That remains to be seen. The net profit to each graphics company, for each console sale, is dependent on the particular deals they made. Selling more of one console doesn't necessarily mean more profit for that graphics company. Furthermore, consoles typically have a 5 year lifespan. Sales of PS3 over the whole lifetime of the product is what ultimately matters.
they got shunned the last round of consoles for IBM and ATI, and Microsoft pretty much let ATI write the book for DX10 this round. Last I checked, the graphics in PS3, a.k.a. RSX, was NVIDIA designed.
Wow, another Slashdotter getting modded up for pointing out that another Slashdotter is getting modded up for pointing out that correlation != causation.
Sorry, you're right with these definitions. I was using the meaning of coherency generally used within graphics research, which is used interchangably with locality.
I've seen the topic of realtime ray-tracing and hardware accelerated ray-tracing come up countless times over the past 15 years. In the 80's and 90's, a realtime ray-tracing acceleration chip was always around the corner. Some products did actually emerge, but never quite caught on. The reason for this is not because "commercial graphics industry has been intent on pushing raster-based graphics as far as they could go". Quite the contrary; it's much more elegant algorithmically (and hence 'easier') to implement a ray-tracer than a scanline based renderer. However, there's a fundamental limitation of ray-tracing that make it unappealing performance-wise. Cache coherence for ray-tracers suck.
All rendering algorithms boil down to a sorting problem, where all the geometry in the scene is sorted in the Z dimension per pixel or sample. Fundamentally, scanline algorithms and ray-tracing algorithms are the same. For primary rays, here's some simpliefied pseudocode:
foreach pixel in image
trace ray through pixel
shade frontmost geometry
The trace essentially sorts all the geometrty along its path.
A scanline algorithm looks like this:
foreach geometry object in the scene
foreach pixel geometry is in
if geometry is in front of whatever is in the pixel already
shade fragement of geometry in pixel
replace pixel with new shaded fragment
As you can see, the only distinction is the order of the two loops. For ray-tracing, traversing the pixels is in the outer loop, and the geometry in the inner loop. For scanline rendering, it's the opposite. This has huge consequences in terms of cache coherency. With scanline methods, since the same object is being shaded in the inner loop, and neighboring fragments of the same object are being shaded, cache coherency tends to be extermely high. The same shader program is used, and likelyhood of the texture being accessed from cache is very good. The same can't be said for ray-tracing. You can shoot two almost identical rays but touch wildly different parts of the scene. Cache coherency relative to scanline rendering is abysmal.
This one performance side-effect of ray-tracing is the only reason we haven't seen any serious ray-tracing for realtime applications. Even in offline rendering, scanline rendering dominates even though software ray-tracing has been available from the beginning of CG. For ray-tracing to become viable, we need more than just more CPU cores. We need buses fast enough to feed all the cores in situations where we have an extremely high ratio of cache misses. Unfortunately, the speed gap between memory speeds and compute power seems to be increasing in recent years.
owever, when the content providers decide to provide everything in DRMed format, and electronics manufacturers only provide DRM-ready equipment, its game over.
Not necessarily. At some point this DRMed content has to become Analog in order to view it or hear it. There will always be some method for pirates to resample the material and distribute it DRM free. If done right, there could be no perceptable loss of quality, which is good enough for most people. This will always be fairly simple to do.
The more advanced hackers will always find some way to hack the DRMed equipment in order to gain access to the unencrypted digital signal. Those pirates will be able to distribute the content without any loss.
If DRM is crammed down everyones throat, it will be similar to copy-protection in games. Game developers/publishers are extact when their game takes "only" 21 days for a "complete" crack. "Complete" meaning with no bugs resulting from the crack. DRM cracking will always be easier, because each media format will only have one system to crack, unlike games which all differ.
But Most of the users that are currently switching are users that allready used browsers other than IE (That is, Opera, Mozilla Suite, Netscape, etc. users)
If all people switching to Firefox are coming from alternative browsers to IE, then why has IE's marketshare dropped?
We will be talking about the victory of Free Software when people understands why Free Software is important, and why proprietary software shouldn't be used, and NOT when some specific piece of Free Software gains marketshare.
Why is it necessary for "everyone" to understand why free software is good? As long as free software has enough marketshare to receive attention from developers and the industry in general, we all benefit.
Re:Hardcore gamers only
on
SLI Primer
·
· Score: 1
SLI also provides a nice upgrade path in the future. As new cards are introduced, the existing ones drop in price. Often it will end up being cheaper to just add a second card over replacing it entirely when you look at the price/performance ratio.
Previous winners of the Free Software Award
* 2003 Alan Cox
* 2002 Lawrence Lessig
* 2001 Guido van Rossum
* 2000 Brian Paul
* 1999 Miguel de Icaza
* 1998 Larry Wall
I agree with everyone on this list of gread free software contributors, but it's certainly conspicuous that Linus is missing from it.
These workstation class card offer more than just speed. They have special features enabled that are useful only for workstation applications. Features like anti-aliased line drawing, useless for games, but critical for CAD and similar workstation apps.
Actually, these cards strictly speaking are often slower versions of their gaming counterparts. FPS is not as important for workstation purposes. Most cards are fast enough to display the datasets needed in most workstation apps. When you buy one of these cards, you're paying for the extra effort that went into making special features in the GPU and drivers for this small market.
At the end of the day, it's not that much money for the compnaies who need these cards. The average salary of the engineer or artist using it far outweighs the cost of the card. Especially considering these same companies were buying SGI workstations costing $30k+ less than ten years ago.
This is a classic "chicken or egg" problem in the graphics industry. Game developers develop games that will maximize the features on existing cards while GPU and card manufacturers design GPUs and video cards that will maximize the performance and quality of existing games.
However, the hardware companies have to occasionally produce cards that have features not used by existing games so game developers can start developing games that push the envelope.
Maybe the advertisers aren't aiming for those who blocked the popups themselves. Maybe they are thinking of users who had popup blocking installed for them by and administrator at work or a friend or family member at home. Such people won't even realize popups were being blocked if somebody else administrates for them.
When you link into a dynamic library on most modern OSs you don't necessarily load the whole library into ram. Generally the library is memory mapped into the process address space and is lazily pulled into physical memory using the virtual memory system provided by the combination of the OS and MMU in your CPU.
The same is true of your executable. Only the parts of the executable that are touched during execution are actually loaded into physical ram. That's why deleting an executable while a process is running it is no allowed or causes the process to fail.
Now that we've found applications for which we do need 4 gigs of ram, what kind of apps would it take to use 18.4 million terabytes? Coming from a high-end computer graphics standpoint I find that increased RAM generally affords me more flexibility and possibilities when designing algorithms than does extra CPU power. A great many optimizations are possible with 3D rendering when you can afford large caches and data structures. These optimizations can increase speed perforamance by orders of magnitude as opposed to the fractional speed increases we get from newer chips with higher clockspeeds. In general, any heavy computation on large data sets such as those found in computer graphics, science, medicine, etc... will benefit greatly from paradigm shifts in availble in a variety of subtle ways. Since available RAM in our machines seems to be increasing faster than CPU speeds we can opt to waste more RAM when trying to find the critical balance between speed and memory usage in our algorithms. Also, it is important to note that although many applications don't need to simultaneously access a lot of memory they could benefit from mapping a large data set into memory in order to avoid manually swapping the data. An example of this is the large data sets that are used in 3D rendering. These data sets often contain a lot of detailed geometry and high resolution textures. A given rendering algorithm probably doesn't need all of the textures and geometry when rendering a portion of the final image, but it's nice when you can mmap() the texture files and geometry into you r address space and not worry about loading and swapping the data manually. These data sets can easily grow larger than 4 gigs making it impossible to map the whole data set in to your process. It's always nice to have more headroom in your virtual memory space than you have in physical ram.
Slashdot Mirror
All the objects are already loaded into directX/openGL, only a few tweaks to tell it to render some extra pieces would be necessary
Most games/3d apps do view frustum culling of geometry before sending the geometry to OpenGL/DirectX. This means that not all the geometry required to render a 360 view is available without tweaking the application itself; which I may add is non-trivial.
It won't submit with JavaScript disabled. Try enabling it.
Wow, another Slashdotter getting modded up for pointing out that another Slashdotter is getting modded up for pointing out that correlation != causation.
Sorry, you're right with these definitions. I was using the meaning of coherency generally used within graphics research, which is used interchangably with locality.
I've seen the topic of realtime ray-tracing and hardware accelerated ray-tracing come up countless times over the past 15 years. In the 80's and 90's, a realtime ray-tracing acceleration chip was always around the corner. Some products did actually emerge, but never quite caught on. The reason for this is not because "commercial graphics industry has been intent on pushing raster-based graphics as far as they could go". Quite the contrary; it's much more elegant algorithmically (and hence 'easier') to implement a ray-tracer than a scanline based renderer. However, there's a fundamental limitation of ray-tracing that make it unappealing performance-wise. Cache coherence for ray-tracers suck.
All rendering algorithms boil down to a sorting problem, where all the geometry in the scene is sorted in the Z dimension per pixel or sample. Fundamentally, scanline algorithms and ray-tracing algorithms are the same. For primary rays, here's some simpliefied pseudocode:
foreach pixel in image
trace ray through pixel
shade frontmost geometry
The trace essentially sorts all the geometrty along its path.
A scanline algorithm looks like this:
foreach geometry object in the scene
foreach pixel geometry is in
if geometry is in front of whatever is in the pixel already
shade fragement of geometry in pixel
replace pixel with new shaded fragment
As you can see, the only distinction is the order of the two loops. For ray-tracing, traversing the pixels is in the outer loop, and the geometry in the inner loop. For scanline rendering, it's the opposite. This has huge consequences in terms of cache coherency. With scanline methods, since the same object is being shaded in the inner loop, and neighboring fragments of the same object are being shaded, cache coherency tends to be extermely high. The same shader program is used, and likelyhood of the texture being accessed from cache is very good. The same can't be said for ray-tracing. You can shoot two almost identical rays but touch wildly different parts of the scene. Cache coherency relative to scanline rendering is abysmal.
This one performance side-effect of ray-tracing is the only reason we haven't seen any serious ray-tracing for realtime applications. Even in offline rendering, scanline rendering dominates even though software ray-tracing has been available from the beginning of CG. For ray-tracing to become viable, we need more than just more CPU cores. We need buses fast enough to feed all the cores in situations where we have an extremely high ratio of cache misses. Unfortunately, the speed gap between memory speeds and compute power seems to be increasing in recent years.
It sounds like this scheme would alter the size of the original text. Don't most schemes compare the hash and the size of the text?
Not necessarily. At some point this DRMed content has to become Analog in order to view it or hear it. There will always be some method for pirates to resample the material and distribute it DRM free. If done right, there could be no perceptable loss of quality, which is good enough for most people. This will always be fairly simple to do.
The more advanced hackers will always find some way to hack the DRMed equipment in order to gain access to the unencrypted digital signal. Those pirates will be able to distribute the content without any loss.
If DRM is crammed down everyones throat, it will be similar to copy-protection in games. Game developers/publishers are extact when their game takes "only" 21 days for a "complete" crack. "Complete" meaning with no bugs resulting from the crack. DRM cracking will always be easier, because each media format will only have one system to crack, unlike games which all differ.
If all people switching to Firefox are coming from alternative browsers to IE, then why has IE's marketshare dropped?
Why is it necessary for "everyone" to understand why free software is good? As long as free software has enough marketshare to receive attention from developers and the industry in general, we all benefit.
SLI also provides a nice upgrade path in the future. As new cards are introduced, the existing ones drop in price. Often it will end up being cheaper to just add a second card over replacing it entirely when you look at the price/performance ratio.
Actually, clockspeeds are often lower than the game card counterparts. Mostly they're just enabling workstation specific features.
These workstation class card offer more than just speed. They have special features enabled that are useful only for workstation applications. Features like anti-aliased line drawing, useless for games, but critical for CAD and similar workstation apps.
Actually, these cards strictly speaking are often slower versions of their gaming counterparts. FPS is not as important for workstation purposes. Most cards are fast enough to display the datasets needed in most workstation apps. When you buy one of these cards, you're paying for the extra effort that went into making special features in the GPU and drivers for this small market.
At the end of the day, it's not that much money for the compnaies who need these cards. The average salary of the engineer or artist using it far outweighs the cost of the card. Especially considering these same companies were buying SGI workstations costing $30k+ less than ten years ago.
This is a classic "chicken or egg" problem in the graphics industry. Game developers develop games that will maximize the features on existing cards while GPU and card manufacturers design GPUs and video cards that will maximize the performance and quality of existing games.
However, the hardware companies have to occasionally produce cards that have features not used by existing games so game developers can start developing games that push the envelope.
Maybe the advertisers aren't aiming for those who blocked the popups themselves. Maybe they are thinking of users who had popup blocking installed for them by and administrator at work or a friend or family member at home. Such people won't even realize popups were being blocked if somebody else administrates for them.
When you link into a dynamic library on most modern OSs you don't necessarily load the whole library into ram. Generally the library is memory mapped into the process address space and is lazily pulled into physical memory using the virtual memory system provided by the combination of the OS and MMU in your CPU.
The same is true of your executable. Only the parts of the executable that are touched during execution are actually loaded into physical ram. That's why deleting an executable while a process is running it is no allowed or causes the process to fail.
Now that we've found applications for which we do need 4 gigs of ram, what kind of apps would it take to use 18.4 million terabytes? Coming from a high-end computer graphics standpoint I find that increased RAM generally affords me more flexibility and possibilities when designing algorithms than does extra CPU power. A great many optimizations are possible with 3D rendering when you can afford large caches and data structures. These optimizations can increase speed perforamance by orders of magnitude as opposed to the fractional speed increases we get from newer chips with higher clockspeeds. In general, any heavy computation on large data sets such as those found in computer graphics, science, medicine, etc... will benefit greatly from paradigm shifts in availble in a variety of subtle ways. Since available RAM in our machines seems to be increasing faster than CPU speeds we can opt to waste more RAM when trying to find the critical balance between speed and memory usage in our algorithms. Also, it is important to note that although many applications don't need to simultaneously access a lot of memory they could benefit from mapping a large data set into memory in order to avoid manually swapping the data. An example of this is the large data sets that are used in 3D rendering. These data sets often contain a lot of detailed geometry and high resolution textures. A given rendering algorithm probably doesn't need all of the textures and geometry when rendering a portion of the final image, but it's nice when you can mmap() the texture files and geometry into you r address space and not worry about loading and swapping the data manually. These data sets can easily grow larger than 4 gigs making it impossible to map the whole data set in to your process. It's always nice to have more headroom in your virtual memory space than you have in physical ram.