[Mesa-dev] [PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

Keith Packard keithp at keithp.com
Sun Nov 3 14:35:49 PST 2013


Kristian Høgsberg <hoegsberg at gmail.com> writes:

> I sent a reply to the sourceforge addresses in the original emails,
> but I didn't see it show up in the archives.  Trying again with the
> freedesktop addresses.

(sorry for having an ancient shell script with sourceforge addresses in
it)

>> +typedef uint32_t *
>> +(*__DRIdri3Stamp)(__DRIdrawable *drawable);
>
> This looks OK, as long as it's not tied into the xcb special_event
> semantics.  From the way it's used, it looks like a loader can just
> increment this uint32_t when it needs to invalidate the buffer.  Still
> seems like an odd API - a invalidate function would be simpler, but
> I'm guessing it's limited by what you can do if you receive the
> special event in a different thread.

Yeah, I definitely do not want a callback function here. The API was
actually designed from the DRI2 side, not the xcb side as DRI2 has this
uint32_t already sitting there that just needed poking.

> With those changes, we can reuse __DRIimage for DRI3 which makes a lot
> of sense.  The GBM and Wayland backends already use __DRIimage for
> color buffers, but convert them to __DRI2buffer to be able to pass
> them into the DRI driver.  Being able to pass a __DRIimage into the
> driver in getBuffers will simplify those backends, and it should be
> fairly simple to port them to the dri3 driver interface.

Ok, so the first step would be to convert drivers from __DRI2buffer to
__DRIimage, at which point it should be trivial to use __DRIimage to
support DRI3? Or should I just take my existing __DRI3buffer code and
change that into a __DRIimage API and leave the __DRI2buffer code around
in the driver to support DRI2?

I'm game for either approach, but fixing the drivers to export a single
API that can support all of the window systems sure seems like a better
long-term plan...

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131103/81a3288e/attachment.pgp>


More information about the mesa-dev mailing list