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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from Marek Olšák <maraeo at gmail.com> 2011-08-27 11:14:54 PDT ---
(In reply to comment #7)
> 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?

I have been thinking about moving u_vbuf_mgr from the drivers to st/mesa or
somewhere between drivers and state trackers, along with user buffer uploads.
u_vbuf_mgr can be used by state trackers too, it's not limited to "just
drivers".

However we should consider that certain drivers can fetch vertices from user
memory just fine. Those are softpipe, llvmpipe, software vertex processing on
r300 swtcl chipsets (e.g. ATI Xpress and AMD 690 chipsets), i915, and pretty
much anything that makes use of draw_context. Doing vertex uploads on those
already-slow drivers would make them even slower, obviously.


> 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.

Vertex uploads and fallbacks work exactly the same in both r300g and r600g.

> 
> > 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.)

The index buffer isn't changed, so it's ok.

> 
> > 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?

Well, it's a completely different approach to uploading vertices. The
translation of vertices into one non-indexed interleaved vertex buffer (as I
was suggesting) could replace the rest of u_vbuf_mgr completely, i.e. uploads
and format fallbacks. So there would have to be some code determining whether
the rest of u_vbuf_mgr should be used (fine-grained uploads based on the
min/max_index data) or the pure translate way (complete translation of all
vertices into a non-indexed draw operation).

I am for using the translate module and doing complete translation in the cases
where it's worth it, and using the rest of u_vbuf_mgr otherwise.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.