Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
Keith Packard kei...@keithp.com writes: This sequence first adds a a couple of new DRIimage extensions to the dri/common, dri/i915 and dri/i965 directories which define a loader-independent API for managing window system operations. The last patch adds a new DRI3000 loader using those new interfaces. I've figured out that I can also re-use dri2CreateNewScreen2 for the image driver bits, as long as I change that function to also look up the image loader. That means there are *no* new dri_util functions needed. To recap, the changes needed to support using the DRIimageExtension interfaces for allocating buffers from the driver in the loader are: DRIimageDriverExtension A proper subset of DRIdri2DriverExtension, which uses the same five functions involved in creating new objects: /* Common DRI functions, shared with DRI2 */ __DRIcreateNewScreen2createNewScreen2; __DRIcreateNewDrawable createNewDrawable; __DRIcreateNewContextcreateNewContext; __DRIcreateContextAttribscreateContextAttribs; __DRIgetAPIMask getAPIMask; DRIimageLoaderExtension Contains just two functions, one to allocate buffers and one to copy the fake front to the real front when flushing stuff. /** * Allocate color buffers. * * \param driDrawable * \param width Width of allocated buffers * \param height Height of allocated buffers * \param format one of __DRI_IMAGE_FORMAT_* * \param stamp Address of variable to be updated when * getBuffers must be called again * \param loaderPrivate The loaderPrivate for driDrawable * \param buffer_maskSet of buffers to allocate * \param buffersReturned buffers */ int (*getBuffers)(__DRIdrawable *driDrawable, int *width, int *height, unsigned int format, uint32_t *stamp, void *loaderPrivate, uint32_t buffer_mask, struct __DRIimageList *buffers); /** * Flush pending front-buffer rendering * * Any rendering that has been performed to the * fake front will be flushed to the front * * \param driDrawableDrawable whose front-buffer is to be flushed * \param loaderPrivate Loader's private data that was previously passed * into __DRIdri2ExtensionRec::createNewDrawable */ void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void *loaderPrivate); Each driver will need to have a path to use the image loader to get color buffers using the DRIimageLoaderExtension getBuffers function. -- keith.pack...@intel.com pgpDlPww2zSWI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
Keith Packard kei...@keithp.com writes: Keith Packard kei...@keithp.com writes: This sequence first adds a a couple of new DRIimage extensions to the dri/common, dri/i915 and dri/i965 directories which define a loader-independent API for managing window system operations. The last patch adds a new DRI3000 loader using those new interfaces. I've figured out that I can also re-use dri2CreateNewScreen2 for the image driver bits, as long as I change that function to also look up the image loader. That means there are *no* new dri_util functions needed. To recap, the changes needed to support using the DRIimageExtension interfaces for allocating buffers from the driver in the loader are: DRIimageDriverExtension A proper subset of DRIdri2DriverExtension, which uses the same five functions involved in creating new objects: /* Common DRI functions, shared with DRI2 */ __DRIcreateNewScreen2createNewScreen2; __DRIcreateNewDrawable createNewDrawable; __DRIcreateNewContextcreateNewContext; __DRIcreateContextAttribscreateContextAttribs; __DRIgetAPIMask getAPIMask; It seems like we could just stick these things in __DRI_CORE as opposed to having another new extension to look up. The downside I see there is bugs in the server, which have patches at xserver-driinterface-versions of my tree. (Unfortunately, I'm having a hard time building the server currently, so no testing yet). Having a new extension whose name has nothing to do with the functions in it seems really weird. Also, apologies for not having done this myself for my CreateNewScreen2 change. pgphDoSyjR_a9.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
On Tue, Nov 05, 2013 at 12:04:32PM -0800, Eric Anholt wrote: Keith Packard kei...@keithp.com writes: Keith Packard kei...@keithp.com writes: This sequence first adds a a couple of new DRIimage extensions to the dri/common, dri/i915 and dri/i965 directories which define a loader-independent API for managing window system operations. The last patch adds a new DRI3000 loader using those new interfaces. I've figured out that I can also re-use dri2CreateNewScreen2 for the image driver bits, as long as I change that function to also look up the image loader. That means there are *no* new dri_util functions needed. To recap, the changes needed to support using the DRIimageExtension interfaces for allocating buffers from the driver in the loader are: DRIimageDriverExtension A proper subset of DRIdri2DriverExtension, which uses the same five functions involved in creating new objects: /* Common DRI functions, shared with DRI2 */ __DRIcreateNewScreen2createNewScreen2; __DRIcreateNewDrawable createNewDrawable; __DRIcreateNewContextcreateNewContext; __DRIcreateContextAttribscreateContextAttribs; __DRIgetAPIMask getAPIMask; It seems like we could just stick these things in __DRI_CORE as opposed to having another new extension to look up. The downside I see there is bugs in the server, which have patches at xserver-driinterface-versions of my tree. (Unfortunately, I'm having a hard time building the server currently, so no testing yet). Having a new extension whose name has nothing to do with the functions in it seems really weird. It may make more sense to just extend the existing interfaces, but when we discussed DRIimageDriverExtension, the idea was that we could phase out DRIdri2Extension. I think that still makes sense but introducing more extensions doesn't make this interface better. The way this was done originally was that we have DRIcoreExtension which provided DRI1 support. The DRIdri2Extension extension replaces some of the core functions (it has a createNewScreen that doesn't take a sarea handle, for example...) and allows a loader to implement DRI2, but you have to use both extensions. DRIswrastExtension works in a similar for swrast. The idea was to share the core functionality, but it's obviously messy to have to mix two extensions to get things working. If we're introducing a new extension, I'd suggest we move the functions from DRIcoreExtension that we still use into this new extension and make it completely replace DRIcoreExtension and DRIdri2Extension. The functions from the core extension we still use are: void (*destroyScreen)(__DRIscreen *screen); const __DRIextension **(*getExtensions)(__DRIscreen *screen); int (*getConfigAttrib)(const __DRIconfig *config, unsigned int attrib, unsigned int *value); int (*indexConfigAttrib)(const __DRIconfig *config, int index, unsigned int *attrib, unsigned int *value); void (*destroyDrawable)(__DRIdrawable *drawable); int (*copyContext)(__DRIcontext *dest, __DRIcontext *src, unsigned long mask); void (*destroyContext)(__DRIcontext *context); int (*bindContext)(__DRIcontext *ctx, __DRIdrawable *pdraw, __DRIdrawable *pread); int (*unbindContext)(__DRIcontext *ctx); and if we add those to DRIimageDriverExtension the loader only needs to look for that and the DRIimage extension. Of course, the implementation is already in dri_util.c, we just need to set the function pointers to the DRIcoreExtension functions we share. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
Eric Anholt e...@anholt.net writes: It seems like we could just stick these things in __DRI_CORE as opposed to having another new extension to look up. Having the driver expose this new extension is how I tell that the driver is going to actually call the __DRIimage-based loader; the alternative to a new extension would be to stick a flag in the __DRI_CORE structure. The downside I see there is bugs in the server, which have patches at xserver-driinterface-versions of my tree. (Unfortunately, I'm having a hard time building the server currently, so no testing yet). Having a new extension whose name has nothing to do with the functions in it seems really weird. It defines the interface to a driver which will be using the image loader to allocate color buffers if available. The fact that the image loader and DRI2 loader can both share the same driver interface is a happy coincidence. -- keith.pack...@intel.com pgpUsRp469s5n.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
