Attached is a patch for Render acceleration on r100 and r200, based off of work by Hui Yu and myself. There are several issues with it, but this bug will be here to track progress and prevent it from getting lost: * Assumes PICT_a8r8g8b8 for windows on 32bpp screens, PICT_r5g6b5 for windows on 16pp screens * Doesn't init the 3d regs on non-CP (where to hook this in?) * Doesn't do Render accel on non-CP because the vertex submission hangs the system * The R200 blending doesn't seem to occur, for some reason (output is always R0_COLOR and R0_ALPHA, though the alpha blending works). * Many regs are initialized on r200 that I suspect are unnecessary (related to tcl being enabled). * Cache flushing is questionable to me -- seems like we should WAIT_2D_IDLECLEAN | WAIT_HOST_IDLECLEAN before rendering and WAIT_3D_IDLECLEAN after, to me.
Created attachment 371 [details] [review] Snapshot of Radeon render work
Created attachment 376 [details] [review] radeon-render-10.diff Now r200 passes rendercheck, but fonts are wacky.
Created attachment 377 [details] [review] radeon-render-11.diff One more version. R100 and R200 both appear to work, passing rendercheck, with more ops supported than ever before. Xft fonts also working. To test this, add: Option "RenderAccel" "YES" to the Driver section of your xorg.conf. Notes: * Only works in CP mode -- need help from ATI for MMIO mode, probably. * Not sure about the necssity of all the the r200 regs we initialize. * Accel doesn't seem to happen with 32-bit framebuffer. * Conformance issue of XAA not passing the dst format in.
In the long term, the textures should be uploaded with hostdata blits to avoid idling the engine, at least with the CP. I wonder if this plays nice with 3D clients? In my own Render acceleration experiments, I set pSAREAPriv->ctxOwner = DRIGetContext( pScrn->pScreen ); to make 3D clients re-upload their state from scratch. In the non-CP case, the 3D engine could be set up in RADEONEngineInit()?
Good catch on the ctxOwner -- I had thought the WakeupHandler and EnterServer stuff all handled that already, but I guess the 2d usage in the drm resets all the necessary registers anyway. I'll add that to the next patch. I'm not really worried about the EngineSetup for MMIO as much as the problem that dispatching through that SE aperture seemed to just hang the card. I haven't tried for quite a few revisions, though.
(In reply to comment #5) > Good catch on the ctxOwner -- I had thought the WakeupHandler and EnterServer > stuff all handled that already, but I guess the 2d usage in the drm resets all > the necessary registers anyway. I'll add that to the next patch. I think EnterServer is fine for 3D client -> X server, but the server needs to set the ctxOwner for X server -> 3D client.
some tests with cairo/glitz (with patch 11): RenderAccel off: [fritz@aquarius cairogears]$ ./cairogears -xrender TRAP 33 frames in 5.0 seconds = 6.600 FPS 28 frames in 5.0 seconds = 5.600 FPS 27 frames in 5.0 seconds = 5.400 FPS 30 frames in 5.0 seconds = 6.000 FPS 31 frames in 5.0 seconds = 6.200 FPS RenderAccel on: [fritz@aquarius cairogears]$ ./cairogears -xrender TRAP 135 frames in 5.0 seconds = 27.000 FPS 138 frames in 5.0 seconds = 27.600 FPS 138 frames in 5.0 seconds = 27.600 FPS 134 frames in 5.0 seconds = 26.800 FPS 138 frames in 5.0 seconds = 27.600 FPS glitz: [fritz@aquarius cairogears]$ ./cairogears -glx -swaa TRAP 248 frames in 5.0 seconds = 49.600 FPS 250 frames in 5.0 seconds = 50.000 FPS 250 frames in 5.0 seconds = 50.000 FPS 249 frames in 5.0 seconds = 49.800 FPS 250 frames in 5.0 seconds = 50.000 FPS Work without any problems on radeon 8500, X11 x.org HEAD. Thank you Eric! :D
Committed a slightly different version that included Saturate and a couple of other operations, along with fixing the ctxOwner issue brought up by Michel Daenzer. Thanks to everyone who helped with this! It could still use the ImageWrite suggestion, but I decided it was a stable enough first shot to go in for now (been using it on my r200 desktop, and the r100 tests seemed fine).
I believe this enhancement was commited to X.org sources with the changelog comment: "Only supported in DRI mode because the MMIO submission hangs the card so far, but the code is left in because it may be supportable soon." Is that still an issue with current X.org 6.8.2? I do see Radeon 7500 cards in MMIO mode hang on Solaris x86, as soon as R100SubsequentCPUToScreenTextureMMIO() is called. Current QT4 betas seem to trigger this call, but according to some usenet posts [*], the GNOME deskop seems to trigger the MMIO freeze on Radeon 7500 as well. (See bug #3222). Is there any idea why the Radeon7500 cards freeze in MMIO mode and how this can be fixed (other than disabling "RenderAccel") ? [*] http://groups-beta.google.com/group/alt.solaris.x86/msg/17d953eaeb015d56 http://groups-beta.google.com/group/comp.unix.solaris/msg/1c67127c8aa39c20
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.