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

From: Keith Packard <keithp@keithp.com>
To: "Kristian Høgsberg" <hoegsberg@gmail.com>
Cc: mesa-dev@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver
Date: Sun, 03 Nov 2013 14:35:49 -0800	[thread overview]
Message-ID: <86r4axf70a.fsf@miki.keithp.com> (raw)
In-Reply-To: <20131102053154.GA4221@tokamak.local>

[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]

Kristian Høgsberg <hoegsberg@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@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev