https://bugs.freedesktop.org/show_bug.cgi?id=37142

Michel Dänzer michel@daenzer.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Product|DRI |Mesa Version|DRI CVS |git Component|DRM/Radeon |Drivers/Gallium/r600

https://bugs.freedesktop.org/show_bug.cgi?id=37142

--- Comment #1 from Ian Romanick idr@freedesktop.org 2011-05-12 10:55:30 PDT --- (In reply to comment #0)

Created an attachment (id=46638)

--> (https://bugs.freedesktop.org/attachment.cgi?id=46638)

openarena + verbose vertex buffer upload logs

Test case : openarena + anholt benchmark + r600g

I added several fprintf debug trace to mesa code around Vertex buffer uploading. Basically, openarena render things using : glVertexPointeer() glLockArraysEXT() several glDrawElements() glUnlockArraysEXT()

It seems that each call to glDrawElements implies a reupload of the vertex buffers, even if it has not changed (as glLock/Unlock calls tell, at least for part of the buffer).

EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. No new applications should use it, and old applications that use it should be fast enough on modern hardware. I really don't think we should add any code to Mesa to make this case fast. We'd be better off submitting patches to openarena to use VBOs instead.

Another related bug (it seems) is in : cso_set_vertex_buffers() which does a test before calling : util_copy_vertex_buffers and pipe->set_vertex_buffers This test always return true, thus the 2 above functions are always called. The test is always true because it memcmp all pipe_vertex_buffer, which contains a 'buffer' pointer, which changes at each frame (see st_draw.c:349).

I'm trying to build a patch which fix the cso_set_vertex_buffers problem and then, taking advantage of glLock/Unlock calls to fix the upload issue.

What do you think ?

https://bugs.freedesktop.org/show_bug.cgi?id=37142

--- Comment #3 from Pierre-Eric Pelloux-Prayer pelloux@gmail.com 2011-05-12 13:19:13 PDT ---

EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. No new applications should use it, and old applications that use it should be fast enough on modern hardware. I really don't think we should add any code to Mesa to make this case fast. We'd be better off submitting patches to openarena to use VBOs instead.

That's why I asked for external opinions. I still feel that IF it can brings significant enough performance improvement, it could be useful - mainly because openarena and all games using quake3 based engine are used in every open-source drivers benchmarks.

https://bugs.freedesktop.org/show_bug.cgi?id=37142

--- Comment #5 from Fabio Pedretti fabio.ped@libero.it 2011-05-13 00:11:50 PDT --- Note that ioquake3 will probably support VBOs soon: https://bugzilla.icculus.org/show_bug.cgi?id=4358

https://bugs.freedesktop.org/show_bug.cgi?id=37142

--- Comment #7 from Pierre-Eric Pelloux-Prayer pelloux@gmail.com 2011-05-17 05:33:51 PDT --- Created an attachment (id=46804) View: https://bugs.freedesktop.org/attachment.cgi?id=46804 Review: https://bugs.freedesktop.org/review?bug=37142&attachment=46804

vertex buffer upload caching

Here's a patch adding vertex buffer upload caching. It's not extensively tested (only with custom app and openarena), and is a bit hackish (mainly regarding : ctx->Array.NewState field, but it seems unused elsewhere). Anyway, it allowed me to do some testing and confirm the initial guess : it brings no performance improvements to openarena :-/ (but that was expected, as profiling the game tells that u_upload_data < 1% cpu time)

So I guess the handling of EXT_compiled_vertex_array is useless - maybe with 1 exception : lower end video cards with lower bandwidth ? I can't test this scenario here, as I only have AMD HD4850.