ATI guys: Two feature requests, R200, OGL extensions

[zeckensack]

I'm hitting a brick wall regarding what can be done under OpenGL (hint: see my signature). So I've taken a look at D3D8 lately and was quite surprised that the two things missing are exposed and hardware accelerated under DX8.1, but not under OpenGL.

1)big issue with ATI_fragment_shader
No PS1.0 texkill equivalent in OpenGL. Can be emulated with comparison and alpha test, but this obviously cannibalizes the latter.
Depth replace instructions are not exposed under OpenGL, yet they are available under D3D.
I'd really like to see these exposed in a respin of the fragment_shader spec, the most important being the full set of depth replace for comparison only/for comparison and write.

2)small issue with swapping chain wrt triple buffering
This is more a lobbying request. ARB_pixel_format defines a swap behaviour attribute, but this has IMHO broken semantics in a triple buffered context. (exchange semantics don't make sense with more than two buffers, we need a WGL_blabla_flip attribute with circular pointer swap semantics)

Details (and a somewhat clunky explanation) here:
http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000307.html

Again, this is an area that is completely under program control under D3D8 but not under OpenGL (although the 'vehicle' to expose it is already there). I'd be grateful if you could lend me some of your ARB influence

In closing, I'm aware that you're likely concentrating your resources on the R300 generation. But I think it would be wise to expose as much functionality as possible on the 'old' gen. The R200 has become probably the most desireable mainstream card, so please give me (and other stubborn GL-heads) the tools to make an impression

 

[NitroGL]

A texkill instruction would be nice, but what I really wanted was the texdepth instruction (perpixel DOT3 lighting with perpixel displacement ).

You should send an email to ATI about it.

 

[GLMAN]

zeckensack,

Well you're pretty much right that we're shifting our focus away from R200 for as far as new development is concerned: We're moving away from ATI_fragment_shader toward developing ATI/ARB_fragment_program which should contain a KILL instructions as well as the ability to export a depth value. Unfortunately, ATI/ARB_fragment_program won't be supported on R200

As far as a triple buffer extension goes, we haven't really though about that one. I agree with one thing said on the thead you referenced: I'd prefer a GL2_buffer_management extension. Buffer managment is one thing DX does better than OpenGL, IMO. Pixel formats are cumbersome and pretty inflexible. GL2 buffer management would definately improve upon that.

 

[zeckensack]

zeckensack,

Well you're pretty much right that we're shifting our focus away from R200 for as far as new development is concerned:

You mark my words, and I'm sure at least some people inside ATI will agree:
R300 is the high end part for building reputation and brand awareness. R200 goes the way of the dodo right now, but I guess RV250 (which is AFAIK functionally equivalent to the R200, as far as 3D graphics are concerned) is your part for revenue and profit. In the near and mid future you will likely have good market penetration with the Radeon9000 parts. These are selling as new cards. So why stop the dev effort just now? You're already pretty much there. All I'm wishing for is a few additional tokens in the ATI_fragment_shader spec and accompanying drivers. When you've done that, I won't ask no more, I promise
The nice thing about OpenGL programming is still the ability to control pretty much every available pipeline resource on any chip. It's really a shame that you apparently decided to leave stuff unexposed that your chips are capable to do.
I hope you don't mind me saying that, but this (maximum feature exposure for non-current chips) is the one area where NVIDIA consistently beats you.

I believe you won't be able to comment on this, but I'll ask anyway: is there some sort of hardware obstacle in conjunction with 'kill', 'texdepth' and the like that hinders seamless integration?

We're moving away from ATI_fragment_shader toward developing ATI/ARB_fragment_program which should contain a KILL instructions as well as the ability to export a depth value.

That bodes well for the future. But I'll ask again that you please consider market penetration. The full blown fragment programs won't do much good for your high-volume mainstream products.

Unfortunately, ATI/ARB_fragment_program won't be supported on R200

Unfortunate it is, but I do understand it. There's not much sense in trimming down the big thing to fit previous generation hardware. That's why I'd rather have a slightly improved ATI_fragment_shader for previous gen hardware and the new stuff on the new hardware. As I take it, on the hardware side of things, the R200/RV250 chips are already pretty much opcode-driven execution machines (in contrast to the state-driven routing machines in NV2x). If kill and depth replace are simple opcodes on your hardware, why not expose them?

As far as a triple buffer extension goes, we haven't really though about that one. I agree with one thing said on the thead you referenced: I'd prefer a GL2_buffer_management extension. Buffer managment is one thing DX does better than OpenGL, IMO. Pixel formats are cumbersome and pretty inflexible. GL2 buffer management would definately improve upon that.

I'm pleased that you see my point. GL2 exts are something I'm really looking forward to as well. At the time of writing of the old thread ARB_pixel_format made more sense to me for the suggestion but that's quite low priority even to me. Again I'm simply wishing for broadest possible hardware support. If GL2_buffer_management (which I must admit I haven't followed) requires features that prohibit support on the R200 level ... well, you probably know what's coming now ... why not make minor changes to the old spec instead of trimming down the new spec? I'd surely use it.


Anyway thanks for your time. It's always appreciated