Want F-Buffer?
- Thread starter Ilfirin
- Start date
I thought the point of the F-Buffer was that it was transparent: it makes a card with limited pixel shader count appear to be a card that supports an unlimited length.
Why does the API even need to know about it? Couldn't the ATI drivers just report they support pixel shaders 1000+ instructions long, and if the driver receives such a long shader, it automatically enables the F-Buffer to process it?
Why does the API even need to know about it? Couldn't the ATI drivers just report they support pixel shaders 1000+ instructions long, and if the driver receives such a long shader, it automatically enables the F-Buffer to process it?
The API DOESN'T need to know about it, the driver has to support it. But that doesn't really answer your question.
The primary problem, I think, is that DX9 sets an upper bound on the number of instructions you can support for each PS version. You can't have more than 96 instructions in PS2.0, 512 in PS2.x, 32,768 in PS3.0, but the differences between the seperate PS modes are more than just instruction counts. There's also added instructions, and pixel shading capabilities that the r350 doesn't support, so they can't just report PS2.x and/or ps3.0 capability, and any ps2.0 shader with more than 96 instructions won't make it past the validation step. So I'm not really sure how they are going to do it, probably through a HWSM-esque hackjob.
The primary problem, I think, is that DX9 sets an upper bound on the number of instructions you can support for each PS version. You can't have more than 96 instructions in PS2.0, 512 in PS2.x, 32,768 in PS3.0, but the differences between the seperate PS modes are more than just instruction counts. There's also added instructions, and pixel shading capabilities that the r350 doesn't support, so they can't just report PS2.x and/or ps3.0 capability, and any ps2.0 shader with more than 96 instructions won't make it past the validation step. So I'm not really sure how they are going to do it, probably through a HWSM-esque hackjob.
It doesn't work currently.. that's what this thread is about 
Yes, when I asked them back when the 9800Pro was first announced they told me OGL2 only as well (as did an ATI guy in reply to the message quoted in my first post at the original location), but Huddy says if they get enough support they'll move it to DX.
Yes, when I asked them back when the 9800Pro was first announced they told me OGL2 only as well (as did an ATI guy in reply to the message quoted in my first post at the original location), but Huddy says if they get enough support they'll move it to DX.
Someone on the OpenGL.org forums was hacking through the OpenGL ICD recently and noted a few new extension strings: GL_GL2_fragment_shader, GL_GL2_vertex_shader, GL_GL2_shader_objects, GL_ATI_uber_buffers, and GL_ATI_il_fshader.
The last one is the only ambiguous one. I guess il fshader could stand for "Infinite Length Fragment Shader", though. I doubt it's a whole new rewriting of GL_ARB_fragment_program and I think it's probably switch that allows one to toggle F-Buffers.
Here's the thread:
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009738.html
The last one is the only ambiguous one. I guess il fshader could stand for "Infinite Length Fragment Shader", though. I doubt it's a whole new rewriting of GL_ARB_fragment_program and I think it's probably switch that allows one to toggle F-Buffers.
Here's the thread:
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009738.html
Then the F-Buffer would be pointless. If it were to require an entire redefinition of ARB_fragment_program, like NV_fragment_program is, it would be a step backward.AndrewM said:
There are two reasonable possibilities that I see: toggled in the application and toggled in the driver. The former means that there must be at least some specific support for it in the application, but it is minimal and does not require a shading path different from a standard ARB-based one (ARB2, in Doom 3's terms). The latter means that regardless of what the application wants, the F-Buffer is enabled for use if it is required.
Actually, I hope that both exist: sorta like how FSAA, Anisotropic Filtering, and V-Sync are handled. Each of those features can be enabled by the application, or they can be forced via the drivers.
Well, they certainly haven't released as many as NVidia, but there's been 7 since the Radeon 9700 came out. Almost all of the advanced functionality that ATI cards support is available through the current suite of extensions.
This is news to me. I don’t know much about DX, but it sounds all wrong to me. AFAIK there is no upper instruction limit, or at least not such low ones.Ilfirin said:
1. The reason the r300 reports max 96 instructions is because it can only handle up to 160 in certain situations, so it has to report 96.
2. The reason the GFFX reports 512 instead of 1024 is because every time a constant is used it takes one extra instruction slot so they have to report 512.
Neither has anything to do with any limits set by DX9. In fact 96 instructions is the minimum instruction limit allowed for PS2, not the maximum.
This is all AFAIK, so I would appreciate some input on this from you guys.
Thowllly said:Ilfirin, thanks for clearing that up. Seems weird I think, but if MS wants to shoot themselves in the foot by introducing artificial limits, then they should be free to do so...
I think it was more that ATI was pushing them, as they did for the OpenGL ARB_fragment_program (which ATI lead the working group - this was a mistake).
Face it, there WILL be multiple paths in engines, which I dont have a problem with (being programmer myself)
I don't think they are "shooting themselves I T F" but preventing IHVs and ISVs from wanting to do the shootingThowllly said:Ilfirin, thanks for clearing that up. Seems weird I think, but if MS wants to shoot themselves in the foot by introducing artificial limits, then they should be free to do so...
The minimum is there, presumably, so that the ISVs know that they can make their shaders at least as complex as the min, while the max is there so that IHVs have a gate budget they can aim for (if they choose).
Ilfirin said:
Emphasis mine. I think it's safe to say just about everyone wants this feature in DX, so let's let them hear it
This was a request for comments from developers. "Everyone" (end users) can't care less about whether or not this feature exists in DX, if the developers don't use it. SO please spare Mr. Huddy's mailbox unless YOU are developing a game which would benefit from huge (say 1000-2000) shaders.
And no, the ability to discuss meaningless shader benchmarks which calculate mandlebrot sets or the digits of Pi doesn't count as "we need this feature in DX".
In case you haven't realized, this forum is full of developers of all types (games, benchmarks, demos, etc). Those are the people I was addressing.
[Edit] This was also the explicit reason why I left his e-mail address out of the message - anyone in a position to ask for this already knows it, or knows where to find it.
[Edit] This was also the explicit reason why I left his e-mail address out of the message - anyone in a position to ask for this already knows it, or knows where to find it.