radeon CS parser refactoring

Ilija Hadzic ihadzic at research.bell-labs.com
Mon Jan 7 15:09:53 PST 2013



On Fri, 4 Jan 2013, Alex Deucher wrote:

> R6xx and r7xx are really all you need to worry about in this case.
> R1xx-r5xx UMS uses a different kernel interface for command submission
> and evergreen and later don't have UMS drm support.  UMS r6xx/r7xx
> support used the same kernel interface for command submission but the
> kernel side was much simpler.

OK, I have found an old machine with RV730 GPU and a known-working UMS: 
2.6.35 kernel, 6.13.2 DDX, 7.8.2 mesa (classic), 1.9 Xorg). I changed the 
kernel to the latest drm-next and ran tests with and without my 
CS-refactoring patches. Here are the results:

* It appears that drm-next in its current state is broken with regard
   to UMS (nothing to do with my patches, it was pre-broken to begin with).
   UMS provokes the kernel into a NULL-pointer dereference oops. Good news
   is that I have tracked down the crash and I will be sending the patches
   with the fix shortly.

* There are multiple patches that contributed to the breakage of UMS.
   I didn't bother pin-pointing them all, but one that I looked
   (6a7068b4) dates back to April 2012 so there are kernels out in
   distros that crash on UMS. That probably tells us how many UMS
   users are left out there :-). BTW, the reason UMS crashes is
   because parser->rdev is NULL in UMS mode so every patch that tries
   to dereference it (and shares the code path with UMS) will cause an
   oops (it will become clear when you see the patches).

* So, having fixed the above incidental finding, I got my machine
   with ancient UMS-userspace and a shiny latest drm-next kernel (plus
   my CS-refactoring patches plus my yet-to-be-sent UMS fixes) to
   work. My test consists of bringing up Gnome (it's Gnome 2 on that
   machine), running glxgears, sphereworld (an example code from
   OpenGL Superbible book), and OpenArena. Everything seems to work.

* Going back to KMS and retesting there, things still look good.

So this (with tests I did on Friday) should cover all the cases.

> Additionally, UMS requires the old
> non-gallium 3D drivers.  It sounds like some other change in the ddx
> broke UMS support for r6xx/r7xx.

The DDX segfault I reported on Friday was provoked by trying to run 
Gallium 3D driver on the top of UMS. Once I switched back to classic, the 
crash went away. So I guess the userspace crash was provoked by some 
obscure path that was never intended to be exercised. I don't think
it's worth investigating further.

-- Ilija



More information about the dri-devel mailing list