On Fri, Jan 4, 2013 at 5:57 PM, Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 4 Jan 2013, Dave Airlie wrote: > >> Did you run these with pre-kms userspace etc to make sure it doesn't >> cause regressions there? >> > > I did some tests with UMS and shuffled a number of cards. As I feared, I ran > into a number of unrelated problems, but in each case I have seen identical > beahvior between the kernel with my patches and without. So as far as I can > tell, my patches do not introduce regressions in legacy modes, althugh I am > not sure about the coverage. > > Also, in one test, I think I have hit a genuine bug in ATI DDX (explained > below). > > Below I describe what I saw with each card family. Maybe for some test cases > I am missing some "magic" option in xorg.conf or maybe what I am seeing > (mostly reduced feature set) is expected in UMS. > > * With an NI card (TURKS, HD6570 card), Xorg just plain tells me that the > card is supported in KMS only mode. So, I guess, that's it for that > card. Evergreen was the last set of hardware supported by UMS. > > * A test with Evergreen (CEDAR) card works in UMS mode, but I can't > get 3D acceleration. I see these messages in Xorg log file: > > [ 37.024] (II) RADEON(0): No DRI yet on Evergreen UMS support for evergreen is modesetting only. No accel. > ..... > ..... > [ 37.364] (II) AIGLX: Screen 0 is not DRI2 capable > [ 37.364] (II) AIGLX: Screen 0 is not DRI capable > [ 37.664] (II) AIGLX: Loaded and initialized swrast > [ 37.664] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > Sounds like just a "property" of UMS to me, but I am not sure. > Nevertheless, the behavior with and without my kernel patches is > identical. Still, 2D copying should still be exercising the CS > parser, so there is some test coverage here. > > * A test with an R7xx card (RV730, E4690 card) results in a segfault in > DDX. Again, this is irrespective of my kernel patches, so I believe > that the bug has been there for a while and that it's in userland. > The crash occurs in r600_set_render_target() function and what causes > it is corrupted cb_conf->surface pointer. When the crash occurs it > has a value of 0x1, which doesn't look like something that would live > in .bss, .data or come from the heap. I didn't try other R6xx cards, > but I suspect that they may have the same problem because they share > the code in DDX. I don't know if UMS DDX will be maintained going > forward, so I don't know if it makes sense to open a bug for this. > BTW, DDX I am testing this with is 6.14.6 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. Additionally, UMS requires the old non-gallium 3D drivers. It sounds like some other change in the ddx broke UMS support for r6xx/r7xx. UMS support was dropped for xf86-video-ati 7.0.0, so we mostly want to try and avoid breaking things for users with ancient userspace stacks and a new kernel. That said, I'm not sure there are that many UMS users left. Alex > > * A test with R300 card (Radeon X300 card) works (again identically > with and without my patches), but again without 3D acceleration. > So it's similar result and comment as with the Evergreen test, though > relevant messages in Xorg log file are slightly different: > > [ 35.630] (EE) AIGLX error: r300 does not export required DRI extension > [ 35.630] (EE) AIGLX: reverting to software rendering > [ 35.915] (II) AIGLX: Loaded and initialized swrast > [ 35.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > Again, I don't know if this is just the way things are in UMS mode or if > there is some configuration magic I need to do. > > So at this point I'd say that I have not seen anything that would indicate a > regression in legacy mode, although the limitations I have hit make the > tests more limited that I thought they would be (and KMS I tested quite a > bit, so I am confident there). > > thanks, > > Ilija > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
