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

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/2013 02:35 PM, Keith Packard wrote:
> 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'd be in favor of the latter.

> 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...

I'm not sure how we'd do that and maintain functionality between new
libGL and old drivers (and vice versa).

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlJ4Cu4ACgkQX1gOwKyEAw/F0ACfUI2NyxLo4t7LLxaiGsdv6QBD
L48AnRfc347ZTiJmzhwvpdh+0Dd3sv0D
=r+Kz
-----END PGP SIGNATURE-----