[Mesa-dev] [PATCH] glx/dri3: Use a separate xcb connection for Present events
Previously glx was using the xcb connection from Xlib.
It is a problem for several reasons:
. There are issues if Xlib is used in another thread (Present event lost)
. Mixing Present events if you receive some for different windows (ie
the client is having more than one window it renders to)
This patch creates a per-context xcb connection to solve these issues.
Solves: https://bugs.freedesktop.org/show_bug.cgi?id=84252
Tested-by: Tobias Jakobi
Signed-off-by: Axel Davy
---
src/glx/dri3_glx.c | 56 -
src/glx/dri3_priv.h | 1 +
2 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1ddc723..245d32f 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -122,6 +122,7 @@ dri3_destroy_context(struct glx_context *context)
free((char *) context->extensions);
(*psc->core->destroyContext) (pcp->driContext);
+ xcb_disconnect(pcp->xcb_connection);
free(pcp);
}
@@ -171,6 +172,9 @@ dri3_create_context_attribs(struct glx_screen *base,
struct dri3_screen *psc = (struct dri3_screen *) base;
__GLXDRIconfigPrivate *config = (__GLXDRIconfigPrivate *) config_base;
__DRIcontext *shared = NULL;
+ Display *dpy = base->dpy;
+ int screen_num = DefaultScreen(dpy);
+ xcb_connection_t *c = NULL;
uint32_t minor_ver = 1;
uint32_t major_ver = 2;
@@ -198,6 +202,12 @@ dri3_create_context_attribs(struct glx_screen *base,
shared = pcp_shared->driContext;
}
+ /* Create XCB connection for present calls. Do not use the Xlib one,
+* to prevent issues if application uses Xlib in another thread */
+ c = xcb_connect(DisplayString(dpy), &screen_num);
+ if (!c)
+ goto error_exit;
+
pcp = calloc(1, sizeof *pcp);
if (pcp == NULL) {
*error = __DRI_CTX_ERROR_NO_MEMORY;
@@ -244,11 +254,14 @@ dri3_create_context_attribs(struct glx_screen *base,
goto error_exit;
pcp->base.vtable = &dri3_context_vtable;
+ pcp->xcb_connection = c;
return &pcp->base;
error_exit:
free(pcp);
+ if (c)
+ xcb_disconnect(c);
return NULL;
}
@@ -284,8 +297,9 @@ static void
dri3_destroy_drawable(__GLXDRIdrawable *base)
{
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
+ struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
- xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+ xcb_connection_t *c = pcp->xcb_connection;
int i;
(*psc->core->destroyDrawable) (pdraw->driDrawable);
@@ -455,8 +469,9 @@ dri3_handle_present_event(struct dri3_drawable *priv,
xcb_present_generic_event_
static bool
dri3_wait_for_event(__GLXDRIdrawable *pdraw)
{
- xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+ struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+ xcb_connection_t *c = pcp->xcb_connection;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
@@ -478,8 +493,9 @@ static int
dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
{
- xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+ struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+ xcb_connection_t *c = pcp->xcb_connection;
uint32_t msc_serial;
/* Ask for the an event for the target MSC */
@@ -578,7 +594,8 @@ dri3_drawable_gc(struct dri3_drawable *priv)
{
if (!priv->gc) {
uint32_t v;
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ struct dri3_context *pcp = (struct dri3_context *)
__glXGetCurrentContext();
+ xcb_connection_t *c = pcp->xcb_connection;
v = 0;
xcb_create_gc(c,
@@ -637,7 +654,7 @@ dri3_copy_sub_buffer(__GLXDRIdrawable *pdraw, int x, int y,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
struct dri3_screen *psc = (struct dri3_screen *) pdraw->psc;
struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ xcb_connection_t *c = pcp->xcb_connection;
struct dri3_buffer *back;
unsigned flags = __DRI2_FLUSH_DRAWABLE;
@@ -701,7 +718,8 @@ static void
dri3_copy_drawable(struct dri3_drawable *priv, Drawable dest, Drawable src)
{
struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
+ xcb_connection_t *c = pcp->xcb_connection;
dri3_flush(psc, priv, __DRI2_FLUSH_DRAWABLE, 0);
@@ -838,10 +856,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen,
Drawa
Re: [Mesa-dev] non-16byte-aligned constant buffers in gallium?
Hi Roland, GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT or PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT is what you're looking for. I guess the test shouldn't ignore that. The value is 256 for R600 and 4 for GCN. Marek On Sat, Apr 18, 2015 at 5:46 AM, Roland Scheidegger wrote: > Hi, > > when looking at a regression (piglit > ext_transform_feedback-immediate-reuse-uniform-buffer, bug 90081) I > realized that behavior wrt non-size-aligned constant buffers doesn't > seem to be all that clear cut. In particular I'm wondering if what the > test (or rather the state tracker) does is actually ok? > Constant buffers were always really considered to have been consisting > of vec4 of floats (they are accessed with xyzw semantics after all), > hence having a constant buffer with a size not a multiple of 16 bytes > seems rather odd. I wonder though if they need to be handled gracefully > somehow (of course, in usual GL fashion, nobody has any idea that this > spiffy 4-byte transform feedback or whatever different bind point buffer > is going to be used as a constant buffer later), or if this is something > which should be addressed elsewhere. > > Roland > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Possible ideas for optimisations in Mesa
On Fri, Apr 17, 2015 at 1:21 PM, Timothy Arceri wrote:
> Hi all,
>
> Last year I spent a whole bunch of time profiling Mesa looking for areas
> where improvements could be made. Anyway I thought I'd point out a
> couple of things, and see if anyone thinks these are worthwhile
> following up.
>
> 1. While the hash table has been getting a lot of attention lately,
> after running the TF2 benchmark one place that showed up as using more
> cpu than the hash table was the glsl parser. I guess this can be mostly
> solved once mesa has a disk cache for shaders.
>
> But something I came across at the time was this paper describing
> modifying (with apparently little effort) bison to generate a hardcoded
> parser that 2.5-6.5 times faster will generating a slightly bigger
> binary [1].
>
> The resulting project has been lost in the sands of time unfortunately
> so I couldn't try it out.
>
> 2. On most of the old quake engine benchmarks the Intel driver spends
> between 3-4.5% of its time or 400 million calls to glib since this code
> can't be inlined in this bit of code from copy_array_to_vbo_array():
>
> while (count--) {
> memcpy(dst, src, dst_stride);
> src += src_stride;
> dst += dst_stride;
> }
>
> I looked in other drivers but I couldn't see them doing this kind of
> thing. I'd imaging because of its nature this code could be a bottle
> neck. Is there any easy ways to avoid doing this type of copy? Or would
> the only thing possible be to write a complex optimisation?
Yeah, other drivers don't do this. In Gallium, we don't change the
stride when uploading buffers, so in our case src_stride ==
dst_stride.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] non-16byte-aligned constant buffers in gallium?
Ah I totally missed that it's queryable! So I guess this is a test bug then. (Interestingly, the spec doesn't quite tell what happens in the case if a buffer's size isn't sufficiently aligned - if the offset is not sufficiently aligned an error is generated but not if the size isn't. The state table clearly tell though UNIFORM_BUFFER_OFFSET_ALIGNMENT is for both offset and size.) Roland Am 18.04.2015 um 12:03 schrieb Marek Olšák: > Hi Roland, > > GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT or > PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT is what you're looking for. > I guess the test shouldn't ignore that. The value is 256 for R600 and > 4 for GCN. > > Marek > > On Sat, Apr 18, 2015 at 5:46 AM, Roland Scheidegger > wrote: >> Hi, >> >> when looking at a regression (piglit >> ext_transform_feedback-immediate-reuse-uniform-buffer, bug 90081) I >> realized that behavior wrt non-size-aligned constant buffers doesn't >> seem to be all that clear cut. In particular I'm wondering if what the >> test (or rather the state tracker) does is actually ok? >> Constant buffers were always really considered to have been consisting >> of vec4 of floats (they are accessed with xyzw semantics after all), >> hence having a constant buffer with a size not a multiple of 16 bytes >> seems rather odd. I wonder though if they need to be handled gracefully >> somehow (of course, in usual GL fashion, nobody has any idea that this >> spiffy 4-byte transform feedback or whatever different bind point buffer >> is going to be used as a constant buffer later), or if this is something >> which should be addressed elsewhere. >> >> Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/23] i965: Plumb compiler debug logging through a function pointer in brw_compiler
On Friday, April 17, 2015 07:12:00 PM Jason Ekstrand wrote: > --- > src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 ++- > src/mesa/drivers/dri/i965/brw_shader.cpp | 13 + > src/mesa/drivers/dri/i965/brw_shader.h | 2 ++ > src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 11 ++- > 4 files changed, 27 insertions(+), 10 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp > index 35bc241..123bdf7 100644 > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp > @@ -2111,15 +2111,16 @@ fs_generator::generate_code(const cfg_t *cfg, int > dispatch_width) >ralloc_free(annotation.ann); > } > > - static GLuint msg_id = 0; > - _mesa_gl_debug(&brw->ctx, &msg_id, > - MESA_DEBUG_SOURCE_SHADER_COMPILER, > - MESA_DEBUG_TYPE_OTHER, > - MESA_DEBUG_SEVERITY_NOTIFICATION, > + const int debug_str_size = 160; > + char debug_str[debug_str_size]; > + int len; > + len = snprintf(debug_str, debug_str_size, >"%s SIMD%d shader: %d inst, %d loops, %d:%d spills:fills, " >"Promoted %u constants, compacted %d to %d bytes.\n", >stage_abbrev, dispatch_width, before_size / 16, loop_count, >spill_count, fill_count, promoted_constants, before_size, > after_size); > + assert(len < debug_str_size); (void)len; > + brw->intelScreen->compiler->shader_debug_log(debug_str); I don't like that this requires fixed size buffer logic at every call site. It's kinda gross. How about making it printf-like instead? Specifically: http://cgit.freedesktop.org/~kwg/mesa/commit/?h=compiler-divorce&id=1a71535d2de01f8a7ad244d39d801d63493ba5e9 http://cgit.freedesktop.org/~kwg/mesa/commit/?h=compiler-divorce&id=830a25a1f11367e032d8e6a13fa141ff82c06417 (compiler-divorce of my tree has the rebased branch with those patches in, if that's useful to you) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/23] i965: Plumb compiler debug logging through a function pointer in brw_compiler
On Sat, Apr 18, 2015 at 1:55 PM, Kenneth Graunke wrote: > On Friday, April 17, 2015 07:12:00 PM Jason Ekstrand wrote: >> --- >> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 ++- >> src/mesa/drivers/dri/i965/brw_shader.cpp | 13 + >> src/mesa/drivers/dri/i965/brw_shader.h | 2 ++ >> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 11 ++- >> 4 files changed, 27 insertions(+), 10 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp >> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp >> index 35bc241..123bdf7 100644 >> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp >> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp >> @@ -2111,15 +2111,16 @@ fs_generator::generate_code(const cfg_t *cfg, int >> dispatch_width) >>ralloc_free(annotation.ann); >> } >> >> - static GLuint msg_id = 0; >> - _mesa_gl_debug(&brw->ctx, &msg_id, >> - MESA_DEBUG_SOURCE_SHADER_COMPILER, >> - MESA_DEBUG_TYPE_OTHER, >> - MESA_DEBUG_SEVERITY_NOTIFICATION, >> + const int debug_str_size = 160; >> + char debug_str[debug_str_size]; >> + int len; >> + len = snprintf(debug_str, debug_str_size, >>"%s SIMD%d shader: %d inst, %d loops, %d:%d spills:fills, >> " >>"Promoted %u constants, compacted %d to %d bytes.\n", >>stage_abbrev, dispatch_width, before_size / 16, >> loop_count, >>spill_count, fill_count, promoted_constants, before_size, >> after_size); >> + assert(len < debug_str_size); (void)len; >> + brw->intelScreen->compiler->shader_debug_log(debug_str); > > I don't like that this requires fixed size buffer logic at every call > site. It's kinda gross. > > How about making it printf-like instead? Specifically: > http://cgit.freedesktop.org/~kwg/mesa/commit/?h=compiler-divorce&id=1a71535d2de01f8a7ad244d39d801d63493ba5e9 > http://cgit.freedesktop.org/~kwg/mesa/commit/?h=compiler-divorce&id=830a25a1f11367e032d8e6a13fa141ff82c06417 Yeah, that's better. I had thought about it but did the easy thing. Given that you've got the patches written, I'm 100% with doing that instead. --Jason > (compiler-divorce of my tree has the rebased branch with those patches > in, if that's useful to you) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] glx/dri3: Use a separate xcb connection for Present events
Previously glx was using the xcb connection from Xlib.
It is a problem because there are issues if Xlib is used
in another thread (Present event lost)
This patch creates a per-context xcb connection to solve this issue.
Solves: https://bugs.freedesktop.org/show_bug.cgi?id=84252
Tested-by: Tobias Jakobi
Signed-off-by: Axel Davy
v2: use xcb_connection_has_error to check if connection failed, instead
of comparing to NULL (xcb_connect never returns NULL)
v3: put the xcb_connection in dri3_screen, instead of dri3_context
---
There's a strange issue with xcb_get_geometry: If I use the new xcb connection
it fails and the error is a drawable error. If I use the Xlib xcb connection
(what
I did in this patch) it works. If anyone knows why, please tell. We use
xcb_get_geometry
with gallium nine with a different xcb connection than Xlib and it works without
problem.
src/glx/dri3_glx.c | 61 +++--
src/glx/dri3_priv.h | 2 ++
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1ddc723..6f028b8 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -285,7 +285,7 @@ dri3_destroy_drawable(__GLXDRIdrawable *base)
{
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
- xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+ xcb_connection_t *c = psc->xcb_connection;
int i;
(*psc->core->destroyDrawable) (pdraw->driDrawable);
@@ -455,8 +455,9 @@ dri3_handle_present_event(struct dri3_drawable *priv,
xcb_present_generic_event_
static bool
dri3_wait_for_event(__GLXDRIdrawable *pdraw)
{
- xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+ struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
+ xcb_connection_t *c = psc->xcb_connection;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
@@ -478,8 +479,9 @@ static int
dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
{
- xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+ struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
+ xcb_connection_t *c = psc->xcb_connection;
uint32_t msc_serial;
/* Ask for the an event for the target MSC */
@@ -578,7 +580,8 @@ dri3_drawable_gc(struct dri3_drawable *priv)
{
if (!priv->gc) {
uint32_t v;
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
+ xcb_connection_t *c = psc->xcb_connection;
v = 0;
xcb_create_gc(c,
@@ -637,7 +640,7 @@ dri3_copy_sub_buffer(__GLXDRIdrawable *pdraw, int x, int y,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
struct dri3_screen *psc = (struct dri3_screen *) pdraw->psc;
struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ xcb_connection_t *c = psc->xcb_connection;
struct dri3_buffer *back;
unsigned flags = __DRI2_FLUSH_DRAWABLE;
@@ -701,7 +704,7 @@ static void
dri3_copy_drawable(struct dri3_drawable *priv, Drawable dest, Drawable src)
{
struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ xcb_connection_t *c = psc->xcb_connection;
dri3_flush(psc, priv, __DRI2_FLUSH_DRAWABLE, 0);
@@ -838,10 +841,9 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen,
Drawable draw,
unsigned int format, int width, int height, int depth)
{
struct dri3_screen *psc = (struct dri3_screen *) glx_screen;
- Display *dpy = glx_screen->dpy;
struct dri3_buffer *buffer;
__DRIimage *pixmap_buffer;
- xcb_connection_t *c = XGetXCBConnection(dpy);
+ xcb_connection_t *c = psc->xcb_connection;
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
struct xshmfence *shm_fence;
@@ -979,7 +981,7 @@ static void
dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer
*buffer)
{
struct dri3_screen *psc = (struct dri3_screen *) pdraw->base.psc;
- xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+ xcb_connection_t *c = psc->xcb_connection;
if (buffer->own_pixmap)
xcb_free_pixmap(c, buffer->pixmap);
@@ -999,7 +1001,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw,
struct dri3_buffer *buffer)
static void
dri3_flush_present_events(struct dri3_drawable *priv)
{
- xcb_connection_t *c = XGetXCBConnection(priv->base.psc->dpy);
+ struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
+ xcb_connection_t *c = psc->xcb_connection;
[Mesa-dev] [PATCH] vc4: with primconvert, quads follow provoking vertex convention
Signed-off-by: Ilia Mirkin --- src/gallium/drivers/vc4/vc4_screen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/vc4/vc4_screen.c b/src/gallium/drivers/vc4/vc4_screen.c index 84aae91..43742c9 100644 --- a/src/gallium/drivers/vc4/vc4_screen.c +++ b/src/gallium/drivers/vc4/vc4_screen.c @@ -94,6 +94,7 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_SHADOW_MAP: case PIPE_CAP_BLEND_EQUATION_SEPARATE: case PIPE_CAP_TWO_SIDED_STENCIL: +case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION: return 1; /* lying for GL 2.0 */ @@ -126,7 +127,6 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR: case PIPE_CAP_MIXED_COLORBUFFER_FORMATS: case PIPE_CAP_SEAMLESS_CUBE_MAP: -case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION: case PIPE_CAP_TGSI_INSTANCEID: case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY: case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY: -- 2.0.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
