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
next prev parent reply other threads:[~2013-11-03 22:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 23:13 [PATCH 0/6] Add DRI3000 support to core and i965 drivers Keith Packard
2013-10-31 23:13 ` [PATCH 1/6] drivers/dri/common: A few dri2 functions are not actually DRI2 specific Keith Packard
2013-11-01 17:48 ` Kristian Høgsberg
2013-10-31 23:13 ` [PATCH 2/6] dri/intel: Split out DRI2 buffer update code to separate function Keith Packard
2013-11-01 17:51 ` Kristian Høgsberg
2013-10-31 23:13 ` [PATCH 4/6] dri/intel: Add intel_fd_for_region Keith Packard
2013-11-01 17:58 ` Kristian Høgsberg
2013-10-31 23:13 ` [PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver Keith Packard
2013-11-01 23:48 ` Kristian Høgsberg
2013-11-02 5:31 ` Kristian Høgsberg
2013-11-03 22:35 ` Keith Packard [this message]
2013-11-04 21:00 ` [Mesa-dev] " Ian Romanick
2013-10-31 23:13 ` [PATCH 6/6] Make GLX/dri3 use the Present extension when available Keith Packard
2013-10-31 23:13 ` Keith Packard
[not found] ` <1383261196-25093-4-git-send-email-keithp@keithp.com>
2013-11-04 21:38 ` [Mesa3d-dev] [PATCH 3/6] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd Ian Romanick
2013-11-04 21:38 ` Ian Romanick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r4axf70a.fsf@miki.keithp.com \
--to=keithp@keithp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@gmail.com \
--cc=mesa-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.