Re: [Mesa-dev] [PATCH] intel: Fix initial MakeCurrent for single-buffer drawables
hi, Kristian:
This patch block the startup of desktop-shell client in weston.
Panel surface and background surface share a common context.
First when client redraw panel surface, _mesa_make_current will set
brw->ctx.ViewportInitialized to true.
Later when client redraw background surface, intelMakeCurrent() won't
call intel_prepare_render(). So there isn't drawbuffer for background
surface.
Please check!
thanks
On Tue, 2014-01-21 at 12:39 -0800, Kristian Høgsberg wrote:
> Commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 attempts to eliminate the
> call to intel_update_renderbuffer() in the case where we already have a
> drawbuffer for the drawable. Unfortunately this only checks the
> back left renderbuffer, which breaks in case of single buffer drawables.
>
> This means that the initial viewport will not be set in that case. Instead,
> we now check whether the initial viewport has not been set and the
> drawable size is 0x0, in which case we call out to
> intel_update_renderbuffer().
> This gives us the correct behaviour but also further eliminates a
> call to intel_update_renderbuffer() in the case where we make a newly
> created drawable current with a context that already has an initial viewport.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=73862
>
> Signed-off-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index d6c41e6..9183dda 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -917,7 +917,6 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> if (driContextPriv) {
>struct gl_context *ctx = &brw->ctx;
>struct gl_framebuffer *fb, *readFb;
> - struct intel_renderbuffer *rb = NULL;
>
>if (driDrawPriv == NULL && driReadPriv == NULL) {
> fb = _mesa_get_incomplete_framebuffer();
> @@ -925,7 +924,6 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>} else {
> fb = driDrawPriv->driverPrivate;
> readFb = driReadPriv->driverPrivate;
> - rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
>}
> @@ -937,11 +935,11 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>intel_gles3_srgb_workaround(brw, fb);
>intel_gles3_srgb_workaround(brw, readFb);
>
> - if (rb && !rb->mt) {
> - /* If we don't have buffers for the drawable yet, force a call to
> - * getbuffers here so we can have a default drawable size. */
> + /* If the context viewport hasn't been initialized, force a call out to
> + * the loader to get buffers so we have a drawable size for the initial
> + * viewport. */
> + if (!brw->ctx.ViewportInitialized && fb->Width == 0 && fb->Height == 0)
> intel_prepare_render(brw);
> - }
>
>_mesa_make_current(ctx, fb, readFb);
> } else {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri3_glx.c: Pass NULL DRI drawables into driver for None GLX drawables
> You seem to miss the case when one is None and not the other. > It should return BadDrawable too. > > This particular case seems not handled by the dri2 code either, and the > gallium > state tracker seems to handle it in bindContext, but not the intel code for > example. [Zhang, Xiong Y] For this particular case, are you mean this case: (draw == None && read != None) || (draw != None && read == None) If it is yes, it's better to add this judgement into MakeContextCurrent() in src/glx/glxcurrent.c, so that both dri2_glx and dri3_glx could use it. thanks > > Axel Davy > > On 23/03/2015 08:07, Xiong Zhang wrote : > > GLX_ARB_create_context spec says: > > If either or are not a valid GLX drawable, a > > GLXBadDrawable error is generated, unless and are both > > None and the OpenGL version supported by is 3.0 or greater. > > > > So when both and are None, it could pass NULL drawable > > into driver instead of returing GLXBadDrawable. > > > > v2: Fix spacing issue (Axel Davy) > > > > https://bugs.freedesktop.org/show_bug.cgi?id=79629 > > Signed-off-by: Xiong Zhang > > --- > > src/glx/dri3_glx.c | 12 +--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c index > > e3fc4de..a07e8d4 100644 > > --- a/src/glx/dri3_glx.c > > +++ b/src/glx/dri3_glx.c > > @@ -133,17 +133,23 @@ dri3_bind_context(struct glx_context *context, > struct glx_context *old, > > struct dri3_context *pcp = (struct dri3_context *) context; > > struct dri3_screen *psc = (struct dri3_screen *) pcp->base.psc; > > struct dri3_drawable *pdraw, *pread; > > + __DRIdrawable *dri_draw = NULL, *dri_read = NULL; > > > > pdraw = (struct dri3_drawable *) driFetchDrawable(context, draw); > > pread = (struct dri3_drawable *) driFetchDrawable(context, read); > > > > driReleaseDrawables(&pcp->base); > > > > - if (pdraw == NULL || pread == NULL) > > + if ((pdraw == NULL && draw != None) || (pread == NULL && read != > > + None)) > > return GLXBadDrawable; > > > > - if (!(*psc->core->bindContext) (pcp->driContext, > > - pdraw->driDrawable, > pread->driDrawable)) > > + if (pdraw) > > + dri_draw = pdraw->driDrawable; > > + > > + if (pread) > > + dri_read = pread->driDrawable; > > + > > + if (!(*psc->core->bindContext)(pcp->driContext, dri_draw, > > + dri_read)) > > return GLXBadContext; > > > > return Success; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri3_glx.c: Pass NULL DRI drawables into driver for None GLX drawables
> Le 24/03/2015 06:50, Zhang, Xiong Y a écrit : > >> You seem to miss the case when one is None and not the other. > >> It should return BadDrawable too. > >> > >> This particular case seems not handled by the dri2 code either, and > >> the gallium state tracker seems to handle it in bindContext, but not > >> the intel code for example. > > [Zhang, Xiong Y] For this particular case, are you mean this case: > > (draw == None && read != None) || (draw != None && read == None) If it > > is yes, it's better to add this judgement into MakeContextCurrent() in > src/glx/glxcurrent.c, so that both dri2_glx and dri3_glx could use it. > > > > thanks > > > Yes. > > I imagine putting it into MakeContextCurrent is not a solution, since it means > GLXBadContext will be returned instead of GLXBadDrawable. [Zhang, Xiong Y] Yes, I agree with you. But it is strange that both macro GLXBadContext and Success are value 0. This means we can't identify them in bindContext(). > > Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] dri3_glx.c: Pass NULL DRI drawables into driver for None GLX drawables
Hi Xiong Zhang, > On 25 March 2015 at 08:05, Xiong Zhang wrote: > > GLX_ARB_create_context spec says: > > If either or are not a valid GLX drawable, a > > GLXBadDrawable error is generated, unless and are both > > None and the OpenGL version supported by is 3.0 or greater. > > > > So when both and are None, it could pass NULL drawable > > into driver instead of returing GLXBadDrawable. > > > I'm a bit fresh in the area, but where do we check that the OpenGL version > supported is 3.0 or greater ? Is there an assumption that all > dri2/3 modules support it ? [Zhang, Xiong Y] the patch lack of checking of OpenGL version >= 3.0, I will add it. > > A similar commit has landed for dri2 in mesa 10.2 f658150639c(glx: > Pass NULL DRI drawables into the DRI driver for None GLX drawables). > Shouldn't a similar one be due for dri(1), drisw etc ? Not suggesting that you > should prep one, just asking. > [Zhang, Xiong Y] yes, Both patches resolve the same issues. I think it should be applied to Dri(1), drisw also > From a quick look - if it wasn't for indirect glx, most of these (and patch > 2/3) > changes could be pushed one level up to glxcurrent.c:MakeContextCurrent. Bit > unfortunate about the duplication but that's another story. > [Zhang, Xiong Y] yes, I want to push these to top level also to reduce replicate code. But There are two difficulties: 1. indirect glx and applegl glx are exception, they use a different bind() code structure as driX 2. Until call psc->core->bindContext(), we don't know whether glx_context is a bad context. And Psc->core->bindContext() should be called in driX_bind_context. I mean patch 3 couldn't move To glxCurrent.c > Cheers > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] dri3_glx.c: Pass NULL DRI drawables into driver for None GLX drawables
Hi, Emil: > > On 25 March 2015 at 08:05, Xiong Zhang wrote: > > > GLX_ARB_create_context spec says: > > > If either or are not a valid GLX drawable, a > > > GLXBadDrawable error is generated, unless and are both > > > None and the OpenGL version supported by is 3.0 or greater. > > > > > > So when both and are None, it could pass NULL drawable > > > into driver instead of returing GLXBadDrawable. > > > > > I'm a bit fresh in the area, but where do we check that the OpenGL > > version supported is 3.0 or greater ? Is there an assumption that all > > dri2/3 modules support it ? > > [Zhang, Xiong Y] the patch lack of checking of OpenGL version >= 3.0, I will > add it. [Zhang, Xiong Y] Since GL version is determined by dri drivers like i965, swrast, how could I get GL version in glx code ? Could you give me an extension example that how to implement gl version check in glx / egl code ? thanks > > > > Cheers > > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] Fw: Very low performance when streaming textures
Using the latest mesa master tree, I test it on my Core i7-2600 : 1) In default configuration, the monitor's refresh rate is 60FPS, so the test result is 59.3 FPS 2) export vblank_mode = 0, then the test result is 170 FPS. I don't see the big difference between using direct transfer or using PBO, the test result almost is the same on these two cases. thanks -Original Message- From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org [mailto:intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On Behalf Of Ben Widawsky Sent: Tuesday, January 22, 2013 1:34 PM To: mesa-dev@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Subject: [Intel-gfx] Fw: Very low performance when streaming textures mesa-dev is a better place for this question. Begin forwarded message: Date: Mon, 21 Jan 2013 22:13:34 +0100 From: Marcel Witte To: intel-...@lists.freedesktop.org Subject: [Intel-gfx] Very low performance when streaming textures Hi, I'm refering to the example of this article about streaming textures and using Pixel Buffer Objects: http://www.songho.ca/opengl/gl_pbo.html The PBO Unpack example (http://www.songho.ca/opengl/files/pboUnpack.zip) is creating an "animated texture" and can switch between three modes: Direct transfering of the texture using glTexSubImage2D, and using one or two PBOs for better performance. I'm running this example on an notebook with an Intel Core i7-2630QM and an Nvidia Geforce GT 550M with Optimus. If I'm using the Nvidia card using optirun I get the expected high performance, using direct tranfer about 150 fps and using PBOs about 400 fps. But if I'm using the intel card I get really slow rates, about 40 fps in direct mode and even worse about 10 fps using PBOs. Running the same example with windows I get about 100 fps using the intel card in every mode. Is this expected behaviour or is this a bug in the intel linux driver? How can I improve the performance? I hope you can help me here as I'm writing a real application using a video as texture. Regards, Marcel Witte ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
