It is approved as you can see in www.opengl.org
http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt
Sorry, the topic should be ARB_Fragment_Program
[This message has been edited by Zak McKrakem (edited 09-20-2002).]
Now that was quick. And I just wrote in another post that it’ll take some more time to get the spec done. Good job! Now let’s read through that monster 
Very well then. Good weekend reading.
That’s great. I noticed another new extension,
http://oss.sgi.com/projects/ogl-sample/registry/ATI/text_fragment_shader.txt
Is this extension extension for the 8500 ? I haven’t looked at it yet but maybe ATI can answer faster than I can read 
.
Is this extension extension for the 8500 ?
Yes, it’s basically a redefinition of ATI_fragment_shader with a textual instead of a procedural interface.
ATI_text_fragment_shader is just the ATI_fragment_shader using strings ala NV_vertex_program/ARB_vertex_program. Doesn’t appear to be any new functionality or abilities though 
Dan
Originally posted by Dan82181:
[b]ATI_text_fragment_shader is just the ATI_fragment_shader using strings ala NV_vertex_program/ARB_vertex_program. Doesn’t appear to be any new functionality or abilities though
Dan[/b]
think about it. its in hw, build by transistors. how should they add functionality if they made the hw just that way? … only nvidia can do this, but imho i prefer the full hw right from the beginning
Originally posted by davepermen:
[b] think about it. its in hw, build by transistors. how should they add functionality if they made the hw just that way? … only nvidia can do this, but imho i prefer the full hw right from the beginning
[/b]
Wishful thinking. I’ve been trying to squeeze a couple of things in and was just hoping it could do maybe 3 or 4 passes, or possibly more ops per pass depending on which ops you are running. Oh well, looks like I gotta wait till I finish getting the car paid off until I get a 9700.
Dan
Well, hopefully 9700 drivers exposing ARB_fragment_program come out before I have my car paid off. 
Just kidding ATI, I know you’re working hard at it. Trust me, before I get my car paid off, we’ll be looking at 50Ghz Pentium 20s or something.
Just browsing the docs, it looks like you can do fog/atmospheric stuff in the fragment program, so that’s cool.
Very good news!
With arb_vertex_program and arb_fragment_program graphics coding is slowly becoming fun again
Originally posted by davepermen:
[b] think about it. its in hw, build by transistors. how should they add functionality if they made the hw just that way? … only nvidia can do this, but imho i prefer the full hw right from the beginning
[/b]
Actually, there’s some room for a bit more. You can’t write to depth like you can in D3D. I would like to see that added for OpenGL ( the hardware supports it ).
Actually, there’s some room for a bit more. You can’t write to depth like you can in D3D. I would like to see that added for OpenGL
That’s what ARB_fragment_program is for
Yes, but that extension won’t be supported on 8500. I don’t understand why ATI doesn’t expose that last bit of 8500 functionality in OpenGL.
I’m very glad to see ATI_text_fragment_shader. Thanks to this, a bit of mess in GL has been cleaned.
However, the extension could be slightly better if it handled texture targets the same
way as it is done in ARB_fragment_program (ignoring target priorities).
Would be great if Nvidia made similar ext for their RC and RC+TS …
[This message has been edited by MZ (edited 09-20-2002).]
I had that thought too, about NV doing something similar for their extensions. I like the fact that ATI’s new extension uses the ARB functions.
Edit: And while we’re at it, how about an ARB_vertex_array_object extension ? That would clean up another bit of mess.
[This message has been edited by PH (edited 09-20-2002).]
Honestly, I would prefer an ARB_vertex_array_range extension, which includes a requirement for fences as well. Maybe with some supported number of allocated memory chunks and vertex array ranges that’s greater than one
Honestly, I know more about how I stream and write my data than the driver does. The D3D model of using the same buffer with NOOVERWRITE and switching between different buffers with DISCARD is not at all as clean – in my humble opinion, of course
Whooha! Thumbs up for the ARB!
Now if we could get a ARB_vertex_array_object/ARB_vertex_array_range extension too it would be awesome, best would IMO be to pack ATI_vertex_array_object and ATI_map_object_buffer and produce an ARB of it.
Can’t wait to get my 9700, hopefully the ARB_fragment_program will be supported quite soon. Future looks bright 
Originally posted by PH:
[b]And while we’re at it, how about an ARB_vertex_array_object extension ? That would clean up another bit of mess.
[/b]
Oooh no… Today’s implementation on ATI boards are far behind VAR. Btw, Sis & Matrox are using VAO ext respectively for Xabre & Parhelia boards. But i don’t know more about that. tests? 
The important thing is that we get a good interface, whether a certain implementation gives you satisfying performance or not isn’t part of the equation.
The dark days are coming to an end - about time too.