https://bugs.freedesktop.org/show_bug.cgi?id=91170
--- Comment #6 from Ilia Mirkin <imir...@alum.mit.edu> --- Created attachment 116925 --> https://bugs.freedesktop.org/attachment.cgi?id=116925&action=edit another bs fix This is very worrying... emitting more fences seems to fix it. Another place where it helped was in nouveau_transfer_write. The joke of it is that emitting a fence doesn't even kick the pushbuf, just writes the commands. But since I'm not actually changing *which* fences are attached, I really don't see how this changes anything. Waiting on fence instead of fence_wr doesn't seem to affect it either. What this game does is totally NUTS btw. It has a 512KB vertex buffer, and every time it maps it is with GL_MAP_INVALIDATE_BUFFER_BIT and writes all 512KB each time. Which is fine, just... inefficient (probably). It also has a 128KB index buffer, of which it maps the whole range with GL_MAP_READ_BIT | GL_MAP_WRITE_BIT | GL_MAP_FLUSH_EXPLICIT_BIT. And then draws, immediately maps it again, draws, etc. This is like the definition of how not to use these buffers. Anyways, this forces the creation of a staging bo (in GART), which receives a copy of the old 128KB of data, and returns a pointer to that. Then the program updates the 12 or whatever bytes of data, and flushes them, so *just* those 12 bytes get written. [I'm not kidding, it literally updates 12 bytes a lot of the time.] I tried adding kicks in copy_data & co, but that (expectedly) didn't help. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau