Last edited:
Siggraph06 ati presentations
- Thread starter tEd
- Start date
nice heads up. I was wondering why we didnt have a few siggraph threads started yet. Anyways, ill be looking through the slides thanks to you. 
epic
epic
A lot of interesting papers, here.
This is good stuff:
http://www.ati.com/developer/siggra...ions_for_Lighting_of_Dynamic_Scenes-print.pdf
This is good stuff:
http://www.ati.com/developer/siggra...ions_for_Lighting_of_Dynamic_Scenes-print.pdf
For the GPGPU wonks:
http://www.ati.com/developer/siggraph06/dpvm_e.pdf
Low level hardware access is good...
http://www.ati.com/developer/siggraph06/dpvm_e.pdf
Low level hardware access is good...
Have you had a chance to play with the new API?
Yes, for awhile now as this is what a large part of my research involves. ;-)
Matrix multiply numbers jumped to 110GFlops (single precision sgemm, not counting GPU offload). Ray tracing also jumped a little. Mainly, you can get around all the overhead of GL/DX, and get access to extended features mentioned in Derek's talk (scatter, render to/texture from host, large register files, raw ISA, direct control of memory formats, etc). Scatter and render/texture from host aren't even in DX10.
This is what many of us in the GPGPU community have been asking (begging) about for awhile now.
Matrix multiply numbers jumped to 110GFlops (single precision sgemm, not counting GPU offload). Ray tracing also jumped a little. Mainly, you can get around all the overhead of GL/DX, and get access to extended features mentioned in Derek's talk (scatter, render to/texture from host, large register files, raw ISA, direct control of memory formats, etc). Scatter and render/texture from host aren't even in DX10.
This is what many of us in the GPGPU community have been asking (begging) about for awhile now.
It seems extremely architecture dependent to me. Won't this become a major issue when they release newer hardware generations?
I thought the same. But this is the price if you want go down to the metal.Maybe the next generation will still be compatible to the X1K ISA.
Yes, but to be fair, the only people doing GPGPU are already willing to go through a tremendous about of pain. This shifts the pain away from fighting with the driver and gives you consistency on a certain arch (X1k for example), but you now get to deal with arch changes.
You can also still write code in a higher level language, like HLSL, or to psuedo asm, ps_3_0, and let the vendors compile that. In fact, most of our apps thus far are done in HLSL->ps_3_0->X1k ISA. We only go direct to the ISA (often by patching the ps3) when we need larger register files or support for things which ps_3_0 doesn't support (scatter). However, if you write direct to the ISA, things may need to change.
But, when Intel/AMD release a new generation chip, hand coded asm needs to be redone (cache changes, updated SSE functionality, etc). But, your app will almost always still run unmodified, just not a peak on CPUs.
You can also still write code in a higher level language, like HLSL, or to psuedo asm, ps_3_0, and let the vendors compile that. In fact, most of our apps thus far are done in HLSL->ps_3_0->X1k ISA. We only go direct to the ISA (often by patching the ps3) when we need larger register files or support for things which ps_3_0 doesn't support (scatter). However, if you write direct to the ISA, things may need to change.
But, when Intel/AMD release a new generation chip, hand coded asm needs to be redone (cache changes, updated SSE functionality, etc). But, your app will almost always still run unmodified, just not a peak on CPUs.
chavvdarrr
Veteran
Is this info available? i.e. from where to download the detailed description of register/asm access, or it will be available?
