[Mesa-dev] [Bug 40401] Cogs is slow

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Aug 27 09:44:04 PDT 2011


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

--- Comment #7 from Vadim <ptpzz at 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.


More information about the mesa-dev mailing list