-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/03/2013 02:35 PM, Keith Packard wrote: > Kristian Høgsberg <hoegsberg@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > 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----- _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
