Nicolai Haehnle wrote:
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
I had fairly reproducable lockups prior to this fix. I'm at work at the moment, but I'll be able to test
it this weekend.
Adam
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
