Hi everybody,

As reported earlier, I had a perfectly repeatable lockup in VB mode that 
always happened after the exact same number of frames in glxgears. I can't 
explain everything about the lockup, mostly because I still don't know what 
the two registers in the begin3d/end3d sequence actually mean, but here's 
what I know:

It turns out that after the first 4 DMA buffers had been used to completion, 
r300FlushCmdBuf() was called from r300RefillCurrentDmaRegion(). This only 
caused simple state setting commands as well as an upload of the current 
vertex program into the VAP. There was no rendering going on, and neither 
the begin3d nor the end3d sequence was part of the commands that were sent 
to the card.
However for some reason, it was this sequence that caused the lockup.

This leads me to believe that there's somehow more "magic" to the 
begin3d/end3d sequence than just cache control as I originally assumed (or 
maybe it *is* cache control, but there's something weird going on in 
connection with it, I simply don't know).

In any case, what I did is *always* emit the begin3d sequence at the top of 
r300_do_cp_cmdbuf and end3d at the bottom of r300_do_cp_cmdbuf (it is also 
emitted in the case of an error). This works for me, I can run glxgears for 
several minutes, even doing some stuff that sometimes tends to produce 
lockups without any problems.

Please, everybody, get the latest CVS (anonymous will take some time to 
catch up...) and test vertex buffer mode with it (go to r300_run_render() 
in r300_render.c and change the #if so that r300_vb_run_render() is 
called). I want to be really sure that this fixes it for other people as 
well (after all, there may be other causes for lockups that haven't occured 
on my machine yet), and that there are no regressions for those who already 
had working VB mode.

Once we can be fairly certain that VB mode is stable (i.e. crash and 
lockup-free), let's talk about removing any mention of the begin3d and 
end3d sequence from the userspace driver. This is really far too subtle an 
issue to allow userspace to mess with it. This counts for the X server as 
well - if anybody feels like implementing Render acceleration, which I 
doubt at this stage, please leave the begin3d/end3d handling to the kernel 
module, as it's the only instance that really knows what's going on.

cu,
Nicolai

Attachment: pgpL5MGT4YXt6.pgp
Description: PGP signature

Reply via email to