Sept. Meeting notes

Some interesting stuff…

“Two new vertex array object extension proposals were presented. This has become time-critical, and a working group will be formed immediately to converge on an ARB VAO specification.” Oh… My god! Can it be true?

Well i’m definitely not so enthousiast!!
quoting from the hours:
“GL2 objects would be defined in terms of client state and client machine units (also true of the ATI/NV proposal), which makes it hard to move VAOs onto the server. Principal design goal is accelerating rendering for direct rendering clients, not enabling more efficient indirect rendering. ATI/NV proposal is oriented towards more dynamic data, as well.”

I haven’t seen what was the proposal from 3DLABS exactly concerning VertexArrays but i feel a little bit sick when i think about static data or in other words data that are stored onboard (as it is with VAR and as it should be -> but is still not proven <- with VAO)
Well, wtf? programability with GL2.0… okay the BIG stuff… will be cool, everybody is nice etc etc etc…
And what about these memory issues? i don’t want AGP when i’m managing static data.
This is not because dynamic stuff & streaming blah is da fashion that they could miss the point???
Something sounds wrong and maybe i’m! :wink:

The links to the slides are broken. I would like to see those ( if anybody with access to them is reading this ).


i don’t see much problems on the VAO problem. they start to solve it, thats all.

but there is still only an os-dependent solution for pbuffers, render to texture. that is so utterly stupid. as rendering to texture gets more and more important, this should be finally handled in a real GL_ARB_render_target.


Originally posted by davepermen:
i don’t see much problems on the VAO problem. they start to solve it, thats all.

Start to solve it??? bugged & still not finished… it’s about a year from now Davepermen!
I don’t want to be harrassant with this VAO prob but i’m fed up with people (from ATI) telling bulls.h.i.t.s…

from the specs:

0.9 - 08/15/01
Added support for variant arrays.

0.8 - 07/06/01
Added table of new state.


And today you're able to say that VAO rules? Frankly they don't, and please don't tell me that that's because they ARE of course faster than CVA! (how can they be slower anyway) but that 2x speed is not enough when you are supposed to turn your board in real hw T&L. (with no bus traffic).

VAO is a shame in term of performances and i don’t care about its current implementation.

(with no bus traffic).

VAR doesn’t achieve this, primarily because doing so would violate numerous laws of physics.

VAO is a shame in term of performances and i don’t care about its current implementation.

Say what you will about the 8500 implementation of VAO, there is nothing wrong with the spec itself. The spec doesn’t say, “You will guarenteably get 5-10x the speed of non-VAO vertices.” In fact, it doesn’t promise any speed improvement. All it does is have a more relaxed version of the rather strict OpenGL array rules.

Likewise, it is not the ARB_render_texture extensions fault that it runs like crap (equivalent to a copy) on a GeForce. It is solely the fault of nVidia’s drivers. Just as VAO performance not meeting your expectations (whatever those are) is purely the fault of ATi’s drivers.

As an excercise to prove this, implement VAO using VAR. You can do this; it isn’t terribly difficult. You’ll find, unsuprisingly, that it achieves virtually the same speed as VAR.

Korval says-> :slight_smile:
“VAR doesn’t achieve this, primarily because doing so would violate numerous laws of physics.”

Then, once you’ve stored your vertices into VRAM could u explain for which good reason they’ll be sent back to system memory through the BUS again?

Are we talking about VertexArrayRange? :))

Originally posted by Korval:
As an excercise to prove this, implement VAO using VAR. You can do this; it isn’t terribly difficult. You’ll find, unsuprisingly, that it achieves virtually the same speed as VAR.

Bravo, but it is non-sense.

Ozzy, VAO alone is not that good, but as soon as you start using the ATI_map_object_buffer extension, VAO becomes as good as VAR. What makes you think it’s slower than VAR ?



Sorry i’m just landing on earth, and i’ve never heard of that ATI_map_object_buffer. ?
where are the specs of this extension? :))

The specs and the raw timings results make me think that VAO (without the map_object_stuff you’re talkin about) doesn’t challenge compared to VAR implementations.

from specs (for Korval also :wink: ->
This extension (VAR) is designed to allow very high vertex processing rates which
are facilitated both by relieving the CPU of as much processing burden as
possible and by allowing graphics hardware to directly access vertex data.
Because this extension is implemented as an addition to the vertex array

Right, currently CPU usage when using VAO is really important! thus, that’s the problem.
A good T&L design (as we’re talking about vertex processing) should not have to involve any CPU cycles. that’s all…

Now maybe the ATI_map_object trick can help but it is not present in the specs. (?) uh?

am i blind? :))

The ATI_map_object_buffer extension is just a way to lock / unlock the object buffer; that is, you get a direct pointer to video memory, instead of having to do your stuff in system memory, then transfer it into video memory. It only helps for dynamic updates, i don’t think it changes anything for static geometry.

And i agree normally, when you statically store your vertices into video memory, the CPU should be idle when rendering. That’s what i’d expect from VAO, did you have a different experience…?


Well, Y.
I’ve looked into your sources and i’ve found the map_object_buffer stuff.
Thus what i’ve got to do now is to test with this locking func…
Btw, i am only using GL_STATIC_ATI when creating the VAO. Thus, maybe it needs to be an explicit lock to VRAM?

note: where did u find that ext?

[This message has been edited by Ozzy (edited 10-08-2002).]

It’s only usefull when you write your data to video memory. Hence, if you’ve got static stuff that you only write once at runtime, it’s useless. But if you need to stream some data in, i’d expect a quite big performance improvement. Btw, i think it requires your VAO to be created with GL_DYNAMIC_ATI.

This extension is not “official”, so i won’t tell more :slight_smile: But believe me when i say the spec is quite simple, and it’s obvious how to use it…


Well i’m a BIT distgusted… :wink:
knocking at the door of ATIDevrel for VAO issues etc etc etc for 8 months!
Not a word…
Anyway, we’ll see what this ext is all about sOon!

Now from my own experience as i said, (and u know Y.) :wink: It’s just that CPU involved while processing vertex that drive me mad since the begining! That’s why i was supposing that it would be AGP transferts.
(what else could it be?)
Moreover there are really bad performances ‘enabled’ when lighting is ON.

You mean they still haven’t released the ATI_map_object_buffer spec? How long has that extension been around?

Oh well. Get and you will immediately see how it works:

// Assuming that buffer_handle is your already created vertex array object:
// Get a pointer to your object buffer:
void *objbuf = glMapObjectBufferATI(buffer_handle);

// ... Now write vertex data to *objbuf.

// And then unmap the buffer:

I’ve never seen the actual spec of ATI_map_object_buffer, but I can’t imagine the above would be too far off.

– Tom

[This message has been edited by Tom Nuydens (edited 10-08-2002).]

don’t know yet! :))
But we’ll definitely see what the buffer addy will look like!! AGP or VRAM? :wink: )

Sorry Zak for this thread being… weird… :wink:

The fact of having a common interface to submit the vertex data (static and dynamic) to the graphics card is something really good.

It is true that render to texture is something that some of us can understand as something important (more important each day for advanced effects), as it can be a common interface for nv_texture_rectangle, occlusion query, a method for doing things if a condition becomes true without losing the parallelism (something like beginif(condition1, condition2, …)), …

But one of the needs to render things quickly is having the vertices in a place where the GPU can handle them efficiently (and it is true for render to texture, for setting up a shadow map, for vertex programs, … for everything). And the lack of a common API for this, is something bad for everybody trying to do something for the consumer mass. And IHVs looking to create a common interface is something all of us should understand like the right approach (this is something we are been asking for years). And it is a sign that they have stopped (at least for a moment) of looking at their own belly button, and trying to do the right thing for developers. I think, they have understood that this is the only way developers will use the new features of their different hw. So, for me, it is good news. ARB_fragment_program, even with the small limitations exposed by jwatte, is also a very good news. As they are the big number of ARB extensions approved and existing on current drivers during the last year. What we have to do, everyone of us, is give the correct feedback to the ARB so they can make the correct decisions.

If ATI’s VAO doesn’t work for you, it doesn’t mean that it is not a good spec, it is probably because their drivers are not optimised or not working properly. I used VAO one year ago, and it freezes the computer. I tell it to ATI, with a small demo, and I haven’t tried it again until last month. Now, it is working and the speed gain is big, from 15FPS to near 100FPS (on one testing machine: PIII 800, W98, R8500), and it is in a real game, with different kind of vertices, static and dynamic arrays, …

With a common interface, and everyone using it, they will need to optimise their driver because the benchmarks will show the difference between cards from different vendors.

Of course, this is just my opinion.