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