Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support
Keith Packard kei...@keithp.com writes: I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. Patches 2, 4 are: Reviewed-by: Eric Anholt e...@anholt.net Patch 5 is: Acked-by: Eric Anholt e...@anholt.net pgpzj9osxG_S4.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support
Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. Patches 2, 4 are: Reviewed-by: Eric Anholt e...@anholt.net Patch 5 is: Acked-by: Eric Anholt e...@anholt.net Thanks. -- keith.pack...@intel.com pgp7IBtW8_yBv.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support
Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. Patches 2, 4 are: Reviewed-by: Eric Anholt e...@anholt.net Patch 5 is: Acked-by: Eric Anholt e...@anholt.net I've pushed a new version of the tree with your review marked and a few changes: * Split the GetScratchPixmapHeader change into two pieces; the first just removes the redundant calls to drm_intel_bo_disable_reuse and the second contains the scratch pixmap changes and the other misc stuff. Yes, I could split the misc changes out into another cleanup patch if you want. * Removed the tiling check from intel_present when flipping. The kernel doesn't appear to ever require matching tiling. * Removed call to dixPrivateKeyRegistered in the 'Add glamor back' patch. What I didn't do is clean up the 'remove glamor' patch so that it would compile even with --enable-glamor. Fixing that seems like noise to me; all of the changes needed to make it work would be immediately un-done when adding glamor back. -- keith.pack...@intel.com pgpeiubNu3VUv.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support
I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. I ran three different desktop environments (current Debian unstable versions): XFCE 4.10 Gnome 3.12 KDE4.13.3 I have not merged DRI2 support when running with Glamor; I've got that working locally, but if you accidentally try indirect rendering, you'll crash the X server with an assert failure. So, this is DRI3 only, at least for now. This patch series also adds a none acceleration mode. It's different from other unaccelerated drivers in offering DRI2 and DRI3 support so that you can run direct rendering. A brief synopsis of the series 1-4 cleanup patches 5 Identify and isolate UXA code; UXA-specific functions are renamed and moved into uxa-specific files. 6 Remove UXA-based Glamor support. This pulls out all of the Glamor calls from UXA rendering paths. This patch only builds with glamor disabled; I didn't worry about the existing glamor code or support for glamor within the rest of the driver. 7-9 Prepare for glamor support. Creates a couple of abstract functions for accel-dependent functionality needed by the initialization and modesetting code. Gets rid of the glamor stubs in intel_glamor.h 10 Add glamor support back in, using the regular glamor API. 11 Add an unaccelerated option (none). This offers fb-only support and is always compiled in to the driver. 12 Delay initial mode set operation until the root window is painted and the server is ready to go. This includes potentially copying an existing fbcon frame buffer to the root window in background none mode, providing support for this in all three acceleration modes. The driver used to support this by copying the fbcon buffer to the screen buffer during early server initialization; this change allows the driver to use regular GC-based CopyArea instead of needing custom rendering code. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
