Bug 91170

Sorry, I missed to specify my video card:

VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2) (prog-if 00 [VGA controller])

Reproduced on GT215. Does not happen on GF108.

Geometry seems off as soon as the first or second title screen... will have to double-check old versions, hopefully it's a regression we can bisect.

OK, so forcing the inline vertex path rather than the stick-bo-into-pushbuf path seems to help. Will try to track down what's different. Probably something dumb around alignment.

Created attachment 116899 [details] [review]
bs fix

Ugh, the buffer-update-is-in-progress issue strikes again! I fixed this ages ago, but it's back. [The first hunk of this patch is unrelated, but it also won't hurt.]

So now to figure out why it's not fencing properly.

(In reply to Ilia Mirkin from comment #4)
> Created attachment 116899 [details] [review] [review]
> bs fix
> 
> Ugh, the buffer-update-is-in-progress issue strikes again! I fixed this ages
> ago, but it's back. [The first hunk of this patch is unrelated, but it also
> won't hurt.]
> 
> So now to figure out why it's not fencing properly.

The patch fixes the problem here as well.

Created attachment 116925 [details] [review]
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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1075.