-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/03/2013 02:35 PM, Keith Packard wrote:
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'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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev