ARB_Fragment_Shader

ATI and NVIDIA are working on a unified extension that should have all the desirable properties of VAO and VAR. The interface will look more like ATI’s VAO.

We all realize that it’s much better for everybody of we can provide a common API for this sooner rather than later.

Thanks -
Cass

I knew it, Cass . Well, at least I guessed you guys were working hard to make things nice and easy for us.

Originally posted by cass:
[b]
ATI and NVIDIA are working on a unified extension that should have all the desirable properties of VAO and VAR. The interface will look more like ATI’s VAO.

We all realize that it’s much better for everybody of we can provide a common API for this sooner rather than later.

Thanks -
Cass[/b]

This is one of the best news I have heard in the last OpenGL years. I hope it will be an ARB extension.
ARB_Fragment_Program released as the hw is becoming available (and not one or two years later) is another really fine news. IMHO.
It is good to notice that when different hardware companies, after doing their own graphics hardware, sit together to define a common interface to make developers life easiest, they reach good solutions. I think this is what the ARB is.

Originally posted by cass:
[b]
ATI and NVIDIA are working on a unified extension that should have all the desirable properties of VAO and VAR. The interface will look more like ATI’s VAO.

We all realize that it’s much better for everybody of we can provide a common API for this sooner rather than later.

Thanks -
Cass[/b]

Oh my lord, the future of OpenGL looks really bright
Another thumbs up.

Originally posted by Cab:
It is good to notice that when different hardware companies, after doing their own graphics hardware, sit together to define a common interface to make developers life easiest, they reach good solutions. I think this is what the ARB is.

Woohoo! Way to go, ATI and NVIDIA. Finally we’ll have a unified interface to VAO/VAR.
Also good to see that OpenGL seems to finally take the fast lane in overtaking DirectX concerning feature up-to-dateness

Originally posted by Asgard:
Woohoo! Way to go, ATI and NVIDIA. Finally we’ll have a unified interface to VAO/VAR.
Also good to see that OpenGL seems to finally take the fast lane in overtaking DirectX concerning feature up-to-dateness

it’s about time they started working together too

a big thanks from me to all the guys working in the graphics companies 3dlabs/ati/nvidia/sgi (others)
keep it going

Originally posted by Humus:
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.

Well, it is an important part of mine.

Frankly, to reach a point B from A.
U can always go there by foot (CVA) or use your dadcycle (VAO) but i definitely prefer my motorbike! (VAR). :wink:

i think the point is that even if the interface looks like VAO, nVIDIA’s implementation (for example) needn’t perform any worse than VAR - though i would prefer it if the new spec allows the app to handle synchronization like VAR if it wants to.

VAR, as nice as it is, isn’t very OpenGL like. Rather than hiding things (like synchronization issues) for you, it exposes them and expects you to do the right thing. It, also, allows you to directly allocate and touch implementation memory, something else OpenGL doesn’t like to do directly.

that’s why it would be good if getting a direct pointer was an option, rather than the default.

still its good to have it in there if you need it. and i think the GL2 guys have the right idea by extending and generalizing the NV_FENCE concept to let the app do better synchronization. with CPU and GPU working in parallel, it’s just like multi-threaded programming, and you NEED app-controlled sync, because the app knows what it’s trying to do and the driver can only guess. sometimes u gotta allow these things for higher performance… but like i said, it shouldn’t be the only (or even the default) way to do it.

> i think the point is that even if the
> interface looks like VAO, nVIDIA’s
> implementation (for example) needn’t
> perform any worse than VAR

Yes, it does. VAO needs to implicitly set a fence (or something similary) every time you use the object. With VAR, I can tell it when to synchronize, and when not to. Synchronization costs a bit of overhead (last I heard, each fence would temporarily bubble the pipe).

Yes, it does. VAO needs to implicitly set a fence (or something similary) every time you use the object. With VAR, I can tell it when to synchronize, and when not to. Synchronization costs a bit of overhead (last I heard, each fence would temporarily bubble the pipe).

Isn’t the fence only needed when you write data ? For example, if you use the MOB extension to get a pointer, I assume it would issue a flush ( or something ).

There can be funny tricks with buffer renaming that allow you to hide synchronization. For what it’s worth, there will be a way to get a pointer to write your vertex data directly into. It’s not entirely clear just what that will look like right now. Whatever it is, I don’t think it’ll look like VAR where you have one pointer for all time. The driver needs the ability to move stuff around and give you a new pointer from a potentially different type of memory.

We’re going to be very careful not to take away any capabilities you have today. If you want to use VAR, it will continue to be there too – there will just be a portable alternative with (hopefully) equal or better flexibility and performance characteristics.

Thanks -
Cass

Any idea what timeframe we are talking about?? maybe the same drivers that exposes ARB_Fragment_program? and maybe before the release of nv30?

aint gonna be no ARB_fragment_program without no nv30.

btw, following ATI’s lead, how about GL_NV_text_textureshader_registercombiners(using the new ARB program interface)?

ARB_vertex_array_object???

Us MAC guys have had this for ages…well a couple of weeks anyway

Well, APPLE_vertex_array_object, APPLE_fence and APPLE_vertex_array_range, available on both NVidia and ATI hardware, at any rate…

Now the question is, when are the PC drivers going to support the best OpenGL extension ever – APPLE_client_storage ?

[This message has been edited by OneSadCookie (edited 09-22-2002).]

I like VAR. It gives me the flexibility I need. But it is also true that it is not the OGL style and its limitations of ‘just one array of memory’ limit its possible extensibility (for example to have things in different types of memory). It is not easy to use for non experienced programmers, as you can constantly see in this forum, (you have to create a small memory ‘manager’ for the allocated buffer and, possibly you have to ‘separate’ the buffer in two chunks for static and dynamic objects, …). It will not be easy to use for a programmer learning OGL and doing small tests, apps. Or it will not be useful for small demos without a previous ‘framework’

I understand that VAO approach is a little bit more limited (you can simulate current VAO with current VAR) but it is easier, you can use it quickly in a small demo, app. With direct pointers you can do things ala VAR style. And it should not be slower than VAR. It is something similar to D3D vertex buffers and with flags like DISCARD (previous content), STATIC, DYNAMIC, … it leaves the driver room for optimization (like buffer renaming as Cass mentioned or storing static objects in video memory, if desired). You must notice that current D3D vertex buffers have needed the evolution from D3D5, 6, and 7 (small changes in 8) to reach its state but now ‘they’ have something I find useful. Of course, this is just my opinion.

Anyway, I see any effort in a common API for transferring geometry to GPU in an efficient way, very welcome. I’m really a little tired of the lack of this feature and to be dealing with VAR, VAOs and CVA (I have dropped the support for CVA some months ago). I have the same feedback from other OGL programmers, some of them doing things in D3D just for the lack of this feature. Another ‘big’ missing feature, in my opinion, is the lack of a common extension for fragment_shaders for HW like GF3, GF4, Radeon 8500, P10, Parhelia,… But it is true that this limitation is just for this HW and seems be solved in future HW with arb_fragment_program while the absence of ARB_VAO (or similar) is a limitation for past, current and future HW.

[This message has been edited by Cab (edited 09-22-2002).]

> Isn’t the fence only needed when you write
> data ? For example, if you use the MOB
> extension to get a pointer, I assume it
> would issue a flush ( or something ).

That would make it totally useless (well, almost) for streaming data, which is exactly what MOB is FOR.

The problem is that you only want to flush up to the point the buffer was last used, or some point “soon after” that. You don’t want to flush up to the present. The only sane way of enforcing this in a driver is with some sort of testable condition for whether each buffer has completed (*). With VAR, I can make the granularity/fencepost trade-off myself, and I make it such that I won’t be testing or setting a fence more than once per frame during normal load.

(*) The driver COULD keep some amount of memory around for buffer rename space, and only set fences when I’ve gone through that amount of memory of newly mapped buffers. However, this means that the driver, not me, has to decide how much memory I’ll go through per frame, which it’s unfortunately less well suited to doing than I am. Although I’m sure they’ll do the best they can and get within spitting distance – personally, I go fill rate bound on the cards that need help, anyway, so it’s probably no big deal. However, these are the reasons I like the approach of VAR better than that of MAB.