everyone learns premature optimisation is the root of all evil.
korval: in opengl instancing has been proven to be unneeded because it is not a main bottleneck. reasoning are the much lighter functioncalls than in dx, where each call is quite hefty.
there are bigger bottlenecks in opengl, much more worth to invest time and money to build workarounds than instancing.
and this was stated both from ati and nvidia. instancing could help, but only a little. opengl is different, performance bottlenecks are at different places.
and currently, opengl lacks much bigger things than instancing. we can talk about that again once we finally got an about equal feature set dx9 has since long (a.k.a. easy rendertargets/rendertotexture still as main api-design-bottleneck).
it’s fun to discuss about it, yes, but you should learn your facts, korval. and use common sense.
It’s like the other 2 pages of discussion just didn’t happen.
Dave, did you just read the topic title and decide to throw in a random comment on the subject?
And just what other features should take precedence over this? You mention rendertargets, but that has already been finalised and awaiting implementations…so what other features is GL missing in comparison to dx9? Oh, it’s instancing isn’t it? Instancing is now the big difference between the two API’s, Dave. Hence this discussion.
Originally posted by ffish: I wouldn’t expect much until March .
ARB_pixel_buffer_object was just posted… Maybe EXT_framebuffer_object can soon follow…
I just noticed pbo was given full ARB status. I check the registry every day . I guess I need to get a life . Anyway, it’d be nice if fbo gets posted soon. Leaked driver implementations supporting fbo may appear before March too, but I’m not gunna hold my breath.
Originally posted by knackered: It’s like the other 2 pages of discussion just didn’t happen.
Dave, did you just read the topic title and decide to throw in a random comment on the subject?
And just what other features should take precedence over this? You mention rendertargets, but that has already been finalised and awaiting implementations…so what other features is GL missing in comparison to dx9? Oh, it’s instancing isn’t it? Instancing is now the big difference between the two API’s, Dave. Hence this discussion.
i normally don’t talk with spammers, but yes, i’ve read the whole discussion and followed it closely.
instancing is just an api difference, but not a performance difference… you could cry about not having immediate mode on dx, too. if you want the api, you can code it yourself and have a simple lib for it. if you want the performance differences, there aren’t any worth the effort. thats different to dx, where there is big possible gain.
I believe you’re mixing up the term ‘spammer’ with the term ‘troll’, dave. I have nothing to sell.
You seem to be missing the point in this discussion - it’s not about whether the feature improves performance in the common case, it’s about whether the feature makes sense for exceptional cases and for possible future scenarios. It’s about whether you agree that an API should provide the ability for applications to give more information about their scene as a whole at draw time, or is it a case of ‘the more atomic the better’. Care to answer, dave?
If you argue against an instancing mechanism, you must also have argued against glDrawRangeElements at the time of its introduction. With small batches, glDrawRangeElements gives very little performance increase…but for big batches it’s dramatic. What’s your opinion on this specific point, dave?
Korval had a good point when he said that because of the expense in submitting many small batches, application programmers avoid doing so, which in turn makes API review boards believe there’s no need for a feature to make small batches more efficient because nobody submits large numbers of small batches. What’s your view on this specific point, dave?
Originally posted by Humus: v-tables are even slower [than conditional branches] in most cases unless the number of paths are large and the conditions can be linearized.
OT:
AMD recommends padding out tables of function pointers to 8 bytes per entry. This avoids contention in the branch prediction (max three entries per 16 byte window).
So? He still reached near theorethical maximum performance with currently available APIs. What more do you need? Instancing can’t make it go faster than the hardware.
True. But it just might reduce the CPU burden. Even if rendering itself cannot be made faster, there’s still some potential benefit to overall sysem performance.
I think this was one of Korval’s points, if I read your discussion correctly.
This is a moot point if the driver does the application’s work of duplicating vertices, indices or (to a lesser degree) batches. Not so if there’s full hardware support.
It’s best if driver developers invest more time on render targets (in whatever form) and GLSL.
GLSL drivers have too many issues and since it’s going to be core in GL 2.0, it should be very much bug free.
Everyone is talking about instancing as beeing a performance solver. Maybe you should make your point in other ways, because most people won’t see a performance boost with this.
It’s best if driver developers invest more time on render targets (in whatever form) and GLSL.
GLSL drivers have too many issues and since it’s going to be core in GL 2.0, it should be very much bug free.
Everyone is talking about instancing as beeing a performance solver. Maybe you should make your point in other ways, because most people won’t see a performance boost with this.
agreed i wanna see time being spent on important things, instancing is only gonna benifit a limited number of situations BUT it will disbenifit? everything else (by adding to driver complexity).
what are the maximum benifits possible with instancing 10-20%, yet ppl are mentioning with this extra 20% all of a sudden instead of drawing a wall with plain ol boring bricks, now we can draw a wall of amazing (adjective goes here) bricks! get real! whatever the results its still gonna look worse than the raycasting shader that was presented here recently,
there are bigger bottlenecks in opengl, much more worth to invest time and money to build workarounds than instancing.
Such as? What performance problems are you talking about, that could be fixed with API changes, rather than simply faster hardware or better drivers?
and this was stated both from ati and nvidia.
The exact quote from the notes was, “Instancing geometry - no need, GL immediate mode rendering calls support this. Khronos may want to engage on this, though, since they don’t have finegrained immediate mode calls.”
Who does Khronos work for? His name isn’t mentioned attached to any IHV, so I’d like to know what hardware doesn’t support “finegrained immediate mode calls”.
easy rendertargets/rendertotexture still as main api-design-bottleneck
Already “done” (ie, the API and spec discussion is finally complete, and all we are waiting on is the publication of the spec and implementations). The ARB is now free to entertain other significant topics of debate.
Outside of other render-to issues (render-to-vertex-array, etc), what issues would you suggest they take up?
OpenGL’s API calls are very lightweight and therefore don’t need any further optimisations
but
If we try rendering 100000 grassholms(dunno how it’s written) something like instancing may be very usefull as it’s a simple and elegant trick. We can use another tricks with the same result of course - Humus described a instancing method using the shaders but I think it is not so straighforward. Instancing is a way of reusing some input streams and it may be very usefull for drawing lots of similar objects. Period.
So: instancing is only useful for some very rare cases but it is usefull.
Originally posted by Korval: Who does Khronos work for? His name isn’t mentioned attached to any IHV, so I’d like to know what hardware doesn’t support “finegrained immediate mode calls”. Khronos is the body behind OpenGL ES. OpenGL ES got rid of glBegin/glEnd, and only supports array based draw calls.
Khronos is the body behind OpenGL ES.
Really? Why is Khronos working on something like precompiled shaders, rather than the ARB proper? It seems that precompiled shaders is something that the ARB should be addressing, not Khronos, since it will effect OpenGL more than ES (which, as I understand it, has no real shading language support yet).
Originally posted by Korval:
Really? Why is Khronos working on something like precompiled shaders, rather than the ARB proper?
Maybe because embedded systems tend to be less-than-ideal platforms to run compilers on? Don’t know, just guessing.
Maybe because embedded systems tend to be less-than-ideal platforms to run compilers on?
A fair point. Though I’m not entirely convinced of the idea of binding our precompiled extension to theirs (though, really, OpenGL ES is a cleaner graphics system than OpenGL proper). Then again, it’s probably better that ES remains close to GL proper.
And there are embedded platforms with vertex programmability available today (MBX).
Wow, embedded stuff has come a long way.
Originally posted by Humus: So? He still reached near theorethical maximum performance with currently available APIs.
This statement is no longer valid. It is now “close to 20%”, not “close to 100%”. See my update above.
This statement is no longer valid. It is now “close to 20%”, not “close to 100%”. See my update above.
Actually, looking back on it, I’m not so sure that your computation is even accurate. R300 cards have between 2 and 4 (I forget offhand how many) vertex pipes, so, in theory, they can run a 6 opcode program in 2-3 cycles. In actual practice, I could believe 4-5, though. 6 would be possible, but unlikely. We could directly test how long the vertex program takes to run simply by making a perfectly vertex program limitted application (one huge batch of the same vertex, effectively) and compare it’s performance to the theoretical maximum.
In any case, there’s clearly some significant performance loss over the case of maximal performance. Whether it is in vertex T&L or vertex throughput/driver CPU overhead is unknown.
The card he used has the equivalent of one vertex shader unit so his calculation of max transform rate is correct. If you need info on chipset specs, Beyond3Ds 3D tables are an excellent resource. You can look up capabilities based both on chipset and board model.
Originally posted by MZ:
This statement is no longer valid. It is now “close to 20%”, not “close to 100%”. See my update above.
Ok, that changes things. But my point still holds true that using constant based instancing can reach performance close to or better than real instancing on current hardware. In a sample I wrote for work I get 108fps with real instancing, 103fps with shader constant based and 22fps with a naive one instance per call implementation. That’s with an asteroid field of 16384 instances of a 48 triangles model (26 vertices). If I boost the subdivision model one step I get a 192 triangle model (98 vertices), and instancing performance is 34fps, constant based instancing 42fps and naive at 22fps.
.
. I guess I need to get a life 
. Anyway, it’d be nice if fbo gets posted soon. Leaked driver implementations supporting fbo may appear before March too, but I’m not gunna hold my breath.