From: Keith Packard <keithp@keithp.com>
To: "Kristian Høgsberg" <hoegsberg@gmail.com>
Cc: mesa3d-dev@lists.freedesktop.org,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
Date: Wed, 06 Nov 2013 10:09:13 -0800 [thread overview]
Message-ID: <868ux1s8qe.fsf@miki.keithp.com> (raw)
In-Reply-To: <CAOeoa-dGGiLR5cCK1_0mNuH2jNnA9JOzcA2TeTM2mn4-WzvNVA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5075 bytes --]
Kristian Høgsberg <hoegsberg@gmail.com> writes:
> It just the two older create context functions (which fall back to
> calling driCreateContextAtribs) and allocateBuffer and releaseBuffer.
> The two buffer functions are __DRIbuffer specific of course, but we
> can implement them in terms of __DRIimage in dri_util.c now.
I guess the benefit is that we could remove the DRIdri2Extension
functions from each driver and just use the DRIimage-based wrappers in
dri_util then?
We're still stuck with leaving the DRIdri2Extension as the interface
From the loader though.
> There is a third option, which is to pull the functions we need from
> __DRIcoreExtension into the __DRIimageDriverExtension, which then is
> all you need along with __DRIimageExtension. This is as painful in
> the short term as the current __DRIimageDriverExtension, but it lets
> of cut loose of the DRI1 (__DRIcoreExtension has the DRI1
> createNewScreen in it) and DRI2 baggage properly later on. And
> pulling out the functions into a loader private struct as you suggest
> will make it a lot less painful. The functions we move from core to
> _DRIimageDriverExtension will share the same implementation in
> dri_util.c so there's no new code.
That doesn't seem like a crazy plan; at least Image-based loaders would
be simple then; find the DRIimageDriverExtension and that's it.
> Right - I actually like the clean break idea, but if we're going to
> take that pain I want to get rid of all the junk and avoid the awkward
> "use some stuff from __DRIcoreExtension and other stuff from
> __DRIimageDriverExtension" setup. So we should either 1) make
> __DRIimageDriverExtension completely replace __DRIcoreExtension and
> __DRIdri2Extension, or 2) just do a minimal, incremental change (just
> the extension to indicate the support for __DRIimage based
> getbuffers).
If we're going to get drivers to add DRIimageExtension to the list of
exported extensions, then it doesn't seem like it matters which way we
go here -- we can move from 2) to 1) in the future without changing any
drivers, only the dri_util bits and the loaders.
However, if we think that 1) is the way to go, we might as well just do
it as that'd avoid having to ever fix the loaders.
> The difference is that there the loader returns a packed array of the
> buffers the driver asked for. Now we're using a struct which can be
> sparsely populated, so the driver should only look at the fields it
> asked for.
My concern is that the DRI2 drivers always return a front buffer for
pixmap drawables, and I think this is actually required for things to
work right (I have vague memories of hacking at this when I started
this).
How about I just stick the set of returned images back into the
DRIimageList struct:
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index 2601249..2a873d8 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1319,6 +1319,7 @@ enum __DRIimageBufferMask {
};
struct __DRIimageList {
+ uint32_t image_mask;
__DRIimage *back;
__DRIimage *front;
};
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1bb8241..7de7abd 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1208,6 +1208,7 @@ dri3_get_buffers(__DRIdrawable *driDrawable,
struct dri3_drawable *priv = loaderPrivate;
struct dri3_buffer *front, *back;
+ buffers->image_mask = 0;
buffers->front = NULL;
buffers->back = NULL;
@@ -1254,12 +1255,15 @@ dri3_get_buffers(__DRIdrawable *driDrawable,
}
if (front) {
+ buffers->image_mask |= __DRI_IMAGE_BUFFER_FRONT;
buffers->front = front->image;
priv->have_fake_front = !priv->is_pixmap;
}
- if (back)
+ if (back) {
+ buffers->image_mask |= __DRI_IMAGE_BUFFER_BACK;
buffers->back = back->image;
+ }
priv->stamp = stamp;
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
index 90bbbfc..273d455 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1338,7 +1338,7 @@ intel_update_image_buffers(struct brw_context *brw, __DRIdrawable *drawable)
buffer_mask,
&images);
- if (images.front) {
+ if (images.image_mask & __DRI_IMAGE_BUFFER_FRONT) {
assert(front_rb);
drawable->w = images.front->width;
drawable->h = images.front->height;
@@ -1348,7 +1348,7 @@ intel_update_image_buffers(struct brw_context *brw, __DRIdrawable *drawable)
images.front,
__DRI_IMAGE_BUFFER_FRONT);
}
- if (images.back) {
+ if (images.image_mask & __DRI_IMAGE_BUFFER_BACK) {
drawable->w = images.back->width;
drawable->h = images.back->height;
intel_update_image_buffer(brw,
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-11-06 18:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 2:23 [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05 2:23 ` [PATCH 1/8] drivers/dri/common: A few dri2 functions are not actually DRI2 specific Keith Packard
2013-11-05 2:23 ` [PATCH 2/8] dri/intel: Split out DRI2 buffer update code to separate function Keith Packard
2013-11-05 2:23 ` [PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd Keith Packard
2013-11-05 22:23 ` Kristian Høgsberg
2013-11-06 0:52 ` Keith Packard
2013-11-07 5:17 ` Christopher James Halse Rogers
2013-11-07 5:42 ` Keith Packard
2013-11-05 2:23 ` [PATCH 4/8] Define __DRI_IMAGE_FORMAT_SARGB8 Keith Packard
2013-11-05 2:23 ` [PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_* Keith Packard
2013-11-05 3:01 ` Jordan Justen
2013-11-05 4:11 ` Keith Packard
2013-11-05 22:53 ` Jordan Justen
2013-11-05 22:35 ` Kristian Høgsberg
2013-11-06 0:54 ` Keith Packard
2013-11-05 2:23 ` [PATCH 6/8] dri/i915, dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat Keith Packard
2013-11-05 22:37 ` [PATCH 6/8] dri/i915,dri/i965: " Kristian Høgsberg
2013-11-05 2:23 ` [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension Keith Packard
2013-11-05 20:05 ` Eric Anholt
2013-11-05 23:47 ` Keith Packard
2013-11-05 22:59 ` Kristian Høgsberg
2013-11-06 0:59 ` Keith Packard
2013-11-06 2:48 ` Kristian Høgsberg
2013-11-06 6:25 ` Kristian Høgsberg
2013-11-06 14:55 ` Keith Packard
2013-11-06 16:17 ` Kristian Høgsberg
2013-11-06 18:09 ` Keith Packard [this message]
2013-11-06 19:06 ` Kristian Høgsberg
2013-11-06 19:29 ` Keith Packard
2013-11-05 2:23 ` [PATCH 8/8] Add DRI3+Present loader Keith Packard
2013-11-05 23:10 ` Eric Anholt
2013-11-06 2:32 ` Keith Packard
2013-11-05 16:40 ` [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05 20:04 ` Eric Anholt
2013-11-05 22:09 ` Kristian Høgsberg
2013-11-05 23:54 ` Keith Packard
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=868ux1s8qe.fsf@miki.keithp.com \
--to=keithp@keithp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@gmail.com \
--cc=mesa3d-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.