Most IMPORTANT is that some-one some-where there is a list of ALL of these. These are best in the form of code comments so the the respective places in the code can be changed.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
Dose the DRM varify that the cmds are in this order? Why not just
have
the DRM 'sort' the cmds? A simple bouble sort would have no more
overhead
then the check for correct order, but it would fix missordered cmd streams.
Once this is done the statement holds true, userland stuff should
never...
Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also..
I'd love to, where do I start? The problem he is that I have no-idea... 1. What values I'd neet to test for and sort. 2. The order of the sorting(probly documented in DRI-client code). 3. Where in the DRM I can proform the needed test and sort.
I would also love a list of ALL of these so I can fix them one by one. A good project for a new DRI developer, no.
I seriously doubt this is doable. Unless you put the whole driver in the kernel, which of course nobody wants. I frequently caused gpu lockups by experimental driver changes (for instance, wrong vertex setup). I think the consensus was that it's ok for the driver to lock up the gpu, but it should not lock up the kernel.
It might be possible to prevent lockups by a watchdog, resetting the gpu if a lockup is detected. This is how ATI deals with lockups in windows (dubbed "VPU Recover"), and there is a patch floating around for DRI too (though it is not exactly for that, and doesn't always work).
Roland
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
