https://bugs.freedesktop.org/show_bug.cgi?id=40401
--- Comment #7 from Vadim <pt...@yandex.ru> 2011-08-27 09:44:03 PDT --- (In reply to comment #6) > We usually just try to optimize drivers even for a totally inefficient OpenGL > usage and get the most performance out of it no matter what. > OK, I understand that mesa would benefit from such optimization, but taking into consideration the time which I'll need to spend on analyzing different ways of doing it, implementing and testing, and potential benefits for applications, it wasn't a top priority for me. These patches were intended for doing a quick test, handling just this single case. But if we want more universal solution, then I'm not sure that vbuf_mgr is a best place for this optimization - maybe it makes sense to do it somewhere else in the mesa, not on the driver level? > Some comments regarding the patches: > 1) Can u_vbuf_mgr_draw_optimize be called inside u_vbuf_mgr_draw_begin instead > of explicitly by a driver? IIRR I called it explicitly from the r600g because I wasn't sure initially if it's needed for (or will work with) r300g. It seems this call can be moved into the u_vbuf_mgr_draw_begin. > 2) Can you directly write the new vertices into a buffer object instead of > user > memory, which must be uploaded to a buffer object at a later point anyway? I was thinking about it, but it seemed to be more complicated, and I thought that when we avoided the copy for 4000 vertices, avoiding another copy for 4 vertices doesn't change much for quick test. But it seems possible to avoid this copy and memory allocation too. > 3) Could you please comment the code a bit more, e.g. how it interacts with > the > other parts of u_vbuf_mgr. It saves vertex buffer before replacing it with the newly created buffer, and sets boolean flag which means that it needs to restore vertex buffer and free allocated memory in the vbuf_mgr_draw_end, IIRR that's all interaction. (I don't remember now if it's really needed to save it, or maybe it's needed to save/restore even more data - e.g. index buffer too. I need to check the code to give the exact answer.) > 4) We could use the translate module to convert indexed vertices in several > separate buffers into one non-indexed interleaved buffer. I think nv50 and > nvc0 > always do that for user buffers. I was looking into it, but it seemed to be the overkill for the simple test. I just wanted to copy vertex data from single interleaved buffer as is, without any format conversions and/or other modifications. But maybe it makes sense to use it if we want to have universal solution. > > I think it's an optimization we definitely want. Should I try to improve these patches for vbuf_mgr according to your comments? Or may be it's better to reimplement it in some other way and in some other place? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
