Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Dave Airlie]

On 5 September 2016 at 16:41, Nicolai Hähnle  wrote:
> On 05.09.2016 03:03, Dave Airlie wrote:
>>
>> So currently out-of-tree radv, reuses addrlib (by copying the all
>> the files), and at least wants to share the register and family
>> header files.
>>
>> This is a set of patches to just move those into a shared directory,
>> in advance of proposing that radv goes into mainline at all.
>
>
> I'm in favor. There's a lot more code that should be shared: parts of
> winsys, a lot of the shader code (even with the TGSI-vs-NIR difference), IB
> dumping, common state setting. What's your plan for those?

I think we can work those things out easier in-tree than out most likely.

I suspect the next thing to tackle after this might be the winsys, and
maybe some of the debug features.

I'm not really sure how much of the state setting (apart from init states)
we'd get to sharing, without introducing CPU overheads in the vulkan driver
that we don't probably want to introduce.

Shader code also has lot of extra features in radeonsi that we wouldn't
need in vulkan, esp all the split compile stuff, but we could probably share
some of the loading etc. Also with SPIR-V on OpenGL becoming a thing,
I'd think we possibly want to start considering using NIR instead of TGSI
(and yes I understand the number of painful scenarios).

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/vdapu: use lanczos filter for scaling v4

[Nayan Deshmukh]

Hi Leo,

I have tested your patch with my mplayer and it gives error when I try to
increase the size of the window. It gives the following error:-

X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadPixmap (invalid Pixmap parameter)

Also when I made the back buffer linear instead of the providing the handle
myself,
it was working fine in my system.

Regards,
Nayan

On Fri, Sep 2, 2016 at 8:51 PM, Leo Liu  wrote:

>
>
> On 09/02/2016 10:48 AM, Christian König wrote:
>
> Am 02.09.2016 um 16:10 schrieb Leo Liu:
>
>
>
> On 09/02/2016 09:50 AM, Christian König wrote:
>
> Am 02.09.2016 um 15:27 schrieb Leo Liu:
>
>
>
> On 09/02/2016 02:11 AM, Christian König wrote:
>
> Am 02.09.2016 um 04:03 schrieb Michel Dänzer:
>
> On 02/09/16 10:17 AM, Michel Dänzer wrote:
>
> On 02/09/16 12:58 AM, Leo Liu wrote:
>
> On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
>
> I saw the code in dri3_glx.c and I could somewhat relate some basic
> code structure to the vl_winsys_dri3.c. But I am new to this and not aware
> of the
> terminology that you used about the buffers. Could you please explain what
> needs
> to be done in more detail or point me to where I can read about it.
>
> I believe it's from loader_dri3_helper.c with "is_different_gpu"
> condition true, that will include back buffer and front buffer case.
> you could try only back buffer case for now.
>
>  From a high level, PRIME mainly affects presentation, not so much the
> video decoding / rendering. The important thing is that the buffer used
> for presentation via the Present extension is linear, not tiled. I'm not
> sure whether it makes more sense to allocate a separate linear buffer
> for this purpose, as is done for GLX, or for the vl code to make the
> corresponding back (or front?) buffer linear in the first place.
>
> A separate linear buffer is probably better, actually, since it will
> also be pinned to system memory while it's being shared with another GPU.
>
>
> Yes, I agree. Nayan should also work on avoiding the extra copy which
> currently occur because we can't allocate output buffers directly in the
> format needed for presentation.
>
> The general idea should be to to check during presentation if the format
> in the output surface is displayable directly.
>
>
> Also we have to consider drawable resized case.
>
>
> Actually we don't. Take a look at the VDPAU spec the output surface should
> be send for displaying without considering it's size.
>
> E.g. when the window is 256x256 pixels, but the application allocated an
> output surface of 1024x768 we should still send the whole surface to the X
> server.
>
> It's the job of the application to resize the output surfaces not the one
> of the VDPAU state tracker.
>
>
> I thought this get done by vl compositor from presentation, scaling up or
> down from output surface to back buffer based on the resize.
>
>
> No, that is incorrect. Take a look at the VDPAU spec:
>
> Applications may choose to allow resizing of the presentation queue target
> (which may be e.g. a regular Window when using an X11-based implementation).
>
> *clip_width* and *clip_height* may be used to limit the size of the
> displayed region of a surface, in order to match the specific region that
> was rendered to.
>
> In turn, this allows the application to allocate over-sized (e.g.
> screen-sized) surfaces, but render to a region that matches the current
> size of the video window.
>
> Using this technique, an application's response to window resizing may
> simply be to render to, and display, a different region of the surface,
> rather than de-/re-allocation of surfaces to match the updated window size.
>
>
> This means that we should send the original output surface size to X, no
> matter what size it has or what size the window has it is displayed in.
>
> That wasn't possible with DRI2, that's why we have that workaround with
> the delayed rendering in the mixer.
>
>
> I did a quick hack on single GPU, and tested, this proves the whole idea
> is working including resizing.
> Linear is still displayable, just looks kind of sluggish when playback.
>
> Here is the hack for reference including remove back buffer creating, and
> presentation rendering, use output surface handle for X
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 26db9f2..908ec3a 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -59,6 +59,9 @@ struct vl_screen
> void *
> (*get_private)(struct vl_screen *vscreen);
>
> +   void *
> +   (*set_output_handle)(struct vl_screen *vscreen, struct winsys_handle
> whandle);
> +
> struct pipe_screen *pscreen;
> struct pipe_loader_device *dev;
>  };
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 3d596a6..4908699 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

--- Comment #4 from Michel Dänzer  ---
Created attachment 126214
  --> https://bugs.freedesktop.org/attachment.cgi?id=126214&action=edit
Always use at least two buffers

Does this patch fix the problem?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97260] [bisected] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #39 from Michel Dänzer  ---
It would have been better to file new reports instead of adding comments here.

Anyway, please test the patch I attached to bug 97549.

--- Comment #38 from Dieter Nützel  ---
I got regression wtih 1e3218b... (loader/dri3: Overhaul dri3_update_num_back)
on Turks XT/Ni 6670

for

glxgears: ~5600 fps -> ~2600 fps (~50%)

mesa-demos/objviever 'bobcat.obj': 1415 fps -> ~1300 fps (~8%)

and flickering with Blender 2.76b
'User Preferences...' -> 'Window Draw Method' 'Automatic'
Which is solvable by changing the  'Window Draw Method' to 'Triple Buffer'
and is an app bug like Michel Dänzer told in Bug 97059.

All three are fine, again with 1e3218b reverted.

--- Comment #37 from Dieter Nützel  ---
Have a look at Bug 97549, too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Edward O'Callaghan]

On 09/05/2016 04:41 PM, Nicolai Hähnle wrote:
> On 05.09.2016 03:03, Dave Airlie wrote:
>> So currently out-of-tree radv, reuses addrlib (by copying the all
>> the files), and at least wants to share the register and family
>> header files.
>>
>> This is a set of patches to just move those into a shared directory,
>> in advance of proposing that radv goes into mainline at all.
> 
> I'm in favor. There's a lot more code that should be shared: parts of
> winsys, a lot of the shader code (even with the TGSI-vs-NIR difference),
> IB dumping, common state setting. What's your plan for those?
> 
> Series is
> 
> Reviewed-by: Nicolai Hähnle 

I agree, this series is:

Reviewed-by: Edward O'Callaghan 

> 
>>
>> Dave.
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

Artem  changed:

   What|Removed |Added

 CC||turbono...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glvnd: Fix dynamic GLX entrypoint lookup

[Eric Engestrom]

On Fri, Sep 02, 2016 at 04:12:24PM -0400, Adam Jackson wrote:
> The dynamic dispatch table needs to be sorted properly, the entrypoints
> shouldn't duplicate the 'glX' prefix, and please just use bsearch()
> instead of open-coding it.
> 
> Signed-off-by: Adam Jackson 
> ---
>  src/glx/g_glxglvnddispatchfuncs.c   | 254 
> ++--
>  src/glx/g_glxglvnddispatchindices.h |  36 ++---
>  src/glx/glxglvnd.c  |  32 ++---
>  3 files changed, 161 insertions(+), 161 deletions(-)
> 
> diff --git a/src/glx/g_glxglvnddispatchfuncs.c 
> b/src/glx/g_glxglvnddispatchfuncs.c
> index e6b9c0b..b5e3398 100644
> --- a/src/glx/g_glxglvnddispatchfuncs.c
> +++ b/src/glx/g_glxglvnddispatchfuncs.c
> @@ -17,16 +17,19 @@ const char * const 
> __glXDispatchTableStrings[DI_LAST_INDEX] = {
>  #define __ATTRIB(field) \
>  [DI_##field] = "glX"#field
>  
> +__ATTRIB(BindSwapBarrierSGIX),
>  __ATTRIB(BindTexImageEXT),
>  // glXChooseFBConfig implemented by libglvnd
>  __ATTRIB(ChooseFBConfigSGIX),
>  // glXChooseVisual implemented by libglvnd
>  // glXCopyContext implemented by libglvnd
> +__ATTRIB(CopySubBufferMESA),
>  // glXCreateContext implemented by libglvnd
>  __ATTRIB(CreateContextAttribsARB),
>  __ATTRIB(CreateContextWithConfigSGIX),
>  __ATTRIB(CreateGLXPbufferSGIX),
>  // glXCreateGLXPixmap implemented by libglvnd
> +__ATTRIB(CreateGLXPixmapMESA),
>  __ATTRIB(CreateGLXPixmapWithConfigSGIX),
>  // glXCreateNewContext implemented by libglvnd
>  // glXCreatePbuffer implemented by libglvnd
> @@ -51,54 +54,50 @@ const char * const 
> __glXDispatchTableStrings[DI_LAST_INDEX] = {
>  __ATTRIB(GetFBConfigAttribSGIX),
>  __ATTRIB(GetFBConfigFromVisualSGIX),
>  // glXGetFBConfigs implemented by libglvnd
> +__ATTRIB(GetMscRateOML),
>  // glXGetProcAddress implemented by libglvnd
>  // glXGetProcAddressARB implemented by libglvnd
> +__ATTRIB(GetScreenDriver),
>  // glXGetSelectedEvent implemented by libglvnd
>  __ATTRIB(GetSelectedEventSGIX),
> +__ATTRIB(GetSwapIntervalMESA),
> +__ATTRIB(GetSyncValuesOML),
>  __ATTRIB(GetVideoSyncSGI),
>  // glXGetVisualFromFBConfig implemented by libglvnd
>  __ATTRIB(GetVisualFromFBConfigSGIX),
>  // glXImportContextEXT implemented by libglvnd
>  // glXIsDirect implemented by libglvnd
> +__ATTRIB(JoinSwapGroupSGIX),
>  // glXMakeContextCurrent implemented by libglvnd
>  // glXMakeCurrent implemented by libglvnd
>  // glXQueryContext implemented by libglvnd
>  __ATTRIB(QueryContextInfoEXT),
> +__ATTRIB(QueryCurrentRendererIntegerMESA),
> +__ATTRIB(QueryCurrentRendererStringMESA),
>  // glXQueryDrawable implemented by libglvnd
>  // glXQueryExtension implemented by libglvnd
>  // glXQueryExtensionsString implemented by libglvnd
>  __ATTRIB(QueryGLXPbufferSGIX),
> +__ATTRIB(QueryMaxSwapBarriersSGIX),
> +__ATTRIB(QueryRendererIntegerMESA),
> +__ATTRIB(QueryRendererStringMESA),
>  // glXQueryServerString implemented by libglvnd
>  // glXQueryVersion implemented by libglvnd
> +__ATTRIB(ReleaseBuffersMESA),
>  __ATTRIB(ReleaseTexImageEXT),
>  // glXSelectEvent implemented by libglvnd
>  __ATTRIB(SelectEventSGIX),
>  // glXSwapBuffers implemented by libglvnd
> +__ATTRIB(SwapBuffersMscOML),
> +__ATTRIB(SwapIntervalMESA),
>  __ATTRIB(SwapIntervalSGI),
>  // glXUseXFont implemented by libglvnd
> +__ATTRIB(WaitForMscOML),
> +__ATTRIB(WaitForSbcOML),
>  // glXWaitGL implemented by libglvnd
>  __ATTRIB(WaitVideoSyncSGI),
>  // glXWaitX implemented by libglvnd
>  
> -__ATTRIB(glXBindSwapBarrierSGIX),
> -__ATTRIB(glXCopySubBufferMESA),
> -__ATTRIB(glXCreateGLXPixmapMESA),
> -__ATTRIB(glXGetMscRateOML),
> -__ATTRIB(glXGetScreenDriver),
> -__ATTRIB(glXGetSwapIntervalMESA),
> -__ATTRIB(glXGetSyncValuesOML),
> -__ATTRIB(glXJoinSwapGroupSGIX),
> -__ATTRIB(glXQueryCurrentRendererIntegerMESA),
> -__ATTRIB(glXQueryCurrentRendererStringMESA),
> -__ATTRIB(glXQueryMaxSwapBarriersSGIX),
> -__ATTRIB(glXQueryRendererIntegerMESA),
> -__ATTRIB(glXQueryRendererStringMESA),
> -__ATTRIB(glXReleaseBuffersMESA),
> -__ATTRIB(glXSwapBuffersMscOML),
> -__ATTRIB(glXSwapIntervalMESA),
> -__ATTRIB(glXWaitForMscOML),
> -__ATTRIB(glXWaitForSbcOML),
> -
>  #undef __ATTRIB
>  };
>  
> @@ -557,49 +556,49 @@ static int dispatch_WaitVideoSyncSGI(int divisor, int 
> remainder,
>  
>  
>  
> -static void dispatch_glXBindSwapBarrierSGIX(Display *dpy, GLXDrawable 
> drawable,
> +static void dispatch_BindSwapBarrierSGIX(Display *dpy, GLXDrawable drawable,
>  int barrier)
>  {
> -PFNGLXBINDSWAPBARRIERSGIXPROC pglXBindSwapBarrierSGIX;
> +PFNGLXBINDSWAPBARRIERSGIXPROC pBindSwapBarrierSGIX;
>  __GLXvendorInfo *dd;
>  
>  dd = GetDispatchFromDrawa

Re: [Mesa-dev] [PATCH] gbm: add missing R8 and GR88 formats

[Eric Engestrom]

On Sat, Sep 03, 2016 at 08:52:07AM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark 

Reviewed-by: Eric Engestrom 

> ---
> I would have added RG88 except we seem to have no corresponding
> __DRI_IMAGE_FORMAT_RG88
> 
>  src/gbm/backends/dri/gbm_dri.c | 6 ++
>  src/gbm/main/gbm.h | 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index bd0f348..6295b4f 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -869,6 +869,12 @@ gbm_dri_bo_create(struct gbm_device *gbm,
> bo->base.base.format = format;
>  
> switch (format) {
> +   case GBM_FORMAT_R8:
> +  dri_format =__DRI_IMAGE_FORMAT_R8;

nit: missing space after `=` (although to be fair,
 __DRI_IMAGE_FORMAT_RGB565 is missing it too)

> +  break;
> +   case GBM_FORMAT_GR88:
> +  dri_format = __DRI_IMAGE_FORMAT_GR88;
> +  break;
> case GBM_FORMAT_RGB565:
>dri_format =__DRI_IMAGE_FORMAT_RGB565;
>break;
> diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
> index 293cae6..59daaa1 100644
> --- a/src/gbm/main/gbm.h
> +++ b/src/gbm/main/gbm.h
> @@ -85,6 +85,12 @@ enum gbm_bo_format {
>  /* color index */
>  #define GBM_FORMAT_C8__gbm_fourcc_code('C', '8', ' ', ' ') 
> /* [7:0] C */
>  
> +/* 8 bpp Red */
> +#define GBM_FORMAT_R8__gbm_fourcc_code('R', '8', ' ', ' ') 
> /* [7:0] R */
> +
> +/* 16 bpp RG */
> +#define GBM_FORMAT_GR88  __gbm_fourcc_code('G', 'R', '8', '8') 
> /* [15:0] G:R 8:8 little endian */
> +
>  /* 8 bpp RGB */
>  #define GBM_FORMAT_RGB332__gbm_fourcc_code('R', 'G', 'B', '8') /* [7:0] 
> R:G:B 3:3:2 */
>  #define GBM_FORMAT_BGR233__gbm_fourcc_code('B', 'G', 'R', '8') /* [7:0] 
> B:G:R 2:3:3 */
> -- 
> 2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glvnd: Fix dynamic GLX entrypoint lookup

[Emil Velikov]

On 5 September 2016 at 11:23, Eric Engestrom  wrote:
> On Fri, Sep 02, 2016 at 04:12:24PM -0400, Adam Jackson wrote:
>> The dynamic dispatch table needs to be sorted properly, the entrypoints
>> shouldn't duplicate the 'glX' prefix, and please just use bsearch()
>> instead of open-coding it.
>>
>> Signed-off-by: Adam Jackson 
>> ---
>>  src/glx/g_glxglvnddispatchfuncs.c   | 254 
>> ++--
>>  src/glx/g_glxglvnddispatchindices.h |  36 ++---
>>  src/glx/glxglvnd.c  |  32 ++---
>>  3 files changed, 161 insertions(+), 161 deletions(-)
>>
>> diff --git a/src/glx/g_glxglvnddispatchfuncs.c 
>> b/src/glx/g_glxglvnddispatchfuncs.c
>> index e6b9c0b..b5e3398 100644
>> --- a/src/glx/g_glxglvnddispatchfuncs.c
>> +++ b/src/glx/g_glxglvnddispatchfuncs.c
>> @@ -17,16 +17,19 @@ const char * const 
>> __glXDispatchTableStrings[DI_LAST_INDEX] = {
>>  #define __ATTRIB(field) \
>>  [DI_##field] = "glX"#field
>>
>> +__ATTRIB(BindSwapBarrierSGIX),
>>  __ATTRIB(BindTexImageEXT),
>>  // glXChooseFBConfig implemented by libglvnd
>>  __ATTRIB(ChooseFBConfigSGIX),
>>  // glXChooseVisual implemented by libglvnd
>>  // glXCopyContext implemented by libglvnd
>> +__ATTRIB(CopySubBufferMESA),
>>  // glXCreateContext implemented by libglvnd
>>  __ATTRIB(CreateContextAttribsARB),
>>  __ATTRIB(CreateContextWithConfigSGIX),
>>  __ATTRIB(CreateGLXPbufferSGIX),
>>  // glXCreateGLXPixmap implemented by libglvnd
>> +__ATTRIB(CreateGLXPixmapMESA),
>>  __ATTRIB(CreateGLXPixmapWithConfigSGIX),
>>  // glXCreateNewContext implemented by libglvnd
>>  // glXCreatePbuffer implemented by libglvnd
>> @@ -51,54 +54,50 @@ const char * const 
>> __glXDispatchTableStrings[DI_LAST_INDEX] = {
>>  __ATTRIB(GetFBConfigAttribSGIX),
>>  __ATTRIB(GetFBConfigFromVisualSGIX),
>>  // glXGetFBConfigs implemented by libglvnd
>> +__ATTRIB(GetMscRateOML),
>>  // glXGetProcAddress implemented by libglvnd
>>  // glXGetProcAddressARB implemented by libglvnd
>> +__ATTRIB(GetScreenDriver),
>>  // glXGetSelectedEvent implemented by libglvnd
>>  __ATTRIB(GetSelectedEventSGIX),
>> +__ATTRIB(GetSwapIntervalMESA),
>> +__ATTRIB(GetSyncValuesOML),
>>  __ATTRIB(GetVideoSyncSGI),
>>  // glXGetVisualFromFBConfig implemented by libglvnd
>>  __ATTRIB(GetVisualFromFBConfigSGIX),
>>  // glXImportContextEXT implemented by libglvnd
>>  // glXIsDirect implemented by libglvnd
>> +__ATTRIB(JoinSwapGroupSGIX),
>>  // glXMakeContextCurrent implemented by libglvnd
>>  // glXMakeCurrent implemented by libglvnd
>>  // glXQueryContext implemented by libglvnd
>>  __ATTRIB(QueryContextInfoEXT),
>> +__ATTRIB(QueryCurrentRendererIntegerMESA),
>> +__ATTRIB(QueryCurrentRendererStringMESA),
>>  // glXQueryDrawable implemented by libglvnd
>>  // glXQueryExtension implemented by libglvnd
>>  // glXQueryExtensionsString implemented by libglvnd
>>  __ATTRIB(QueryGLXPbufferSGIX),
>> +__ATTRIB(QueryMaxSwapBarriersSGIX),
>> +__ATTRIB(QueryRendererIntegerMESA),
>> +__ATTRIB(QueryRendererStringMESA),
>>  // glXQueryServerString implemented by libglvnd
>>  // glXQueryVersion implemented by libglvnd
>> +__ATTRIB(ReleaseBuffersMESA),
>>  __ATTRIB(ReleaseTexImageEXT),
>>  // glXSelectEvent implemented by libglvnd
>>  __ATTRIB(SelectEventSGIX),
>>  // glXSwapBuffers implemented by libglvnd
>> +__ATTRIB(SwapBuffersMscOML),
>> +__ATTRIB(SwapIntervalMESA),
>>  __ATTRIB(SwapIntervalSGI),
>>  // glXUseXFont implemented by libglvnd
>> +__ATTRIB(WaitForMscOML),
>> +__ATTRIB(WaitForSbcOML),
>>  // glXWaitGL implemented by libglvnd
>>  __ATTRIB(WaitVideoSyncSGI),
>>  // glXWaitX implemented by libglvnd
>>
>> -__ATTRIB(glXBindSwapBarrierSGIX),
>> -__ATTRIB(glXCopySubBufferMESA),
>> -__ATTRIB(glXCreateGLXPixmapMESA),
>> -__ATTRIB(glXGetMscRateOML),
>> -__ATTRIB(glXGetScreenDriver),
>> -__ATTRIB(glXGetSwapIntervalMESA),
>> -__ATTRIB(glXGetSyncValuesOML),
>> -__ATTRIB(glXJoinSwapGroupSGIX),
>> -__ATTRIB(glXQueryCurrentRendererIntegerMESA),
>> -__ATTRIB(glXQueryCurrentRendererStringMESA),
>> -__ATTRIB(glXQueryMaxSwapBarriersSGIX),
>> -__ATTRIB(glXQueryRendererIntegerMESA),
>> -__ATTRIB(glXQueryRendererStringMESA),
>> -__ATTRIB(glXReleaseBuffersMESA),
>> -__ATTRIB(glXSwapBuffersMscOML),
>> -__ATTRIB(glXSwapIntervalMESA),
>> -__ATTRIB(glXWaitForMscOML),
>> -__ATTRIB(glXWaitForSbcOML),
>> -
>>  #undef __ATTRIB
>>  };
>>
>> @@ -557,49 +556,49 @@ static int dispatch_WaitVideoSyncSGI(int divisor, int 
>> remainder,
>>
>>
>>
>> -static void dispatch_glXBindSwapBarrierSGIX(Display *dpy, GLXDrawable 
>> drawable,
>> +static void dispatch_BindSwapBarrierSGIX(Display *dpy, GLXDrawable drawable,
>>  int barrier)
>>  {
>> -PFNGLXBINDSWAPBAR

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

--- Comment #5 from Eero Tamminen  ---
(In reply to Michel Dänzer from comment #4)
> Created attachment 126214 [details] [review]
> Always use at least two buffers
> 
> Does this patch fix the problem?

Yes, but that's not all...

BXT performance raised a lot in the affected programs end of last week (some
more than the drop, some less than the drop).  This was due Chris' commit
adding BXT & KBL PCI IDs to xf86-video-intel. I assume with this, X will be
using SNA also on BXT instead of the "default acceleration" that uses (slow)
legacy blitter.

So, I did few tests:
* BXT: reverting the "Overhaul dri3_update_num_back" with the new X DDX didn't
affect the performance (same good one)
* BXT: with old X DDX attached patch fixes the drops
* BXT: with new X DDX attached patch doesn't give additional improvement
* SNB: attached patch fixes the drops

Comments:
- This isn't necessarily Mesa issue, but X DDX one
- Something fishy with SNB for which it would be good to get comment from Chris

Still TODO:
-Check modesetting driver perf with the before and after the commit
- Provide requested info from GDB

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm: add missing R8 and GR88 formats

[Rob Clark]

On Mon, Sep 5, 2016 at 6:50 AM, Eric Engestrom
 wrote:
> On Sat, Sep 03, 2016 at 08:52:07AM -0400, Rob Clark wrote:
>> Signed-off-by: Rob Clark 
>
> Reviewed-by: Eric Engestrom 
>
>> ---
>> I would have added RG88 except we seem to have no corresponding
>> __DRI_IMAGE_FORMAT_RG88
>>
>>  src/gbm/backends/dri/gbm_dri.c | 6 ++
>>  src/gbm/main/gbm.h | 6 ++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index bd0f348..6295b4f 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -869,6 +869,12 @@ gbm_dri_bo_create(struct gbm_device *gbm,
>> bo->base.base.format = format;
>>
>> switch (format) {
>> +   case GBM_FORMAT_R8:
>> +  dri_format =__DRI_IMAGE_FORMAT_R8;
>
> nit: missing space after `=` (although to be fair,
>  __DRI_IMAGE_FORMAT_RGB565 is missing it too)

oh, whoops.. I guess easy to miss with things that start with "__".
Thanks for pointing that out, I've fixed it up locally

BR,
-R

>> +  break;
>> +   case GBM_FORMAT_GR88:
>> +  dri_format = __DRI_IMAGE_FORMAT_GR88;
>> +  break;
>> case GBM_FORMAT_RGB565:
>>dri_format =__DRI_IMAGE_FORMAT_RGB565;
>>break;
>> diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
>> index 293cae6..59daaa1 100644
>> --- a/src/gbm/main/gbm.h
>> +++ b/src/gbm/main/gbm.h
>> @@ -85,6 +85,12 @@ enum gbm_bo_format {
>>  /* color index */
>>  #define GBM_FORMAT_C8__gbm_fourcc_code('C', '8', ' ', ' ') 
>> /* [7:0] C */
>>
>> +/* 8 bpp Red */
>> +#define GBM_FORMAT_R8__gbm_fourcc_code('R', '8', ' ', ' ') 
>> /* [7:0] R */
>> +
>> +/* 16 bpp RG */
>> +#define GBM_FORMAT_GR88  __gbm_fourcc_code('G', 'R', '8', '8') 
>> /* [15:0] G:R 8:8 little endian */
>> +
>>  /* 8 bpp RGB */
>>  #define GBM_FORMAT_RGB332__gbm_fourcc_code('R', 'G', 'B', '8') /* [7:0] 
>> R:G:B 3:3:2 */
>>  #define GBM_FORMAT_BGR233__gbm_fourcc_code('B', 'G', 'R', '8') /* [7:0] 
>> B:G:R 2:3:3 */
>> --
>> 2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] mesa 12.0.2

[Emil Velikov]

Hi all,

Mesa 12.0.2 is now available.

The current release fixes crashes in GLX, EGL and Wayland-EGL, resolves a
number of memory leaks in the video decoding drivers, makes the Intel Vulkan
driver more robust by exporting only the required symbols (previously we would
get symbol collisions leading to strange behaviour or even crashes).

From Android side of things a deadlock and various memory leaks have been
fixed.

Not to mention the steady amount of driver fixes in i965, nouveau, radeonsi,
freedreno and vc4.


Andreas Boll (1):
  configure.ac: Use ${datarootdir} for --with-vulkan-icddir help string too

Bernard Kilarski (1):
  glx: fix error code when there is no context bound

Brian Paul (4):
  svga: handle mismatched number of samplers, sampler views
  mesa: use _mesa_clear_texture_image() in clear_texture_fields()
  swrast: fix incorrectly positioned putImage() in swrast driver
  mesa: fix format conversion bug in get_tex_rgba_uncompressed()

Chad Versace (2):
  i965: Fix miptree layout for EGLImage-based renderbuffers
  i965: Respect miptree offsets in intel_readpixels_tiled_memcpy()

Christian König (1):
  st/mesa: fix reference counting bug in st_vdpau

Chuck Atkins (1):
  swr: Refactor checks for compiler feature flags

Daniel Scharrer (1):
  mesa: Fix fixed function spot lighting on newer hardware (again)

Dave Airlie (2):
  anv: fix writemask on blit fragment shader.
  st/glsl_to_tgsi: fix st_src_reg_for_double constant.

Emil Velikov (16):
  docs: add sha256 checksums for 12.0.1
  mesa: automake: list builddir before srcdir
  mesa: scons: list builddir before srcdir
  i965: store reference to the context within struct brw_fence (v2)
  anv: remove internal 'validate' layer
  anv: automake: use VISIBILITY_CFLAGS to restrict symbol visibility
  anv: automake: build with -Bsymbolic
  anv: do not export the Vulkan API
  anv: remove dummy VK_DEBUG_MARKER_EXT entry points
  isl: automake: use VISIBILITY_CFLAGS to restrict symbol visibility
  cherry-ignore: temporary(?) drop "a4xx: make sure to actually clamp depth"
  i915: Check return value of screen->image.loader->getBuffers
  Revert "i965/miptree: Set logical_depth0 == 6 for cube maps"
  glx/glvnd: list the strcmp arguments in correct order
  Update version to 12.0.2
  docs: add release notes for 12.0.2

Eric Anholt (4):
  vc4: Close our screen's fd on screen close.
  vc4: Disable early Z with computed depth.
  vc4: Fix a leak of the src[] array of VPM reads in optimization.
  vc4: Fix leak of the bo_handles table.

Francisco Jerez (3):
  i965: Emit SKL VF cache invalidation W/A from brw_emit_pipe_control_flush.
  i965: Make room in the batch epilogue for three more pipe controls.
  i965: Fix remaining flush vs invalidate race conditions in
brw_emit_pipe_control_flush.

Haixia Shi (1):
  platform_android: prevent deadlock in droid_swap_buffers

Ian Romanick (5):
  mesa: Strip arrayness from interface block names in some IO validation
  glsl: Pack integer and double varyings as flat even if
interpolation mode is none
  glcpp: Track the actual version instead of just the version_resolved flag
  glcpp: Only disallow #undef of pre-defined macros on GLSL ES >=
3.00 shaders
  glsl: Mark cube map array sampler types as reserved in GLSL ES 3.10

Ilia Mirkin (16):
  mesa: etc2 online compression is unsupported, don't attempt it
  st/mesa: return appropriate mesa format for ETC texture formats
  mesa: set _NEW_BUFFERS when updating texture bound to current buffers
  nv50,nvc0: srgb rendering is only available for rgba/bgra
  vbo: allow DrawElementsBaseVertex in display lists
  gallium/util: add helper to compute zmin/zmax for a viewport state
  nv50,nvc0: fix depth range when halfz is enabled
  nv50/ir: fix bb positions after exit instructions
  vbo: add basevertex when looking up elements for vbo splitting
  a4xx: only disable depth clipping, not all clipping, when requested
  nv50/ir: make sure cfg iterator always hits all blocks
  main: add missing EXTRA_END in OES_sample_variables get check
  nouveau: always enable at least one RC
  nv30: only bail on color/depth bpp mismatch when surfaces are swizzled
  a4xx: make sure to actually clamp depth as requested
  gk110/ir: fix quadop dall emission

Jan Ziak (2):
  egl/x11: avoid using freed memory if dri2 init fails
  loader: fix memory leak in loader_dri3_open

Jason Ekstrand (31):
  nir/spirv: Don't multiply the push constant block size by 4
  anv: Add a stub for CmdCopyQueryPoolResults on Ivy Bridge
  glsl/types: Fix function type comparison function
  glsl/types: Use _mesa_hash_data for hashing function types
  genxml: Make gen6-7 blending look more like gen8
  anv/pipeline: Unify blend state setup between gen7 and gen8
  anv: Enable indepe

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

--- Comment #6 from Eero Tamminen  ---
With modesetting:

* BXT: similar to new X DDX, perf OK (somewhat below X DDX)
* SNB: perf still bad, but better than with Intel DDX

-> on SNB the attached patch is needed to get performance on previous level
regardless of DDX.

Backtraces are from BXT, both with old (last month) X Intel DDX, before and
after the commit.  Earlier dri3_update_num_back() was called when getting
buffers, now it's called when swapping.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

--- Comment #7 from Eero Tamminen  ---
Created attachment 126221
  --> https://bugs.freedesktop.org/attachment.cgi?id=126221&action=edit
backtrace before change

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97549] [SNB, BXT] up to 40% perf drop from "loader/dri3: Overhaul dri3_update_num_back" commit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97549

--- Comment #8 from Eero Tamminen  ---
Created attachment 126222
  --> https://bugs.freedesktop.org/attachment.cgi?id=126222&action=edit
backtrace after change

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97260] [bisected] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #40 from Dieter Nützel  ---
(In reply to Michel Dänzer from comment #39)
> It would have been better to file new reports instead of adding comments
> here.

Sorry for that Michel.
I've appended it here because it overlap with attachment 125838
https://bugs.freedesktop.org/attachment.cgi?id=125838
and your related from patchwork
https://patchwork.freedesktop.org/patch/106274
Comment #26.

> Anyway, please test the patch I attached to bug 97549.

I did.

FIX the former two on _my_ hardware.
Except Blender, but that was expected...

So you have my T-b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Marek Olšák]

On Fri, Sep 2, 2016 at 9:45 PM, Rob Clark  wrote:
> So, android and blob GLES drivers were left unchecked for too long, and
> now we are stuck with this annoying OES_EGL_image_external extension and
> the expectation that the driver can import multi-planar YUV buffers (via,
> for example, EGL_EXT_image_dma_buf_import), despite the fact that nearly
> all hardware out there needs this lowered to multiple samplers (one per
> plane) and colorspace conversion in the shader.  It would be nice to
> ignore this (mis)feature, except that by now it is required by android.
>
> This patchset adds a TGSI lowering pass to handle 2 or 3 planar YUV.
> And associated logic in mesa/st to append additional sampler view/state
> to handle the additional planes.  There is no change needed in the
> individual gallium drivers (provided you support R8 and R8G8).  The
> extra logic and shader variants only kick in when the shader uses
> samplerExternalOES.
>
> I think I got the _NEW_xyz state handling correct, but that is worth
> a double check from someone who knows that better.
>
> So far, I've only wired this up in fragment shader stage.  I'm not
> entirely sure who in their right mind would be using a YUV image in
> (for example) a geometry shader, but I didn't see anything in the
> OES_EGL_image_external spec that lets us get out of adding variants
> for all the other shader stages, other than that the spec is written
> against GLES 1.1 or GLES 2.0, which doesn't have these extra stages.
> I would be interested in opinions about whether we can weasel our
> way out of compute/tess/geom support and stick to just VS and FS.

I suggest handling YUV in FS only and ignoring all other stages.

>
> I've got some simple test code, which uses gbm to create dmabuf's
> so it should run on any driver:
>
>  https://github.com/robclark/kmscube/commits/yuv-cube
>
> You can find the latest versions of the patches here:
>
>  https://github.com/freedreno/mesa/commits/wip-yuv
>
> Rough list of things TODO:
>
>  + Make sure something validates that user is not requiring too
>many texture slots (ie. using texObj->RequiredTextureImageUnits)
>*before* getting to the point of asserting in atom update path
>which appends the extra U/V sampler slots
>
>  + NIR lowering.. currently nir_lower_tex does have support for
>lowering yuv (used by i965), but it utilizes a new tex_src_plane
>arg, instead of just using additional sampler slots.  Maybe just
>update nir_lower_tex to support both ways?
>
>  + Additional shader stages (at least VS)

Please ignore VS unless there is a known use case.

>
>  + single plane (interleaved) YUV formats?  And seems like android
>wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
>In general I don't want to go too crazy and add every YUV format
>under the sun, but try and limit it to the must-have formats.

Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] egl: return corresponding offset of EGLImage instead of 0.

[Weng Chuanbo]

Hi Emil,

   (Seems something wrong with my company's email, so I use
this one)

   I understand your meaning except the NULL check part. Please
see my questions below.



-Original Message-

From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org
] On Behalf Of Emil Velikov

Sent: Wednesday, August 31, 2016 1:57 AM

To: Weng, Chuanbo 

Cc: ML mesa-dev 

Subject: Re: [Mesa-dev] [PATCH v2] egl: return corresponding offset of
EGLImage instead of 0.



On 30 August 2016 at 18:39, Weng, Chuanbo  wrote:

> Hi Emil,

> Thanks for your review!

> Please see my comments  and questions below.

>

> -Original Message-

> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org
] On

> Behalf Of Emil Velikov

> Sent: Tuesday, August 30, 2016 6:29 PM

> To: Weng, Chuanbo 

> Cc: ML mesa-dev 

> Subject: Re: [Mesa-dev] [PATCH v2] egl: return corresponding offset of
EGLImage instead of 0.

>

> On 25 August 2016 at 18:50, Chuanbo Weng  wrote:

>> The offset should not always be 0. For example, if EGLImage is

>> created from a 2D texture with EGL_GL_TEXTURE_LEVEL=1, then the

>> offset should be the actual start of miplevel 1 in drm bo.

>>

>> v2: version bump on the EGL image interface and add gallium pieces.

>>

>> Signed-off-by: Chuanbo Weng 

>> ---

>>  include/GL/internal/dri_interface.h  | 4 +++-

>>  src/egl/drivers/dri2/egl_dri2.c  | 3 ++-

>>  src/gallium/state_trackers/dri/dri2.c| 8 +++-

>>  src/gbm/backends/dri/gbm_dri.c   | 5 +++--

>>  src/mesa/drivers/dri/i965/intel_screen.c | 9 +++--

> I'm likely the only one here, but I'd suggest splitting things up:

> - introduce flag - include/

> - wire up loaders, one at a time - src/{egl,gbm}

> - implement in driver, one at a time - src/{mesa,gallium}

> [Chuanbo] I'm not sure whether I understand correctly. Do you

> mean that I should split this patch into three patches as you suggested?

>

If you want to go the extreme - five (if you implement the gallium bits),
three otherwise. Before doing anything I'd stick around for a second for
others to voice their preference [against].





>> -   if (!dri->image || dri->image->base.version < 12) {

>> +   if (!dri->image || dri->image->base.version < 12 ||

>> + !dri->image->mapImage) {

> Hmm we want these NULL checks split out and ported to older loader(s).

> Otherwise we will get NULL deref when using older loader + newer dri
module(s).

> [Chuanbo] So we just need to leave it as original?

>

Split it into a preparatory patch, adding the following tag.

CC: 

[Chuanbo] Could you explain " we want these NULL checks split out
and ported to older loader " more detailed?

And what's older loaders? What's newer dri modules?

>From my understanding, the only path in mesa code invokes mapImage is
gbm_dri_bo_map. So if apply my patch code above, no NULL deref will happen.



>

>> --- a/src/mesa/drivers/dri/i965/intel_screen.c

>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c

>

>> +.mapImage   = NULL,

>> +.unmapImage = NULL,

> Consider looking into/implementing the map/unmap interfaces. IIRC there
was an implementation (slightly* different one) a while back [1].

> You really want this if you're thinking for Android and/or CrOS ARC + a
better gralloc [2].

> [Chuanbo] Is it required to implement map/unmap interfaces? Since
I'm not interested in Android and/or CrOS ARC + a better gralloc.

> And I find that blitImage and getCapabilities are not implemented when

> bump verison. So I don’t think it's required to implement map/unmap
interface.

>

You don't have to, thus the "consider". Just trying to get someone from
Intel side excited/involved into this.





-Emil



/me wishes that MS implements a client which can do proper quoting or
people move to one that can 
___

mesa-dev mailing list

mesa-dev@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Rob Clark]

On Mon, Sep 5, 2016 at 12:12 PM, Marek Olšák  wrote:
> On Fri, Sep 2, 2016 at 9:45 PM, Rob Clark  wrote:
>> So, android and blob GLES drivers were left unchecked for too long, and
>> now we are stuck with this annoying OES_EGL_image_external extension and
>> the expectation that the driver can import multi-planar YUV buffers (via,
>> for example, EGL_EXT_image_dma_buf_import), despite the fact that nearly
>> all hardware out there needs this lowered to multiple samplers (one per
>> plane) and colorspace conversion in the shader.  It would be nice to
>> ignore this (mis)feature, except that by now it is required by android.
>>
>> This patchset adds a TGSI lowering pass to handle 2 or 3 planar YUV.
>> And associated logic in mesa/st to append additional sampler view/state
>> to handle the additional planes.  There is no change needed in the
>> individual gallium drivers (provided you support R8 and R8G8).  The
>> extra logic and shader variants only kick in when the shader uses
>> samplerExternalOES.
>>
>> I think I got the _NEW_xyz state handling correct, but that is worth
>> a double check from someone who knows that better.
>>
>> So far, I've only wired this up in fragment shader stage.  I'm not
>> entirely sure who in their right mind would be using a YUV image in
>> (for example) a geometry shader, but I didn't see anything in the
>> OES_EGL_image_external spec that lets us get out of adding variants
>> for all the other shader stages, other than that the spec is written
>> against GLES 1.1 or GLES 2.0, which doesn't have these extra stages.
>> I would be interested in opinions about whether we can weasel our
>> way out of compute/tess/geom support and stick to just VS and FS.
>
> I suggest handling YUV in FS only and ignoring all other stages.

Compute stage might be be reasonable.  I agree the other stages do not
seem too sensible and I doubt they would get much use outside of some
yet-to-be-written piglit tests.

I do have the other stages wired up now (locally).. it isn't all that
difficult to do.  Probably the harder part is writing piglit tests for
them.  I'd be curious what i965 does, I suppose that would seem like
enough of a precedent.  I certainly don't mind dropping the support
for other stages, or maybe stashing off on a branch on github in case
someone eventually comes up with a valid use-case.

But since piglit only tests FS (and has some problems at that, see RFC
patch I sent to piglit list), I guess use in other stages is at least
untested, if supported in i965.

>>
>> I've got some simple test code, which uses gbm to create dmabuf's
>> so it should run on any driver:
>>
>>  https://github.com/robclark/kmscube/commits/yuv-cube
>>
>> You can find the latest versions of the patches here:
>>
>>  https://github.com/freedreno/mesa/commits/wip-yuv
>>
>> Rough list of things TODO:
>>
>>  + Make sure something validates that user is not requiring too
>>many texture slots (ie. using texObj->RequiredTextureImageUnits)
>>*before* getting to the point of asserting in atom update path
>>which appends the extra U/V sampler slots
>>
>>  + NIR lowering.. currently nir_lower_tex does have support for
>>lowering yuv (used by i965), but it utilizes a new tex_src_plane
>>arg, instead of just using additional sampler slots.  Maybe just
>>update nir_lower_tex to support both ways?
>>
>>  + Additional shader stages (at least VS)
>
> Please ignore VS unless there is a known use case.
>
>>
>>  + single plane (interleaved) YUV formats?  And seems like android
>>wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
>>In general I don't want to go too crazy and add every YUV format
>>under the sun, but try and limit it to the must-have formats.
>
> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?

Hmm, no.. (I also don't support it in freedreno, so not entirely sure
what that format is.)

How did you expect that to help?

BR,
-R

> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Marek Olšák]

On Mon, Sep 5, 2016 at 6:32 PM, Rob Clark  wrote:
> On Mon, Sep 5, 2016 at 12:12 PM, Marek Olšák  wrote:
>> On Fri, Sep 2, 2016 at 9:45 PM, Rob Clark  wrote:
>>> So, android and blob GLES drivers were left unchecked for too long, and
>>> now we are stuck with this annoying OES_EGL_image_external extension and
>>> the expectation that the driver can import multi-planar YUV buffers (via,
>>> for example, EGL_EXT_image_dma_buf_import), despite the fact that nearly
>>> all hardware out there needs this lowered to multiple samplers (one per
>>> plane) and colorspace conversion in the shader.  It would be nice to
>>> ignore this (mis)feature, except that by now it is required by android.
>>>
>>> This patchset adds a TGSI lowering pass to handle 2 or 3 planar YUV.
>>> And associated logic in mesa/st to append additional sampler view/state
>>> to handle the additional planes.  There is no change needed in the
>>> individual gallium drivers (provided you support R8 and R8G8).  The
>>> extra logic and shader variants only kick in when the shader uses
>>> samplerExternalOES.
>>>
>>> I think I got the _NEW_xyz state handling correct, but that is worth
>>> a double check from someone who knows that better.
>>>
>>> So far, I've only wired this up in fragment shader stage.  I'm not
>>> entirely sure who in their right mind would be using a YUV image in
>>> (for example) a geometry shader, but I didn't see anything in the
>>> OES_EGL_image_external spec that lets us get out of adding variants
>>> for all the other shader stages, other than that the spec is written
>>> against GLES 1.1 or GLES 2.0, which doesn't have these extra stages.
>>> I would be interested in opinions about whether we can weasel our
>>> way out of compute/tess/geom support and stick to just VS and FS.
>>
>> I suggest handling YUV in FS only and ignoring all other stages.
>
> Compute stage might be be reasonable.  I agree the other stages do not
> seem too sensible and I doubt they would get much use outside of some
> yet-to-be-written piglit tests.
>
> I do have the other stages wired up now (locally).. it isn't all that
> difficult to do.  Probably the harder part is writing piglit tests for
> them.  I'd be curious what i965 does, I suppose that would seem like
> enough of a precedent.  I certainly don't mind dropping the support
> for other stages, or maybe stashing off on a branch on github in case
> someone eventually comes up with a valid use-case.
>
> But since piglit only tests FS (and has some problems at that, see RFC
> patch I sent to piglit list), I guess use in other stages is at least
> untested, if supported in i965.
>
>>>
>>> I've got some simple test code, which uses gbm to create dmabuf's
>>> so it should run on any driver:
>>>
>>>  https://github.com/robclark/kmscube/commits/yuv-cube
>>>
>>> You can find the latest versions of the patches here:
>>>
>>>  https://github.com/freedreno/mesa/commits/wip-yuv
>>>
>>> Rough list of things TODO:
>>>
>>>  + Make sure something validates that user is not requiring too
>>>many texture slots (ie. using texObj->RequiredTextureImageUnits)
>>>*before* getting to the point of asserting in atom update path
>>>which appends the extra U/V sampler slots
>>>
>>>  + NIR lowering.. currently nir_lower_tex does have support for
>>>lowering yuv (used by i965), but it utilizes a new tex_src_plane
>>>arg, instead of just using additional sampler slots.  Maybe just
>>>update nir_lower_tex to support both ways?
>>>
>>>  + Additional shader stages (at least VS)
>>
>> Please ignore VS unless there is a known use case.
>>
>>>
>>>  + single plane (interleaved) YUV formats?  And seems like android
>>>wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
>>>In general I don't want to go too crazy and add every YUV format
>>>under the sun, but try and limit it to the must-have formats.
>>
>> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?
>
> Hmm, no.. (I also don't support it in freedreno, so not entirely sure
> what that format is.)
>
> How did you expect that to help?

It would help if the texture were not layered.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark  wrote:
>>>  + single plane (interleaved) YUV formats?  And seems like android
>>>wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
>>>In general I don't want to go too crazy and add every YUV format
>>>under the sun, but try and limit it to the must-have formats.
>>
>> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?
>
> Hmm, no.. (I also don't support it in freedreno, so not entirely sure
> what that format is.)
>
> How did you expect that to help?

It's the UYVY/YUYV sampler formats (i.e. single-plane YUV formats). I
don't think they do the YUV -> RGB conversion, but you just get the
relevant YUV values. From the docs:

"""
Format names with an embedded underscore are subsampled. R8G8_B8G8 is
a single 32-bit block of two pixels, where the R and B values are
repeated in both pixels.
"""

Supported on nouveau, and I think a few other drivers.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/33] anv: Use blorp for most blits and clears

[Jason Ekstrand]

Everything is now reviewed.  I've also sent two additional patches blorp
which, when placed prior to the anv patches, make the series
regression-free and they've been reviewed by Topi.

Nanley, if you don't mind, I would still like your review on the "use blorp
to implement vkFoo" patches.  They're a complete replacement of the old
blit2d or direct meta entrypoints and it's entirely possible that I've
missed things.  You know the dirty little details of those APIs better than
about anyone else (including myself) so I'll feel much more comfortable if
you've looked over it.

--Jason

On Wed, Aug 31, 2016 at 2:22 PM, Jason Ekstrand 
wrote:

> This little (hah!) series does a bit more blorp reworking and then converts
> most of the Vulkan driver to using blorp for its blit and copy operations.
>
> As it currently stands, it adds a few cts "regresssions" which are really
> because the CTS makes assumptions about rounding in scaled blit operations
> that aren't quite valid.
>
> This series also doesn't 100% remove vulkan meta.  As it stands, blorp
> can't do depth/stencil clears so those are left in meta.  Support could be
> added to blorp (and we could use it from GL) but that's a bit more work and
> I wanted to get this sent out earlier rather than later.
>
> For review, I would recommend that Topi review the first 19 or so and
> Nanley review patch 26+.  For 20-25, I'm not sure.  Kristian may be the
> best one to review since he understands it all but Jordan or Nanley could
> take a crack at it too.
>
> Cc: Topi Pohjolainen 
> Cc: Jordan Justen 
> Cc: Nanley Chery 
> Cc: Chad Versace 
> Cc: Kristian Høgsberg 
>
> Jason Ekstrand (33):
>   intel/isl: Add an isl_swizzle structure and use it for isl_view
> swizzles
>   intel/blorp: Take an isl_swizzle instead of a SWIZZLE
>   intel/blorp: Take a destination swizzle in blorp_blit
>   intel/blorp: Don't assume R8_UINT in convert_to_single_slice
>   intel/blorp: Use the surface format for computing offsets
>   intel/blorp: Fix the early return condition in convert_to_single_slice
>   intel/isl: Fix an assert in get_intratile_offset_sa
>   intel/blorp: Handle 3D surfaces in convert_to_single_slice
>   intel/isl: Add a helper for getting the size of an interleaved pixel
>   intel/blorp: Use isl_get_interleaved_msaa_px_size_sa
>   intel/blorp: Use fake_interleaved_msaa in retile_w_to_y
>   intel/blorp: Stop using the X/YOffset field of RENDER_SURFACE_STATE
>   intel/blorp: Pull the guts of blorp_blit into a helper
>   intel/blorp: Add an entrypoint for doing bit-for-bit copies
>   intel/blorp: Add support for RGB destinations in copies
>   intel/blorp: Add support for clearing R9G9B9E5 surfaces
>   intel/blorp: Make color_write_disable const and optional
>   intel/blorp: Add a swizzle parameter to blorp_clear
>   intel/blorp: Rework alloc_binding_table
>   intel/blorp: Use #defines for all __gen_ helpers
>   anv/pipeline: Roll compute_urb_partition into emit_urb_setup
>   anv: Generalize emit_urb_setup
>   intel/anv: Use #defines for all __gen_ helpers
>   anv: Add initial blorp support
>   anv: Make image_get_surface_for_aspect_mask const
>   anv: Use blorp to implement VkBlitImage
>   anv: Use blorp for CopyImageToBuffer
>   anv: Use blorp for CopyBufferToImage
>   anv: Use blorp for CopyImage
>   anv: Use blorp for CopyBuffer and UpdateBuffer
>   anv: Delete meta_blit2d
>   anv: Use blorp for ClearColorImage
>   anv: Use blorp for doing MSAA resolves
>
>  src/intel/blorp/blorp.c  |7 +-
>  src/intel/blorp/blorp.h  |   19 +-
>  src/intel/blorp/blorp_blit.c |  570 +---
>  src/intel/blorp/blorp_clear.c|   24 +-
>  src/intel/blorp/blorp_genX_exec.h|   25 +-
>  src/intel/blorp/blorp_priv.h |   26 +-
>  src/intel/isl/isl.c  |   22 +-
>  src/intel/isl/isl.h  |   23 +-
>  src/intel/isl/isl_surface_state.c|8 +-
>  src/intel/vulkan/Makefile.am |1 +
>  src/intel/vulkan/Makefile.sources|9 +-
>  src/intel/vulkan/anv_blorp.c |  846 
>  src/intel/vulkan/anv_device.c|4 +
>  src/intel/vulkan/anv_formats.c   |9 +-
>  src/intel/vulkan/anv_genX.h  |9 +
>  src/intel/vulkan/anv_image.c |   27 +-
>  src/intel/vulkan/anv_meta.c  |   21 -
>  src/intel/vulkan/anv_meta.h  |   44 -
>  src/intel/vulkan/anv_meta_blit.c |  739 ---
>  src/intel/vulkan/anv_meta_blit2d.c   | 1544
> --
>  src/intel/vulkan/anv_meta_clear.c|   21 -
>  src/intel/vulkan/anv_meta_copy.c |  479 ---
>  src/intel/vulkan/anv_meta_resolve.c  |  870 
>  src/intel/vulkan/anv_pipeline.c  |  14

[Mesa-dev] [PATCH] gallium/winsys/kms: Close drm device filedescriptor on kms_dri_sw_winsys release

[Lukasz Spintzyk]

Hi,

This patch fixes issue where unloading kernel modules udl or evdi was
impossible due to not closed file descriptor.
As this library is loaded by Xorg after unpluging device the process
is still keeping file open making unload impossible.

Steps to reproduce:
 - Install latest xorg-server:
To reproduce the issue you have to use latest xorg-server 1.18.4
https://lists.x.org/archives/xorg-devel/2016-July/050459.html
(There was an issue fixed in commit 5b4ced6d3a4c309e1792ac49017fb961a7262e7f 
which was crashing xserver and preventing clear device removal)
 - Plug-in usb 2.0 DisplayLink device. Additional display should be added.
 - Unplug usb device.
 - run command rmmod udl
You should see message:
rmmod: ERROR: Module udl is in use

This is my first patch here. I hope that it will not mess-up to much.

regards
Lukasz Spintzyk

Lukasz Spintzyk (1):
  gallium/winsys/kms: Close drm device filedescriptor on
kms_dri_sw_winsys release

 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/winsys/kms: Close drm device filedescriptor on kms_dri_sw_winsys release

[Lukasz Spintzyk]

This closes filedescriptor owned by kms_dri_sw_winsys struct. It fixes issue
where removal of udl or evdi module used by DisplayLink devices was impossible
due to not closed filedescriptors.

When this file descriptor was not closed then command
rmmod udl was returning error "Module udl is in use".
By this fix xserver does not prevent module removal when usb device
is unplugged.

Signed-off-by: Lukasz Spintzyk 
---
 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index 07eca99..f06ccef 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -371,6 +371,9 @@ kms_sw_displaytarget_display(struct sw_winsys *ws,
 static void
 kms_destroy_sw_winsys(struct sw_winsys *winsys)
 {
+   struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
+
+   close(kms_sw->fd);
FREE(winsys);
 }
 
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Rob Clark]

On Mon, Sep 5, 2016 at 12:37 PM, Ilia Mirkin  wrote:
> On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark  wrote:
  + single plane (interleaved) YUV formats?  And seems like android
wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
In general I don't want to go too crazy and add every YUV format
under the sun, but try and limit it to the must-have formats.
>>>
>>> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?
>>
>> Hmm, no.. (I also don't support it in freedreno, so not entirely sure
>> what that format is.)
>>
>> How did you expect that to help?
>
> It's the UYVY/YUYV sampler formats (i.e. single-plane YUV formats). I
> don't think they do the YUV -> RGB conversion, but you just get the
> relevant YUV values. From the docs:
>
> """
> Format names with an embedded underscore are subsampled. R8G8_B8G8 is
> a single 32-bit block of two pixels, where the R and B values are
> repeated in both pixels.
> """
>
> Supported on nouveau, and I think a few other drivers.
>

On Mon, Sep 5, 2016 at 12:36 PM, Marek Olšák  wrote:
>
> It would help if the texture were not layered.

Ahh, gotcha.. tbh I haven't given too much thought to support for
interleaved/422 yuv formats, although I suspect that android would
want that too for camera sorta use-cases.  (All the sensors I have
seen are either raw/bayer or interleaved yuv.)

Some hw seems to support YUYV/UYUV natively.. at least it looked like
vc4 did, and I think a3xx does too (although probably sans the matrix
multiply).  So we might end up wanting some shader cap(s)?

Otoh, I don't mind punting on interleaved YUV.  Just getting video
playback use-case (which is all about planar formats) going is a good
step in the right direction.  (Plus camera support in upstream kernel
is a whole other big mess.)

Fyi, I updated https://github.com/freedreno/mesa/commits/wip-yuv ..
depending on decision about non-FS stages, I might drop some of the
fixup patches and maybe some of the prep-work variant handling
patches.  (Although some of the prep patches might be worth keeping
just to make it easier to resurrect the YUV bits for other stages if
we ever need that.  idk)

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 2/2] mesa/st: support lowering multi-planar YUV

[Marek Olšák]

On Fri, Sep 2, 2016 at 9:45 PM, Rob Clark  wrote:
> Support multi-planar YUV for external EGLImage's (currently just in the
> dma-buf import path) by lowering to multiple texture fetch's for each
> plane and CSC in shader.
>
> Currently lots of TODO's, only NV12 implemented so far, only wired up in
> frag shader, etc, etc..
> ---
>  src/gallium/auxiliary/util/u_inlines.h  |   4 +-
>  src/gallium/include/pipe/p_state.h  |   9 +++
>  src/gallium/include/state_tracker/st_api.h  |   3 +
>  src/gallium/state_trackers/dri/dri2.c   | 111 
> ++--
>  src/gallium/state_trackers/dri/dri_screen.c |  11 +++
>  src/mesa/main/mtypes.h  |  16 
>  src/mesa/program/ir_to_mesa.cpp |   1 +
>  src/mesa/state_tracker/st_atom_sampler.c|  52 -
>  src/mesa/state_tracker/st_atom_shader.c |  27 +++
>  src/mesa/state_tracker/st_atom_texture.c|  71 +-
>  src/mesa/state_tracker/st_cb_eglimage.c |  18 +
>  src/mesa/state_tracker/st_context.c |  10 ++-
>  src/mesa/state_tracker/st_glsl_to_nir.cpp   |   1 +
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp  |   4 +
>  src/mesa/state_tracker/st_manager.c |   1 +
>  src/mesa/state_tracker/st_program.c |  18 +
>  src/mesa/state_tracker/st_program.h |   3 +
>  17 files changed, 330 insertions(+), 30 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_inlines.h 
> b/src/gallium/auxiliary/util/u_inlines.h
> index c2a0b08..b7b8313 100644
> --- a/src/gallium/auxiliary/util/u_inlines.h
> +++ b/src/gallium/auxiliary/util/u_inlines.h
> @@ -136,8 +136,10 @@ pipe_resource_reference(struct pipe_resource **ptr, 
> struct pipe_resource *tex)
> struct pipe_resource *old_tex = *ptr;
>
> if (pipe_reference_described(&(*ptr)->reference, &tex->reference,
> -
> (debug_reference_descriptor)debug_describe_resource))
> +
> (debug_reference_descriptor)debug_describe_resource)) {
> +  pipe_resource_reference(&old_tex->next, NULL);
>old_tex->screen->resource_destroy(old_tex->screen, old_tex);
> +   }
> *ptr = tex;
>  }
>
> diff --git a/src/gallium/include/pipe/p_state.h 
> b/src/gallium/include/pipe/p_state.h
> index ebd0337..4a88da6 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -498,6 +498,15 @@ struct pipe_resource
>
> unsigned bind;/**< bitmask of PIPE_BIND_x */
> unsigned flags;   /**< bitmask of PIPE_RESOURCE_FLAG_x */
> +
> +   /**
> +* For planar images, ie. YUV EGLImage external, etc, pointer to the
> +* next plane.
> +*
> +* TODO might be useful for dealing w/ z32s8 too, since at least a
> +* couple drivers split these out into separate buffers internally.
> +*/
> +   struct pipe_resource *next;

I'm not a fan of this but I don't have a better idea.

>  };
>
>
> diff --git a/src/gallium/include/state_tracker/st_api.h 
> b/src/gallium/include/state_tracker/st_api.h
> index 21d5177..06abfc5 100644
> --- a/src/gallium/include/state_tracker/st_api.h
> +++ b/src/gallium/include/state_tracker/st_api.h
> @@ -200,6 +200,9 @@ struct st_egl_image
> /* this is owned by the caller */
> struct pipe_resource *texture;
>
> +   /* format only differs from texture->format for multi-planar (YUV): */
> +   enum pipe_format format;
> +
> unsigned level;
> unsigned layer;
>  };
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index fdab499..91eabc8 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -83,6 +83,20 @@ static int convert_fourcc(int format, int 
> *dri_components_p)
>format = __DRI_IMAGE_FORMAT_GR88;
>dri_components = __DRI_IMAGE_COMPONENTS_RG;
>break;
> +   /*
> +* For multi-planar YUV formats, we return the format of the first
> +* plane only.  Since there is only one caller which supports multi-
> +* planar YUV it gets to figure out the remaining planes on it's
> +* own.
> +*/
> +   case __DRI_IMAGE_FOURCC_YUV420:
> +  format = __DRI_IMAGE_FORMAT_R8;
> +  dri_components = __DRI_IMAGE_COMPONENTS_Y_U_V;
> +  break;
> +   case __DRI_IMAGE_FOURCC_NV12:
> +  format = __DRI_IMAGE_FORMAT_R8;
> +  dri_components = __DRI_IMAGE_COMPONENTS_Y_UV;
> +  break;
> default:
>return -1;
> }
> @@ -90,6 +104,11 @@ static int convert_fourcc(int format, int 
> *dri_components_p)
> return format;
>  }
>
> +/* NOTE this probably isn't going to do the right thing for YUV images
> + * (but I think the same can be said for intel_query_image()).  I think
> + * only needed for exporting dmabuf's, so I think I won't loose much
> + * sleep over it.
> + */
>  static int convert_to_fourcc(int format)
>  {
> switch(format) {
> @@ -762,14 +781,16 @@ dri2_lookup_egl_image(struct dri_screen *

[Mesa-dev] [Bug 97260] [bisected] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #41 from Dieter Nützel  ---
With Marek's latest Mesa commits (0d7ec8b) it helps even more.
The regression with 'glxgears' and 'objview/bobcat.obj' is much bigger and
FIXED with your patch from bug 97549.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] FPE Invalid Operation

[Bram Stolk]

Hey,

Do you guys test with Floating-Point-Exceptions enabled?
Because on Intel-Haswell, I can trigger a FPE with a simple glClearColor
and glClear.
I think glClear is doing bad FP math on Haswell.

https://software.intel.com/en-us/forums/graphics-driver-bug-
reporting/topic/681580

I recommend doing a:

feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );

In your test-suite.

-- 
Owner/Director of Game Studio Abraham Stolk Inc.
Vancouver BC, Canada
b.st...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] egl: return corresponding offset of EGLImage instead of 0.

[Emil Velikov]

On 5 September 2016 at 17:21, Weng Chuanbo  wrote:

> [Chuanbo] Could you explain " we want these NULL checks split out
> and ported to older loader " more detailed?
>
> And what's older loaders? What's newer dri modules?
>
> From my understanding, the only path in mesa code invokes mapImage is
> gbm_dri_bo_map. So if apply my patch code above, no NULL deref will happen.
>
For this particular exercise we can say that there are three loaders -
src/{gbm,glx,egl}, the interface is in include/ and everything else
can be considered* as dri module/drivers.

So here you want to split out the null checks into a separate patches,
which precede the functional (EGLimage) change. This way the former
can be applied (as they are bugfixes) for older versions of mesa.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] FPE Invalid Operation

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 12:55 PM, Bram Stolk  wrote:
> Hey,
>
> Do you guys test with Floating-Point-Exceptions enabled?

I think most people just test with whatever is the default.

> Because on Intel-Haswell, I can trigger a FPE with a simple glClearColor and
> glClear.
> I think glClear is doing bad FP math on Haswell.
>
> https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/681580

Unfortunately you don't have any debug info for your mesa build.

>
> I recommend doing a:
>
> feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
>
> In your test-suite.

I did that but was unable to trigger the error on a i7-920 CPU and an
NVIDIA GPU (driven by nouveau) in some simple tests. Perhaps a change
in how HSW reports errors, or could be a HSW- (or gen7+) specific code
path.

If you're able to, make a local build, adding -O0 to cflags, and don't
strip the debug info. That should show you exactly where the issue
lies.

Separately, if you can make a small program that reproduces the issue
for you (e.g. with glut + epoxy), that would help others test and
figure out what's going on.

  -ilia

P.S. for reference, this is the (whitespace-damaged) patch I applied
to piglit for my testing:

diff --git a/tests/util/piglit-framework-gl.h b/tests/util/piglit-framework-gl.h
index 81c1a5e..1510fc1 100644
--- a/tests/util/piglit-framework-gl.h
+++ b/tests/util/piglit-framework-gl.h
@@ -235,6 +235,7 @@ void
 piglit_gl_test_run(int argc, char *argv[],
   const struct piglit_gl_test_config *config);

+#include 
 #ifdef __cplusplus
 #  define PIGLIT_EXTERN_C_BEGIN extern "C" {
 #  define PIGLIT_EXTERN_C_END   }
@@ -263,6 +264,7 @@ piglit_gl_test_run(int argc, char *argv[],
 piglit_disable_error_message_boxes();\
  \
 piglit_gl_test_config_init(&config); \
+   feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );   \
  \
 config.init = piglit_init;   \
 config.display = piglit_display; \
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Marek Olšák]

On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
> So currently out-of-tree radv, reuses addrlib (by copying the all
> the files), and at least wants to share the register and family
> header files.
>
> This is a set of patches to just move those into a shared directory,
> in advance of proposing that radv goes into mainline at all.

While I'm not against merging radv, I'd like our (closed) Vulkan
driver to be considered the main and default driver after we open
source it.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] gallium/util: move endian detect into a separate file

[Marek Olšák]

On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This just ports the simpler endian detection bits, addrlib
> sharing wants this outside gallium.
> ---
>  src/gallium/include/pipe/p_config.h | 40 ++-
>  src/util/Makefile.sources   |  3 +-
>  src/util/u_endian.h | 65 
> +
>  3 files changed, 69 insertions(+), 39 deletions(-)
>  create mode 100644 src/util/u_endian.h
>
> diff --git a/src/gallium/include/pipe/p_config.h 
> b/src/gallium/include/pipe/p_config.h
> index 0b570c7..3fa43ed 100644
> --- a/src/gallium/include/pipe/p_config.h
> +++ b/src/gallium/include/pipe/p_config.h
> @@ -126,44 +126,8 @@
>   * Endian detection.
>   */
>
> -#ifdef __GLIBC__
> -#include 
> -
> -#if __BYTE_ORDER == __LITTLE_ENDIAN
> -# define PIPE_ARCH_LITTLE_ENDIAN
> -#elif __BYTE_ORDER == __BIG_ENDIAN
> -# define PIPE_ARCH_BIG_ENDIAN
> -#endif
> -
> -#elif defined(__APPLE__)
> -#include 
> -
> -#if __DARWIN_BYTE_ORDER == __DARWIN_LITTLE_ENDIAN
> -# define PIPE_ARCH_LITTLE_ENDIAN
> -#elif __DARWIN_BYTE_ORDER == __DARWIN_BIG_ENDIAN
> -# define PIPE_ARCH_BIG_ENDIAN
> -#endif
> -
> -#elif defined(__sun)
> -#include 
> -
> -#if defined(_LITTLE_ENDIAN)
> -# define PIPE_ARCH_LITTLE_ENDIAN
> -#elif defined(_BIG_ENDIAN)
> -# define PIPE_ARCH_BIG_ENDIAN
> -#endif
> -
> -#elif defined(__OpenBSD__) || defined(__NetBSD__)
> -#include 
> -#include 
> -
> -#if _BYTE_ORDER == _LITTLE_ENDIAN
> -# define PIPE_ARCH_LITTLE_ENDIAN
> -#elif _BYTE_ORDER == _BIG_ENDIAN
> -# define PIPE_ARCH_BIG_ENDIAN
> -#endif
> -
> -#else
> +#include "util/u_endian.h"
> +#if !defined(PIPE_ARCH_LITTLE_ENDIAN) && !defined(PIPE_ARCH_BIG_ENDIAN)
>
>  #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || 
> defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64)
>  #define PIPE_ARCH_LITTLE_ENDIAN
> diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> index 6def4f7..5950615 100644
> --- a/src/util/Makefile.sources
> +++ b/src/util/Makefile.sources
> @@ -30,7 +30,8 @@ MESA_UTIL_FILES :=\
> strtod.c \
> strtod.h \
> texcompress_rgtc_tmp.h \
> -   u_atomic.h
> +   u_atomic.h \
> +   u_endian.h
>
>  MESA_UTIL_GENERATED_FILES = \
> format_srgb.c
> diff --git a/src/util/u_endian.h b/src/util/u_endian.h
> new file mode 100644
> index 000..57490b2
> --- /dev/null
> +++ b/src/util/u_endian.h
> @@ -0,0 +1,65 @@
> +/**
> + *
> + * Copyright 2007-2008 VMware, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + **/
> +

Missing:

#ifndef U_ENDIAN_H
#define U_ENDIAN_H
...

> +#ifdef __GLIBC__
> +#include 
> +
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +# define PIPE_ARCH_LITTLE_ENDIAN
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +# define PIPE_ARCH_BIG_ENDIAN
> +#endif
> +
> +#elif defined(__APPLE__)
> +#include 
> +
> +#if __DARWIN_BYTE_ORDER == __DARWIN_LITTLE_ENDIAN
> +# define PIPE_ARCH_LITTLE_ENDIAN
> +#elif __DARWIN_BYTE_ORDER == __DARWIN_BIG_ENDIAN
> +# define PIPE_ARCH_BIG_ENDIAN
> +#endif
> +
> +#elif defined(__sun)
> +#include 
> +
> +#if defined(_LITTLE_ENDIAN)
> +# define PIPE_ARCH_LITTLE_ENDIAN
> +#elif defined(_BIG_ENDIAN)
> +# define PIPE_ARCH_BIG_ENDIAN
> +#endif
> +
> +#elif defined(__OpenBSD__) || defined(__NetBSD__)
> +#include 
> +#include 
> +
> +#if _BYTE_ORDER == _LITTLE_ENDIAN
> +# define PIPE_ARCH_LITTLE_ENDIAN
> +#elif _BYTE_ORDER == _BIG_ENDIAN
> +# define PIPE_ARCH_BIG_ENDIAN
> +#endif
> +
> +#endif
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] amd/addrlib: move addrlib from amdgpu winsys to common code

[Marek Olšák]

With my comment at patch 3 addressed, the series is:

Acked-by: Marek Olšák 

Marek

On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> ---
>  src/amd/Makefile.addrlib.am| 35 
> ++
>  src/amd/Makefile.am|  3 ++
>  src/amd/Makefile.sources   | 24 ++-
>  .../amdgpu/drm => amd}/addrlib/addrinterface.cpp   |  0
>  .../amdgpu/drm => amd}/addrlib/addrinterface.h |  0
>  .../winsys/amdgpu/drm => amd}/addrlib/addrtypes.h  |  0
>  .../amdgpu/drm => amd}/addrlib/core/addrcommon.h   |  0
>  .../drm => amd}/addrlib/core/addrelemlib.cpp   |  0
>  .../amdgpu/drm => amd}/addrlib/core/addrelemlib.h  |  0
>  .../amdgpu/drm => amd}/addrlib/core/addrlib.cpp|  0
>  .../amdgpu/drm => amd}/addrlib/core/addrlib.h  |  0
>  .../amdgpu/drm => amd}/addrlib/core/addrobject.cpp |  0
>  .../amdgpu/drm => amd}/addrlib/core/addrobject.h   |  0
>  .../drm => amd}/addrlib/inc/chip/r800/si_gb_reg.h  |  0
>  .../drm => amd}/addrlib/inc/lnx_common_defs.h  |  0
>  .../addrlib/r800/chip/si_ci_vi_merged_enum.h   |  0
>  .../amdgpu/drm => amd}/addrlib/r800/ciaddrlib.cpp  |  0
>  .../amdgpu/drm => amd}/addrlib/r800/ciaddrlib.h|  0
>  .../amdgpu/drm => amd}/addrlib/r800/egbaddrlib.cpp |  0
>  .../amdgpu/drm => amd}/addrlib/r800/egbaddrlib.h   |  0
>  .../amdgpu/drm => amd}/addrlib/r800/siaddrlib.cpp  |  0
>  .../amdgpu/drm => amd}/addrlib/r800/siaddrlib.h|  0
>  .../winsys/amdgpu/drm => amd/common}/amdgpu_id.h   |  2 +-
>  src/gallium/winsys/amdgpu/drm/Makefile.am  |  7 ++---
>  src/gallium/winsys/amdgpu/drm/Makefile.sources | 20 -
>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c  |  2 +-
>  26 files changed, 65 insertions(+), 28 deletions(-)
>  create mode 100644 src/amd/Makefile.addrlib.am
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/addrinterface.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/addrinterface.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/addrtypes.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrcommon.h 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrelemlib.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrelemlib.h 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrlib.cpp (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrlib.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrobject.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/core/addrobject.h 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => 
> amd}/addrlib/inc/chip/r800/si_gb_reg.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/inc/lnx_common_defs.h 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => 
> amd}/addrlib/r800/chip/si_ci_vi_merged_enum.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/ciaddrlib.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/ciaddrlib.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/egbaddrlib.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/egbaddrlib.h 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/siaddrlib.cpp 
> (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd}/addrlib/r800/siaddrlib.h (100%)
>  rename src/{gallium/winsys/amdgpu/drm => amd/common}/amdgpu_id.h (99%)
>
> diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> new file mode 100644
> index 000..434e692
> --- /dev/null
> +++ b/src/amd/Makefile.addrlib.am
> @@ -0,0 +1,35 @@
> +# Copyright 2016 Red Hat Inc.
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the "Software"),
> +# to deal in the Software without restriction, including without limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the next
> +# paragraph) shall be included in all copies or substantial portions of the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> +# IN THE SOFTWARE.
> +
> +ADDRLIB_LIBS = addrlib/libamdgpu_addrlib.la

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Roland Scheidegger]

Am 05.09.2016 um 18:37 schrieb Ilia Mirkin:
> On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark  wrote:
  + single plane (interleaved) YUV formats?  And seems like android
wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
In general I don't want to go too crazy and add every YUV format
under the sun, but try and limit it to the must-have formats.
>>>
>>> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?
>>
>> Hmm, no.. (I also don't support it in freedreno, so not entirely sure
>> what that format is.)
>>
>> How did you expect that to help?
> 
> It's the UYVY/YUYV sampler formats (i.e. single-plane YUV formats). I
> don't think they do the YUV -> RGB conversion, but you just get the
> relevant YUV values. From the docs:
> 
> """
> Format names with an embedded underscore are subsampled. R8G8_B8G8 is
> a single 32-bit block of two pixels, where the R and B values are
> repeated in both pixels.
> """
> 
> Supported on nouveau, and I think a few other drivers.

FWIW these are required by d3d10, so afaik all newer desktop gpus
implement them natively.

Roland

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] FPE Invalid Operation

[Bram Stolk]

>If you're able to, make a local build, adding -O0 to cflags, and don't
>strip the debug info. That should show you exactly where the issue
>lies.

I built mesa 12.0.2 using:
~/src/mesa-12.0.2$ CFLAGS=-O0 ./configure --prefix=$HOME --disable-dri3

If I LD_PRELOAD the resulting libGL.so then the crash goes away and I see
correctly reported:
GL_VERSION  3.3 (Core Profile) Mesa 12.0.2

So maybe it is an old bug, making 11.2.0 affected, but not 12.0.2?
So then I proceeded to build the same version that comes with Ubuntu.

When LD_PRELOAD-ing that libary, I get:

Thread 1 "game" received signal SIGFPE, Arithmetic exception.
0x7fffeecb48e4 in gen7_upload_urb (brw=0x27419b8) at gen7_urb.c:301
301 round(hs_wants * (((double) remaining_space) /
total_wants));
(gdb) where
#0  0x7fffeecb48e4 in gen7_upload_urb (brw=0x27419b8) at gen7_urb.c:301
#1  0x7fffeec95c8c in check_and_emit_atom (brw=0x27419b8,
state=0x7ffe5500, atom=0x2767860) at brw_state_upload.c:771
#2  0x7fffeec961ea in brw_upload_pipeline_state (brw=0x27419b8,
pipeline=BRW_RENDER_PIPELINE) at brw_state_upload.c:882
#3  0x7fffeec962e4 in brw_upload_render_state (brw=0x27419b8) at
brw_state_upload.c:904
#4  0x7fffeec76362 in brw_try_draw_prims (ctx=0x27419b8,
arrays=0x270d010, prims=0x7ffe56c0, nr_prims=1, ib=0x0, min_index=0,
max_index=2, indirect=0x0) at brw_draw.c:560
#5  0x7fffeec76785 in brw_draw_prims (ctx=0x27419b8,
prims=0x7ffe56c0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=2, unused_tfb_object=0x0, stream=0, indirect=0x0)
at brw_draw.c:650
#6  0x7fffeec7fcf5 in brw_draw_rectlist (brw=0x27419b8,
rect=0x7ffe57b0, num_instances=1) at brw_meta_fast_clear.c:219
#7  0x7fffeec80e01 in brw_meta_fast_clear (brw=0x27419b8, fb=0x2722e00,
buffers=34, partial_clear=false) at brw_meta_fast_clear.c:777
#8  0x7fffeec63e23 in brw_clear (ctx=0x27419b8, mask=34) at
brw_clear.c:244
#9  0x7fffee842f66 in _mesa_Clear (mask=17664) at main/clear.c:224
#10 0x77ba43fa in glClear (mask=17664) at
glapi/glapi_mapi_tmp.h:3068
#11 0x00452d4d in Gfx::TargetClear (r=0.0100228256, g=0.0100228256,
b=0.039681904, a=1, depth=1, stencil=0) at ../graphics/graphics.cpp:588
#12 0x0040a739 in Vis::Update (this=0x7ffe5d58,
elapsed=1.7007e-07, numsteps=1, dt=0.0041688, wld=0x7ffe91b0)
at vis.cpp:511
#13 0x00428462 in main (argc=1, argv=0x7fffdd78) at main.cpp:106
(gdb) l
296  vs_chunks += vs_additional;
297  remaining_space -= vs_additional;
298  total_wants -= vs_wants;
299
300  unsigned hs_additional = (unsigned)
301 round(hs_wants * (((double) remaining_space) /
total_wants));
302  hs_chunks += hs_additional;
303  remaining_space -= hs_additional;
304  total_wants -= hs_wants;
305
(gdb) print total_wants
$1 = 0
(gdb)

Even though 12.0.2 seems unaffected:
Ubuntu is using 11.2.0, maybe fixing the v11 tree still makes sense?

I'm also puzzled that this division by zero depends on the values I pass to
glClearColor before the glClear command, though.

Bram

PS: Just a side-note: when I tried re-configuring (after building) my
11.2.0 tree, it choked on pyton mako. I had to delete the entire source
tree, and unpack again before I could re-configure.


On Mon, Sep 5, 2016 at 10:19 AM, Ilia Mirkin  wrote:

> On Mon, Sep 5, 2016 at 12:55 PM, Bram Stolk  wrote:
> > Hey,
> >
> > Do you guys test with Floating-Point-Exceptions enabled?
>
> I think most people just test with whatever is the default.
>
> > Because on Intel-Haswell, I can trigger a FPE with a simple glClearColor
> and
> > glClear.
> > I think glClear is doing bad FP math on Haswell.
> >
> > https://software.intel.com/en-us/forums/graphics-driver-bug-
> reporting/topic/681580
>
> Unfortunately you don't have any debug info for your mesa build.
>
> >
> > I recommend doing a:
> >
> > feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
> >
> > In your test-suite.
>
> I did that but was unable to trigger the error on a i7-920 CPU and an
> NVIDIA GPU (driven by nouveau) in some simple tests. Perhaps a change
> in how HSW reports errors, or could be a HSW- (or gen7+) specific code
> path.
>
> If you're able to, make a local build, adding -O0 to cflags, and don't
> strip the debug info. That should show you exactly where the issue
> lies.
>
> Separately, if you can make a small program that reproduces the issue
> for you (e.g. with glut + epoxy), that would help others test and
> figure out what's going on.
>
>   -ilia
>
> P.S. for reference, this is the (whitespace-damaged) patch I applied
> to piglit for my testing:
>
> diff --git a/tests/util/piglit-framework-gl.h
> b/tests/util/piglit-framework-gl.h
> index 81c1a5e..1510fc1 100644
> --- a/tests/util/piglit-framework-gl.h
> +++ b/tests/util/piglit-framework-gl.h
> @@ -235,6 +235,7 @@ void
>  piglit_gl_test_run(int argc, char *argv[],
>const str

Re: [Mesa-dev] FPE Invalid Operation

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 2:32 PM, Bram Stolk  wrote:
>
>>If you're able to, make a local build, adding -O0 to cflags, and don't
>>strip the debug info. That should show you exactly where the issue
>>lies.
>
> I built mesa 12.0.2 using:
> ~/src/mesa-12.0.2$ CFLAGS=-O0 ./configure --prefix=$HOME --disable-dri3
>
> If I LD_PRELOAD the resulting libGL.so then the crash goes away and I see
> correctly reported:
> GL_VERSION  3.3 (Core Profile) Mesa 12.0.2
>
> So maybe it is an old bug, making 11.2.0 affected, but not 12.0.2?
> So then I proceeded to build the same version that comes with Ubuntu.
>
> When LD_PRELOAD-ing that libary, I get:
>
> Thread 1 "game" received signal SIGFPE, Arithmetic exception.
> 0x7fffeecb48e4 in gen7_upload_urb (brw=0x27419b8) at gen7_urb.c:301
> 301 round(hs_wants * (((double) remaining_space) /
> total_wants));

Ah yes. That was a known bug for gen7+ (IvyBridge+), which was fixed
some time back.

commit 01c89ccc5d1529aa1efbae80c8ef641a59abbd93
Author: Ardinartsev Nikita 
Date:   Wed Jun 22 18:28:11 2016 -0700

i965: Avoid division by zero.

Fixes regression introduced by af5ca43f2676bff7499f93277f908b681cb821d0

Cc: "12.0 11.2" 
Reviewed-by: Matt Turner 
Reviewed-by: Kenneth Graunke 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95419

(And there even was an earlier attempt with 2a8aa1e3deb99 but it got
reverted due to reasons unspecified in the commit log.)

> Even though 12.0.2 seems unaffected:
> Ubuntu is using 11.2.0, maybe fixing the v11 tree still makes sense?

While it was tagged for 11.2.x, I'm not sure that there will be
another 11.2.x release. The 12.0 release has already been out for 2
months, and in general, we only support 1 stable release branch at a
time. (Except right around release time.)

We can't control what distros carry, but if they want to use
out-of-support releases, they're on their own to pick up fixes.

> I'm also puzzled that this division by zero depends on the values I pass to
> glClearColor before the glClear command, though.

Some colors can be fast-cleared while others can't. 0,0,0,1 can be,
while I think 0.5,anything can't. This in turn causes a full draw to
happen, which hits different code paths.

>
> Bram
>
> PS: Just a side-note: when I tried re-configuring (after building) my 11.2.0
> tree, it choked on pyton mako. I had to delete the entire source tree, and
> unpack again before I could re-configure.

The required mako version was recently increased. However it's odd
that running configure would "choke" like that. Sometimes doing a
configure isn't enough to get everything properly rebuilt and you have
to do a "make clean" first.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97542] mesa-12.0.1 with llvm-3.9.0_rc3 - src/gallium/state_trackers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to clang::CompilerInvocation::setLangDefault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97542

Daniel Exner  changed:

   What|Removed |Added

 CC||dex+fdobugzilla@dragonslave
   ||.de

--- Comment #6 from Daniel Exner  ---
Well, I just wanted to bump llvm to the _released_ 3.9.0 and hit this bug when
trying to recompile mesa 12.0.2.

Perhaps it should be noted somewhere that mesa minor version releases only
support the llvm release of the mayor they belong to.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Luke A. Guest]

On 05/09/16 18:41, Marek Olšák wrote:
> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
>> So currently out-of-tree radv, reuses addrlib (by copying the all
>> the files), and at least wants to share the register and family
>> header files.
>>
>> This is a set of patches to just move those into a shared directory,
>> in advance of proposing that radv goes into mainline at all.
> While I'm not against merging radv, I'd like our (closed) Vulkan
> driver to be considered the main and default driver after we open
> source it.
>
When's that likely to be though?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] radeonsi: skip draws with instance_count == 0

[Marek Olšák]

From: Marek Olšák 

loosely ported from Vulkan
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 0a91291..9469bb4 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -875,23 +875,33 @@ void si_ce_post_draw_synchronization(struct si_context 
*sctx)
}
 }
 
 void si_draw_vbo(struct pipe_context *ctx, const struct pipe_draw_info *info)
 {
struct si_context *sctx = (struct si_context *)ctx;
struct si_state_rasterizer *rs = sctx->queued.named.rasterizer;
struct pipe_index_buffer ib = {};
unsigned mask, dirty_fb_counter, dirty_tex_counter, rast_prim;
 
-   if (!info->count && !info->indirect &&
-   (info->indexed || !info->count_from_stream_output))
-   return;
+   if (likely(!info->indirect)) {
+   /* SI-CI treat instance_count==0 as instance_count==1. There is
+* no workaround for indirect draws, but we can at least skip
+* direct draws.
+*/
+   if (unlikely(!info->instance_count))
+   return;
+
+   /* Handle count == 0. */
+   if (unlikely(!info->count &&
+(info->indexed || 
!info->count_from_stream_output)))
+   return;
+   }
 
if (!sctx->vs_shader.cso) {
assert(0);
return;
}
if (!sctx->ps_shader.cso && (!rs || !rs->rasterizer_discard)) {
assert(0);
return;
}
if (!!sctx->tes_shader.cso != (info->mode == PIPE_PRIM_PATCHES)) {
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] gallium/radeon/winsyses: fix counting mapped memory

[Marek Olšák]

From: Marek Olšák 

Not all buffers are unmapped explicitly.
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 8 
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 8 
 2 files changed, 16 insertions(+)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index a4bc474..32df0be 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -144,20 +144,28 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
amdgpu_va_range_free(bo->va_handle);
amdgpu_bo_free(bo->bo);
 
for (i = 0; i < RING_LAST; i++)
   amdgpu_fence_reference(&bo->fence[i], NULL);
 
if (bo->initial_domain & RADEON_DOMAIN_VRAM)
   bo->ws->allocated_vram -= align64(bo->base.size, 
bo->ws->info.gart_page_size);
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
   bo->ws->allocated_gtt -= align64(bo->base.size, 
bo->ws->info.gart_page_size);
+
+   if (bo->map_count >= 1) {
+  if (bo->initial_domain & RADEON_DOMAIN_VRAM)
+ bo->ws->mapped_vram -= bo->base.size;
+  else
+ bo->ws->mapped_gtt -= bo->base.size;
+   }
+
FREE(bo);
 }
 
 static void amdgpu_bo_destroy_or_cache(struct pb_buffer *_buf)
 {
struct amdgpu_winsys_bo *bo = amdgpu_winsys_bo(_buf);
 
if (bo->use_reusable_pool)
   pb_cache_add_buffer(&bo->cache_entry);
else
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 56aab48..5db2061 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -309,20 +309,28 @@ void radeon_bo_destroy(struct pb_buffer *_buf)
 /* Close object. */
 args.handle = bo->handle;
 drmIoctl(rws->fd, DRM_IOCTL_GEM_CLOSE, &args);
 
 pipe_mutex_destroy(bo->map_mutex);
 
 if (bo->initial_domain & RADEON_DOMAIN_VRAM)
 rws->allocated_vram -= align(bo->base.size, rws->info.gart_page_size);
 else if (bo->initial_domain & RADEON_DOMAIN_GTT)
 rws->allocated_gtt -= align(bo->base.size, rws->info.gart_page_size);
+
+if (bo->map_count >= 1) {
+if (bo->initial_domain & RADEON_DOMAIN_VRAM)
+bo->rws->mapped_vram -= bo->base.size;
+else
+bo->rws->mapped_gtt -= bo->base.size;
+}
+
 FREE(bo);
 }
 
 static void radeon_bo_destroy_or_cache(struct pb_buffer *_buf)
 {
struct radeon_bo *bo = radeon_bo(_buf);
 
if (bo->use_reusable_pool)
   pb_cache_add_buffer(&bo->cache_entry);
else
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] radeonsi: skip redundant INDEX_TYPE writes

[Marek Olšák]

From: Marek Olšák 

Ported from Vulkan.
---
 src/gallium/drivers/radeonsi/si_hw_context.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.h   |  1 +
 src/gallium/drivers/radeonsi/si_state_draw.c | 50 +---
 3 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c 
b/src/gallium/drivers/radeonsi/si_hw_context.c
index a03b327..24b0360 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -218,20 +218,21 @@ void si_begin_new_cs(struct si_context *ctx)
si_mark_atom_dirty(ctx, &ctx->b.viewports.atom);
 
r600_postflush_resume_features(&ctx->b);
 
assert(!ctx->b.gfx.cs->prev_dw);
ctx->b.initial_gfx_cs_size = ctx->b.gfx.cs->current.cdw;
 
/* Invalidate various draw states so that they are emitted before
 * the first draw call. */
si_invalidate_draw_sh_constants(ctx);
+   ctx->last_index_size = -1;
ctx->last_primitive_restart_en = -1;
ctx->last_restart_index = SI_RESTART_INDEX_UNKNOWN;
ctx->last_gs_out_prim = -1;
ctx->last_prim = -1;
ctx->last_multi_vgt_param = -1;
ctx->last_ls_hs_config = -1;
ctx->last_rast_prim = -1;
ctx->last_sc_line_stipple = ~0;
ctx->last_vtx_reuse_depth = -1;
ctx->emit_scratch_reloc = true;
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 5c041ce..a648d86 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -300,20 +300,21 @@ struct si_context {
booldb_flush_depth_inplace;
booldb_flush_stencil_inplace;
booldb_depth_clear;
booldb_depth_disable_expclear;
booldb_stencil_clear;
booldb_stencil_disable_expclear;
unsignedps_db_shader_control;
boolocclusion_queries_disabled;
 
/* Emitted draw state. */
+   int last_index_size;
int last_base_vertex;
int last_start_instance;
int last_drawid;
int last_sh_base_reg;
int last_primitive_restart_en;
int last_restart_index;
int last_gs_out_prim;
int last_prim;
int last_multi_vgt_param;
int last_ls_hs_config;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d4447a9..d7325ff 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -546,49 +546,59 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, 
R_028B2C_VGT_STRMOUT_DRAW_OPAQUE_BUFFER_FILLED_SIZE >> 2);
radeon_emit(cs, 0); /* unused */
 
radeon_add_to_buffer_list(&sctx->b, &sctx->b.gfx,
  t->buf_filled_size, RADEON_USAGE_READ,
  RADEON_PRIO_SO_FILLED_SIZE);
}
 
/* draw packet */
if (info->indexed) {
-   radeon_emit(cs, PKT3(PKT3_INDEX_TYPE, 0, 0));
-
-   /* index type */
-   switch (ib->index_size) {
-   case 1:
-   radeon_emit(cs, V_028A7C_VGT_INDEX_8);
-   break;
-   case 2:
-   radeon_emit(cs, V_028A7C_VGT_INDEX_16 |
-   (SI_BIG_ENDIAN && sctx->b.chip_class <= CIK 
?
-V_028A7C_VGT_DMA_SWAP_16_BIT : 0));
-   break;
-   case 4:
-   radeon_emit(cs, V_028A7C_VGT_INDEX_32 |
-   (SI_BIG_ENDIAN && sctx->b.chip_class <= CIK 
?
-V_028A7C_VGT_DMA_SWAP_32_BIT : 0));
-   break;
-   default:
-   assert(!"unreachable");
-   return;
+   if (ib->index_size != sctx->last_index_size) {
+   radeon_emit(cs, PKT3(PKT3_INDEX_TYPE, 0, 0));
+
+   /* index type */
+   switch (ib->index_size) {
+   case 1:
+   radeon_emit(cs, V_028A7C_VGT_INDEX_8);
+   break;
+   case 2:
+   radeon_emit(cs, V_028A7C_VGT_INDEX_16 |
+   (SI_BIG_ENDIAN && 
sctx->b.chip_class <= CIK ?
+
V_028A7C_VGT_DMA_SWAP_16_

[Mesa-dev] [PATCH 3/4] radeonsi: add more unlikely() uses into si_draw_vbo

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_state_draw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 9469bb4..d4447a9 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -889,46 +889,46 @@ void si_draw_vbo(struct pipe_context *ctx, const struct 
pipe_draw_info *info)
 */
if (unlikely(!info->instance_count))
return;
 
/* Handle count == 0. */
if (unlikely(!info->count &&
 (info->indexed || 
!info->count_from_stream_output)))
return;
}
 
-   if (!sctx->vs_shader.cso) {
+   if (unlikely(!sctx->vs_shader.cso)) {
assert(0);
return;
}
-   if (!sctx->ps_shader.cso && (!rs || !rs->rasterizer_discard)) {
+   if (unlikely(!sctx->ps_shader.cso && (!rs || !rs->rasterizer_discard))) 
{
assert(0);
return;
}
-   if (!!sctx->tes_shader.cso != (info->mode == PIPE_PRIM_PATCHES)) {
+   if (unlikely(!!sctx->tes_shader.cso != (info->mode == 
PIPE_PRIM_PATCHES))) {
assert(0);
return;
}
 
/* Re-emit the framebuffer state if needed. */
dirty_fb_counter = p_atomic_read(&sctx->b.screen->dirty_fb_counter);
-   if (dirty_fb_counter != sctx->b.last_dirty_fb_counter) {
+   if (unlikely(dirty_fb_counter != sctx->b.last_dirty_fb_counter)) {
sctx->b.last_dirty_fb_counter = dirty_fb_counter;
sctx->framebuffer.dirty_cbufs |=
((1 << sctx->framebuffer.state.nr_cbufs) - 1);
sctx->framebuffer.dirty_zsbuf = true;
si_mark_atom_dirty(sctx, &sctx->framebuffer.atom);
}
 
/* Invalidate & recompute texture descriptors if needed. */
dirty_tex_counter = 
p_atomic_read(&sctx->b.screen->dirty_tex_descriptor_counter);
-   if (dirty_tex_counter != sctx->b.last_dirty_tex_descriptor_counter) {
+   if (unlikely(dirty_tex_counter != 
sctx->b.last_dirty_tex_descriptor_counter)) {
sctx->b.last_dirty_tex_descriptor_counter = dirty_tex_counter;
si_update_all_texture_descriptors(sctx);
}
 
si_decompress_graphics_textures(sctx);
 
/* Set the rasterization primitive type.
 *
 * This must be done after si_decompress_textures, which can call
 * draw_vbo recursively, and before si_update_shaders, which uses
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Marek Olšák]

On Mon, Sep 5, 2016 at 11:32 PM, Luke A. Guest  wrote:
>
>
> On 05/09/16 18:41, Marek Olšák wrote:
>> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
>>> So currently out-of-tree radv, reuses addrlib (by copying the all
>>> the files), and at least wants to share the register and family
>>> header files.
>>>
>>> This is a set of patches to just move those into a shared directory,
>>> in advance of proposing that radv goes into mainline at all.
>> While I'm not against merging radv, I'd like our (closed) Vulkan
>> driver to be considered the main and default driver after we open
>> source it.
>>
> When's that likely to be though?

I wish I knew that too.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Luke A. Guest]

On 05/09/16 23:49, Marek Olšák wrote:
> On Mon, Sep 5, 2016 at 11:32 PM, Luke A. Guest  wrote:
>>
>> On 05/09/16 18:41, Marek Olšák wrote:
>>> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
 So currently out-of-tree radv, reuses addrlib (by copying the all
 the files), and at least wants to share the register and family
 header files.

 This is a set of patches to just move those into a shared directory,
 in advance of proposing that radv goes into mainline at all.
>>> While I'm not against merging radv, I'd like our (closed) Vulkan
>>> driver to be considered the main and default driver after we open
>>> source it.
>>>
>> When's that likely to be though?
> I wish I knew that too.
>
Ok, but if the radv driver ends up getting there first, you cannot
expect the developers to just wipe it when AMD finally bother to open
their driver just so it can be considered the default? Seems strange.

Luke.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: release GLSL IR in LinkShader after it's not needed

[Timothy Arceri]

Assuming there are no regressions.

Reviewed-by: Timothy Arceri 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Dave Airlie]

On 6 September 2016 at 03:41, Marek Olšák  wrote:
> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
>> So currently out-of-tree radv, reuses addrlib (by copying the all
>> the files), and at least wants to share the register and family
>> header files.
>>
>> This is a set of patches to just move those into a shared directory,
>> in advance of proposing that radv goes into mainline at all.
>
> While I'm not against merging radv, I'd like our (closed) Vulkan
> driver to be considered the main and default driver after we open
> source it.

I think when that happens, we can talk about it, until that happens I'm ignoring
the closed driver, as I can't ship it, so it doesn't exist from my current POV.

I will state on record, that I could be convinced to drop radv in the future,
as it's been a really interesting project and great learning experience, but
if something maintainable and open source friendly appears with an open
not thrown over the wall development methodology, then I'd get behind it.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] radeonsi: add more unlikely() uses into si_draw_vbo

[Michel Dänzer]

On 06/09/16 07:46 AM, Marek Olšák wrote:
> From: Marek Olšák 

Did you measure any significant performance boost with this change?
Otherwise, using (un)likely can be bad because it can defeat the CPU's
branch prediction, which tends to be pretty good these days.


> - if (!sctx->vs_shader.cso) {
> + if (unlikely(!sctx->vs_shader.cso)) {
>   assert(0);
>   return;
>   }
> - if (!sctx->ps_shader.cso && (!rs || !rs->rasterizer_discard)) {
> + if (unlikely(!sctx->ps_shader.cso && (!rs || !rs->rasterizer_discard))) 
> {
>   assert(0);
>   return;
>   }
> - if (!!sctx->tes_shader.cso != (info->mode == PIPE_PRIM_PATCHES)) {
> + if (unlikely(!!sctx->tes_shader.cso != (info->mode == 
> PIPE_PRIM_PATCHES))) {
>   assert(0);
>   return;
>   }

These three are no-brainers though, as these conditions are normally
never true.


>   /* Re-emit the framebuffer state if needed. */
>   dirty_fb_counter = p_atomic_read(&sctx->b.screen->dirty_fb_counter);
> - if (dirty_fb_counter != sctx->b.last_dirty_fb_counter) {
> + if (unlikely(dirty_fb_counter != sctx->b.last_dirty_fb_counter)) {
>   sctx->b.last_dirty_fb_counter = dirty_fb_counter;
>   sctx->framebuffer.dirty_cbufs |=
>   ((1 << sctx->framebuffer.state.nr_cbufs) - 1);
>   sctx->framebuffer.dirty_zsbuf = true;
>   si_mark_atom_dirty(sctx, &sctx->framebuffer.atom);
>   }
>  
>   /* Invalidate & recompute texture descriptors if needed. */
>   dirty_tex_counter = 
> p_atomic_read(&sctx->b.screen->dirty_tex_descriptor_counter);
> - if (dirty_tex_counter != sctx->b.last_dirty_tex_descriptor_counter) {
> + if (unlikely(dirty_tex_counter != 
> sctx->b.last_dirty_tex_descriptor_counter)) {
>   sctx->b.last_dirty_tex_descriptor_counter = dirty_tex_counter;
>   si_update_all_texture_descriptors(sctx);
>   }

But these two might be better left to the CPU's branch prediction.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] radeonsi: add more unlikely() uses into si_draw_vbo

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 9:54 PM, Michel Dänzer  wrote:
> On 06/09/16 07:46 AM, Marek Olšák wrote:
>> From: Marek Olšák 
>
> Did you measure any significant performance boost with this change?
> Otherwise, using (un)likely can be bad because it can defeat the CPU's
> branch prediction, which tends to be pretty good these days.

Is there a way to affect the branch predictor on x86 with instruction
encodings? I didn't think so. I was under the impression that all
likely/unlikely did was to affect placement of the code, i.e. where
the "if" code was placed.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[Andras Schwartz]

https://www.facebook.com/beatrix.beres.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] (no subject)

[Andras Schwartz]

https://www.facebook.com/messages/13832670320
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Michel Dänzer]

From: Michel Dänzer 

This can make a significant difference for performance with some extreme
test cases such as vblank_mode=0 glxgears.

Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
Cc: "12.0 11.2" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
Signed-off-by: Michel Dänzer 
---

I could swear I tested vblank_mode=0 glxgears with my previous change
and couldn't measure any difference, but I can now, so I must have
messed up my previous testing somehow... Apologies for any inconvenience
this caused.

 src/loader/loader_dri3_helper.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 86ae5ae..3ce0352 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable *draw)
 {
if (draw->flipping)
   draw->num_back = 3;
-   else if (draw->vtable->get_swap_interval(draw) != 0)
-  draw->num_back = 2;
else
-  draw->num_back = 1;
+  draw->num_back = 2;
 }
 
 void
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] egl: return corresponding offset of EGLImage instead of 0.

[Weng Chuanbo]

Got it. Thanks for your patient explanation!

2016-09-06 1:14 GMT+08:00 Emil Velikov :

> On 5 September 2016 at 17:21, Weng Chuanbo  wrote:
>
> > [Chuanbo] Could you explain " we want these NULL checks split out
> > and ported to older loader " more detailed?
> >
> > And what's older loaders? What's newer dri modules?
> >
> > From my understanding, the only path in mesa code invokes mapImage is
> > gbm_dri_bo_map. So if apply my patch code above, no NULL deref will
> happen.
> >
> For this particular exercise we can say that there are three loaders -
> src/{gbm,glx,egl}, the interface is in include/ and everything else
> can be considered* as dri module/drivers.
>
> So here you want to split out the null checks into a separate patches,
> which precede the functional (EGLimage) change. This way the former
> can be applied (as they are bugfixes) for older versions of mesa.
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Jason Ekstrand]

On Mon, Sep 5, 2016 at 7:39 PM, Michel Dänzer  wrote:

> From: Michel Dänzer 
>
> This can make a significant difference for performance with some extreme
> test cases such as vblank_mode=0 glxgears.
>
> Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
> Cc: "12.0 11.2" 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
> Signed-off-by: Michel Dänzer 
> ---
>
> I could swear I tested vblank_mode=0 glxgears with my previous change
> and couldn't measure any difference, but I can now, so I must have
> messed up my previous testing somehow... Apologies for any inconvenience
> this caused.
>
>  src/loader/loader_dri3_helper.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_
> helper.c
> index 86ae5ae..3ce0352 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable *draw)
>  {
> if (draw->flipping)
>draw->num_back = 3;
> -   else if (draw->vtable->get_swap_interval(draw) != 0)
> -  draw->num_back = 2;
> else
> -  draw->num_back = 1;
> +  draw->num_back = 2;
>

With this change, the function is logically identical to the old function
with the async flipping case removed.  I'm still not sure why we aren't
getting a stall with 3 butters in the swapinterval=0 flipping case, but if
it doesn't have a perf impact, it must not be a problem.

Reviewed-by: Jason Ekstrand 

Thanks for digging into it to find the real problem. :-)

--Jason


>  }
>
>  void
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv/pipeline: Lower indirect outputs when EmitNoIndirectOutput is set

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Reported-by: Timothy Arceri 
---
 src/intel/vulkan/anv_pipeline.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 35acc4a..9780201 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -186,6 +186,8 @@ anv_shader_compile_to_nir(struct anv_device *device,
nir_variable_mode indirect_mask = 0;
if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
   indirect_mask |= nir_var_shader_in;
+   if (compiler->glsl_compiler_options[stage].EmitNoIndirectOutput)
+  indirect_mask |= nir_var_shader_out;
if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
   indirect_mask |= nir_var_local;
 
-- 
2.5.0.400.gff86faf

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Overhaul dri3_update_num_back

[Michel Dänzer]

On 02/09/16 11:46 PM, Axel Davy wrote:
> Le 02/09/2016 à 16:41, Axel Davy a écrit :
>> Le 02/09/2016 à 03:06, Michel Dänzer a écrit :
>>> On 02/09/16 12:37 AM, Alex Deucher wrote:
 On Thu, Sep 1, 2016 at 11:28 AM, Jason Ekstrand
  wrote:
> On Aug 31, 2016 11:39 PM, "Michel Dänzer"  wrote:
>> On 01/09/16 02:05 PM, Jason Ekstrand wrote:
>>> On Wed, Aug 31, 2016 at 7:00 PM, Michel Dänzer >> > wrote:
>>>
>>>  That said, I'd be interested in hearing about any test cases
>>> where 4
>>>  buffers provide a significant boost over 3.
>>>
>>>
>>> A little history that may be useful: Quadbuffering was originally
>>> added
>>> for DRI3+present here:
>>>
>>>
>>> https://cgit.freedesktop.org/mesa/mesa/commit/?id=f7a36ef5fe23056299a77414f9ad8b5e5a1d
>>>
>> So the commit message claims. If you look at the code after that
>> change
>> though, it's basically impossible to end up with 4 buffers (at least
>> permanently), since it would require all these conditions to be
>> true at
>> the same:
>>
>> 1. priv->flipping (the last Present request was completed as a flip)
>> 2. !(priv->present_capabilities & XCB_PRESENT_CAPABILITY_ASYNC)
>> (the X
>> driver doesn't support async flips)
>> 3. priv->swap_interval == 0
>>
>> Given 2, 1 & 3 are mutually exclusive.
> I'm not seeing how 1 & 3 are mutually exclusive. priv->swap_interval
> doesn't seem to have anything to do with whether or not you're
> flipping.
>>> priv->swap_interval == 0 can only use flips if async flips are
>>> supported.
>> This may not be always true.

It is with the current Present implementation in xserver.


>> In particular with my XWayland Present implementation (yeah it's been
>> years, perhaps time to work on it again), you could have:
>> . 1 buffer on the screen
>> . 1 buffer scheduled for next flip kernel side
>> . 1 buffer old than the previous buffers, and that will get scheduled
>> for flip after if no new buffer arrives (and will be released if a new
>> buffer arrives)
> I meant "newer" of course
>>
>> All three kept by the Wayland compositor.
>> Thus you need a fourth buffer to keep rendering.

The same logic could be implemented in the core Present code in xserver.
My main concern about this is the increased latency due to using a sync
flip. If the application or user sets swap interval 0, I suspect the
intention tends to be to minimize latency. So maybe this logic should
only be used if the driver supports async flips but rejects them in
specific cases, e.g. because the user enabled TearFree.

Anyway, in the meantime, 4 buffers can only make any difference vs 3
buffers with async flips even in theory, and in practice I can only
measure ~1% difference with vblank_mode=0 glxgears in fullscreen (if
anyone can measure a bigger difference with any test case, please let me
know!). Is that enough to justify the additional memory usage for the
4th buffer?

With GpuTest Triangle in fullscreen, I actually get ~0.3% higher numbers
with 3 vs 4 buffers.


> If you use one buffer for swap interval = 0 and no flipping, it means
> you wait for the xserver to handle the presentation request and send the
> answer, before rendering again.
> Before there wasn't this synchronization, because there were two buffers.
> 
> Could this be the cause of the slowdown ?

It was indeed. The thing is, even now I can only measure any significant
difference between one or two buffers with vblank_mode=0 glxgears (not
even e.g. with GpuTest triangle at 800x600 windowed). I thought I tested
that with my previous change but must have messed up somehow. :(


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Michel Dänzer]

On 06/09/16 12:08 PM, Jason Ekstrand wrote:
> On Mon, Sep 5, 2016 at 7:39 PM, Michel Dänzer  > wrote:
> 
> From: Michel Dänzer  >
> 
> This can make a significant difference for performance with some extreme
> test cases such as vblank_mode=0 glxgears.
> 
> Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
> Cc: "12.0 11.2"  >
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
> 
> Signed-off-by: Michel Dänzer  >
> ---
> 
> I could swear I tested vblank_mode=0 glxgears with my previous change
> and couldn't measure any difference, but I can now, so I must have
> messed up my previous testing somehow... Apologies for any inconvenience
> this caused.
> 
>  src/loader/loader_dri3_helper.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> index 86ae5ae..3ce0352 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable
> *draw)
>  {
> if (draw->flipping)
>draw->num_back = 3;
> -   else if (draw->vtable->get_swap_interval(draw) != 0)
> -  draw->num_back = 2;
> else
> -  draw->num_back = 1;
> +  draw->num_back = 2;
> 
> 
> With this change, the function is logically identical to the old
> function with the async flipping case removed.

Not sure what you mean exactly, but I hope we can agree that the code is
easier to understand and reason about now. :)


> I'm still not sure why we aren't getting a stall with 3 butters in the
> swapinterval=0 flipping case, but if it doesn't have a perf impact, it must
> not be a problem.

Right, there is a stall, but it doesn't seem significant, at least on my
setup.


> Reviewed-by: Jason Ekstrand  >

Thanks!


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv/pipeline: Lower indirect outputs when EmitNoIndirectOutput is set

[Kenneth Graunke]

On Monday, September 5, 2016 8:10:48 PM PDT Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> Reported-by: Timothy Arceri 
> ---
>  src/intel/vulkan/anv_pipeline.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
> index 35acc4a..9780201 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -186,6 +186,8 @@ anv_shader_compile_to_nir(struct anv_device *device,
> nir_variable_mode indirect_mask = 0;
> if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
>indirect_mask |= nir_var_shader_in;
> +   if (compiler->glsl_compiler_options[stage].EmitNoIndirectOutput)
> +  indirect_mask |= nir_var_shader_out;
> if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
>indirect_mask |= nir_var_local;
>  
> 

Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Jason Ekstrand]

On Sep 5, 2016 8:43 PM, "Michel Dänzer"  wrote:
>
> On 06/09/16 12:08 PM, Jason Ekstrand wrote:
> > On Mon, Sep 5, 2016 at 7:39 PM, Michel Dänzer  > > wrote:
> >
> > From: Michel Dänzer  > >
> >
> > This can make a significant difference for performance with some
extreme
> > test cases such as vblank_mode=0 glxgears.
> >
> > Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
> > Cc: "12.0 11.2"  > >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
> > 
> > Signed-off-by: Michel Dänzer  > >
> > ---
> >
> > I could swear I tested vblank_mode=0 glxgears with my previous
change
> > and couldn't measure any difference, but I can now, so I must have
> > messed up my previous testing somehow... Apologies for any
inconvenience
> > this caused.
> >
> >  src/loader/loader_dri3_helper.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c
> > b/src/loader/loader_dri3_helper.c
> > index 86ae5ae..3ce0352 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable
> > *draw)
> >  {
> > if (draw->flipping)
> >draw->num_back = 3;
> > -   else if (draw->vtable->get_swap_interval(draw) != 0)
> > -  draw->num_back = 2;
> > else
> > -  draw->num_back = 1;
> > +  draw->num_back = 2;
> >
> >
> > With this change, the function is logically identical to the old
> > function with the async flipping case removed.
>
> Not sure what you mean exactly, but I hope we can agree that the code is
> easier to understand and reason about now. :)

I mean that you original patch made two functional changes: One was to drop
quadbuffering and the second was to single-buffer in the swapinterval==0
case.  This effectively reverts the second functional change while leaving
the first intact.

Yes, it's much easier to read now.  One could argue that the "counting
buffers" approach of the original code had it's merits, but it is much
easier to look at the new code and see what it will do in any particular
case.

> > I'm still not sure why we aren't getting a stall with 3 butters in the
> > swapinterval=0 flipping case, but if it doesn't have a perf impact, it
must
> > not be a problem.
>
> Right, there is a stall, but it doesn't seem significant, at least on my
> setup.
>
>
> > Reviewed-by: Jason Ekstrand  > >
>
> Thanks!
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] intel/isl: Add a format_supports_multisampling helper

[Pohjolainen, Topi]

On Fri, Sep 02, 2016 at 03:50:42PM -0700, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.h|  2 ++
>  src/intel/isl/isl_format.c | 30 ++
>  src/intel/isl/isl_gen6.c   | 19 +--
>  src/intel/isl/isl_gen7.c   | 16 +---
>  src/intel/isl/isl_gen8.c   |  4 +---
>  5 files changed, 35 insertions(+), 36 deletions(-)
> 
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index ecedc05..cb7c22d 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -989,6 +989,8 @@ bool isl_format_supports_vertex_fetch(const struct 
> brw_device_info *devinfo,
>enum isl_format format);
>  bool isl_format_supports_lossless_compression(const struct brw_device_info 
> *devinfo,
>enum isl_format format);
> +bool isl_format_supports_multisampling(const struct brw_device_info *devinfo,
> +   enum isl_format format);
>  
>  bool isl_format_has_unorm_channel(enum isl_format fmt) ATTRIBUTE_CONST;
>  bool isl_format_has_snorm_channel(enum isl_format fmt) ATTRIBUTE_CONST;
> diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
> index 8507cc5..5d43fe7 100644
> --- a/src/intel/isl/isl_format.c
> +++ b/src/intel/isl/isl_format.c
> @@ -429,6 +429,36 @@ isl_format_supports_lossless_compression(const struct 
> brw_device_info *devinfo,
> return format_gen(devinfo) >= format_info[format].lossless_compression;
>  }
>  
> +bool
> +isl_format_supports_multisampling(const struct brw_device_info *devinfo,
> +  enum isl_format format)
> +{
> +   /* From the Sandybridge PRM, Volume 4 Part 1 p72, SURFACE_STATE, Surface
> +* Format:
> +*
> +*If Number of Multisamples is set to a value other than
> +*MULTISAMPLECOUNT_1, this field cannot be set to the following
> +*formats:
> +*
> +*   - any format with greater than 64 bits per element
> +*   - any compressed texture format (BC*)
> +*   - any YCRCB* format
> +*
> +* The restriction on the format's size is removed on Broadwell.  Also,
> +* there is an exception for HiZ which we treat as a compressed format and
> +* is allowed to be multisampled on Broadwell and earlier.
> +*/
> +   if (devinfo->gen < 8 && isl_format_get_layout(format)->bpb > 64) {
> +  return false;
> +   } else if (isl_format_is_compressed(format)) {
> +  return false;

I'm merely studying here a little while waiting for jenkins: HiZ case hits
this condition with ISL_TXC_HIZ. Where is the exception you mention in the
comment?

> +   } else if (isl_format_is_yuv(format)) {
> +  return false;
> +   } else {
> +  return true;
> +   }
> +}
> +
>  static inline bool
>  isl_format_has_channel_type(enum isl_format fmt, enum isl_base_type type)
>  {
> diff --git a/src/intel/isl/isl_gen6.c b/src/intel/isl/isl_gen6.c
> index 2c52e38..b30998d 100644
> --- a/src/intel/isl/isl_gen6.c
> +++ b/src/intel/isl/isl_gen6.c
> @@ -30,8 +30,6 @@ gen6_choose_msaa_layout(const struct isl_device *dev,
>enum isl_tiling tiling,
>enum isl_msaa_layout *msaa_layout)
>  {
> -   const struct isl_format_layout *fmtl = 
> isl_format_get_layout(info->format);
> -
> assert(ISL_DEV_GEN(dev) == 6);
> assert(info->samples >= 1);
>  
> @@ -40,22 +38,7 @@ gen6_choose_msaa_layout(const struct isl_device *dev,
>return false;
> }
>  
> -   /* From the Sandybridge PRM, Volume 4 Part 1 p72, SURFACE_STATE, Surface
> -* Format:
> -*
> -*If Number of Multisamples is set to a value other than
> -*MULTISAMPLECOUNT_1, this field cannot be set to the following
> -*formats:
> -*
> -*   - any format with greater than 64 bits per element
> -*   - any compressed texture format (BC*)
> -*   - any YCRCB* format
> -*/
> -   if (fmtl->bpb > 64)
> -  return false;
> -   if (isl_format_is_compressed(info->format))
> -  return false;
> -   if (isl_format_is_yuv(info->format))
> +   if (!isl_format_supports_multisampling(dev->info, info->format))
>return false;
>  
> /* From the Sandybridge PRM, Volume 4 Part 1 p85, SURFACE_STATE, Number of
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index 02273f8..7b40291 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/src/intel/isl/isl_gen7.c
> @@ -30,8 +30,6 @@ gen7_choose_msaa_layout(const struct isl_device *dev,
>  enum isl_tiling tiling,
>  enum isl_msaa_layout *msaa_layout)
>  {
> -   const struct isl_format_layout *fmtl = 
> isl_format_get_layout(info->format);
> -
> bool require_array = false;
> bool require_interleaved = false;
>  
> @@ -43,19 +41,7 @@ gen7_choose_msaa_layout(const struct isl_device *dev,
>return true;
> }
>  
> -   /* From the Ivybridge PRM, Volume 4 Part 1 p63, SU

Re: [Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Michel Dänzer]

On 06/09/16 01:59 PM, Jason Ekstrand wrote:
> On Sep 5, 2016 8:43 PM, "Michel Dänzer"  > wrote:
>>
>> On 06/09/16 12:08 PM, Jason Ekstrand wrote:
>> > On Mon, Sep 5, 2016 at 7:39 PM, Michel Dänzer  
>> > >> wrote:
>> >
>> > From: Michel Dänzer  
>> > >>
>> >
>> > This can make a significant difference for performance with some
> extreme
>> > test cases such as vblank_mode=0 glxgears.
>> >
>> > Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
>> > Cc: "12.0 11.2"  
>> >  >>
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
>> > 
>> > Signed-off-by: Michel Dänzer  
>> > >>
>> > ---
>> >
>> > I could swear I tested vblank_mode=0 glxgears with my previous
> change
>> > and couldn't measure any difference, but I can now, so I must have
>> > messed up my previous testing somehow... Apologies for any
> inconvenience
>> > this caused.
>> >
>> >  src/loader/loader_dri3_helper.c | 4 +---
>> >  1 file changed, 1 insertion(+), 3 deletions(-)
>> >
>> > diff --git a/src/loader/loader_dri3_helper.c
>> > b/src/loader/loader_dri3_helper.c
>> > index 86ae5ae..3ce0352 100644
>> > --- a/src/loader/loader_dri3_helper.c
>> > +++ b/src/loader/loader_dri3_helper.c
>> > @@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable
>> > *draw)
>> >  {
>> > if (draw->flipping)
>> >draw->num_back = 3;
>> > -   else if (draw->vtable->get_swap_interval(draw) != 0)
>> > -  draw->num_back = 2;
>> > else
>> > -  draw->num_back = 1;
>> > +  draw->num_back = 2;
>> >
>> >
>> > With this change, the function is logically identical to the old
>> > function with the async flipping case removed.
>>
>> Not sure what you mean exactly, but I hope we can agree that the code is
>> easier to understand and reason about now. :)
> 
> I mean that you original patch made two functional changes: One was to
> drop quadbuffering

As I explained, there was really no quad-buffering in the first place.


> and the second was to single-buffer in the swapinterval==0 case.
> This effectively reverts the second functional change while leaving
> the first intact.

That's not the only remaining change either. E.g. before my changes,
flipping with swap interval > 0 was using only two buffers, now it's
three. (That was actually the main motivation for my first change)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader/dri3: Always use at least two back buffers

[Michel Dänzer]

On 06/09/16 03:14 PM, Michel Dänzer wrote:
> On 06/09/16 01:59 PM, Jason Ekstrand wrote:
>> On Sep 5, 2016 8:43 PM, "Michel Dänzer" > > wrote:
>>>
>>> On 06/09/16 12:08 PM, Jason Ekstrand wrote:
 On Mon, Sep 5, 2016 at 7:39 PM, Michel Dänzer > 
 >> wrote:

 From: Michel Dänzer > 
 >>

 This can make a significant difference for performance with some
>> extreme
 test cases such as vblank_mode=0 glxgears.

 Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
 Cc: "12.0 11.2" > 
 > >>
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
 
 Signed-off-by: Michel Dänzer > 
 >>
 ---

 I could swear I tested vblank_mode=0 glxgears with my previous
>> change
 and couldn't measure any difference, but I can now, so I must have
 messed up my previous testing somehow... Apologies for any
>> inconvenience
 this caused.

  src/loader/loader_dri3_helper.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

 diff --git a/src/loader/loader_dri3_helper.c
 b/src/loader/loader_dri3_helper.c
 index 86ae5ae..3ce0352 100644
 --- a/src/loader/loader_dri3_helper.c
 +++ b/src/loader/loader_dri3_helper.c
 @@ -70,10 +70,8 @@ dri3_update_num_back(struct loader_dri3_drawable
 *draw)
  {
 if (draw->flipping)
draw->num_back = 3;
 -   else if (draw->vtable->get_swap_interval(draw) != 0)
 -  draw->num_back = 2;
 else
 -  draw->num_back = 1;
 +  draw->num_back = 2;


 With this change, the function is logically identical to the old
 function with the async flipping case removed.
>>>
>>> Not sure what you mean exactly, but I hope we can agree that the code is
>>> easier to understand and reason about now. :)
>>
>> I mean that you original patch made two functional changes: One was to
>> drop quadbuffering
> 
> As I explained, there was really no quad-buffering in the first place.
> 
> 
>> and the second was to single-buffer in the swapinterval==0 case.
>> This effectively reverts the second functional change while leaving
>> the first intact.
> 
> That's not the only remaining change either. E.g. before my changes,
> flipping with swap interval > 0 was using only two buffers, now it's
> three. (That was actually the main motivation for my first change)

To be precise, this change only applies when the X driver supports async
flips, otherwise it was already using three buffers before. (Note that
async flips are never used with swap interval > 0)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev