unlimited shader length in Radeon 9600, Radeon 9800?

[madshi]

http://www.theinquirer.net/?article=8062

Well, it's the inquirer, but the infos sound pretty solid.

This one sounds interesting:

The 350s have a very special F buffer for storing temporal pixel shader data, it allows for "virtually unlimited" pixel shader length, meaning full OpenGL 2.0 fragment shading and possibly also Renderman shaders, all in hardware.

 

[Nebuchadnezzar]

I don't know what to say.

Would totally kill Nvidia...




EDIT: Added 'would' in italic

 

[Brent]

 

[Luminescent]

 

[Ilfirin]

 

[Dingly Dell]

http://graphics.stanford.edu/projects/shading/pubs/hwws2001-fbuffer/talk-html/

 

[demalion]

A certain "undulating" personality around here hinted at something similar, so I tend to believe the comment isn't just a marketing-speak version of 128-bit FP buffers.

But I don't know what it is...large cache + virtual memory system for shaders? Would the P10 and descendents also have unlimited shader length?

I don't think it is really significant except for bragging rights, or atleast it isn't except for any other things that go along with it like improved shader execution speed...

I'm sure Carmack could find it useful for his experimentation, based on what he has said, and it can certainly steal some "Cinematic Shading" thunder (but I'm not cognizant of the significance of that initiative as of yet), but other than press releases, how do you really show it off?

I'd be much more interested in some other details about it in comparison to the R300.

 

[Pete]

Nvidia should perhaps call its own DX9 extensions DX9## or DX9.NET.

 

[3dcgi]

http://graphics.stanford.edu/projects/shading/pubs/hwws2001-fbuffer/talk-html/

FYI. The guy that gave that presentation works for Nvidia now.

 

[RoOoBo]

http://graphics.stanford.edu/projects/shading/pubs/hwws2001-fbuffer/talk-html/

Just skimming the paper and slides, but in which form is that different from the R300 4 render targets (pixel shader output to float point textures)? The paper even states in the section '5.4 Where does F-Buffer data enter the fragment pipeline?' that texture units could be used to access F-Buffers as inputs.

I guess (and taking into account that the source is TheInquirer) that there isn't something new in R350. Maybe now the drivers are able to auto multipass long shaders using the render targets. I wonder if some kind of hardware could be used to avoid the need to pass geometry again for the multiple passes, something like the hability of a fragment to 'loop' over the pixel shaders with different programs. The output fragment would be send to the fragment FIFO again with a pointer to a new pixel shader program, however it would be very inefficient if the new pixel shader program must be loaded from memory each time (somekind of scheduling and batching of fragments taking into account which shader programs are used would be needed).

 

[Mark]

I'll put this as simply as possible: It's true

 

[madshi]

Hmmm... That's interesting. The direct link still works, but currently the inquirer's front page doesn't list the article anymore. 8)

 

[Nebuchadnezzar]

That's even more strange...

 

[Hyp-X]

Just skimming the paper and slides, but in which form is that different from the R300 4 render targets (pixel shader output to float point textures)?

The elements in this buffer are in rasterization order.
It's a serial buffer.

While you could read them back using a texture unit it works differently form standard texturing - as you don't need texture coordinates, you just read the buffer sequentially.

It needs hardware support - but it's should be very cheap to implement.

I beleive that there can be shaders that runs faster with F-buffering multipassing than in single pass.
If you have a lot of texture accesses in a single pass it can kill you texel cache!

 

[demonic]

All I want to see, is ATi to get Dawn running on the R9800..

That in a single moment, would kill the GFFX.

 

[UncleSam DL iXBT]

While you could read them back using a texture unit it works differently form standard texturing - as you don't need texture coordinates, you just read the buffer sequentially.

It needs hardware support - but it's should be very cheap to implement.

I beleive that there can be shaders that runs faster with F-buffering multipassing than in single pass.
If you have a lot of texture accesses in a single pass it can kill you texel cache!

yep you right

this is

1. splitting parser in driver
2. this a kind of hardware loopback buffer for parameters as you say
3. and hardware piping and caching of shader microcode parts from local memory like nv30

so we can do randerman but yet without arbitary mem access

wait for DX11
i think arbitary vertex access and generation will be here at DX10 - so for 50/500

 

[megadrive0088]

for DX11
i think arbitary vertex access and generation will be here at DX10 - so for 50/500

i take it that 50/500 means Nvidia NV50 and ATI R500?
(which are in development now)

 

[Nebuchadnezzar]

for DX11
i think arbitary vertex access and generation will be here at DX10 - so for 50/500

i take it that 50/500 means Nvidia NV50 and ATI R500?
(which are in development now)

Ermm, I think neighter is in development...

 

[epicstruggle]

ATI will call the extended set of DX9 features the DX9++, although we suppose it could add just as many ++++++ as it wanted to.

YOu have got to love the inq for their colorfull techincal talk.

later,

 

[UncleSam DL iXBT]

Ermm, I think neighter is in development...

yep its nv50 and r500

its simply - DX10 in development now and tendences are pretty predictable. when dx10 development starts - starts development of ARCHITECTURE (not realization that is chip but architecture).

so some capabilities already clear

i think nv40 in _chip development now and nv50 in architecture investigations and feautures development.