Re: [Mesa-dev] [PATCH v3 3/3] intel/i965: Enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 18.10.2018, 13:22 -0700 schrieb Ian Romanick:
> On 10/18/2018 09:39 AM, Gert Wollny wrote:
> > From: Gert Wollny 
> > 
> > Enables and passes on i965:
> >   dEQP-
> > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> > 
> > Signed-off-by: Gert Wollny 
> > ---
> >  src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> > b/src/mesa/drivers/dri/i965/intel_extensions.c
> > index d7e02efb54..ca921de8e8 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -76,6 +76,7 @@ intelInitExtensions(struct gl_context *ctx)
> > ctx->Extensions.ARB_shading_language_packing = true;
> > ctx->Extensions.ARB_shadow = true;
> > ctx->Extensions.ARB_sync = true;
> > +   ctx->Extensions.EXT_sRGB_write_control = true;
> 
> This should be down with the other EXT enables.  The sorting includes
> the XYZ tag.
Sorry, fixed locally. 

Best, 
Gert 

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

[Mesa-dev] [PATCH v2] meson: Add -Werror=return-type when supported.

[Kenneth Graunke]

This warning detects non-void functions with a missing return statement,
return statements with a value in void functions, and functions with an
bogus return type that ends up defaulting to int.  It's already enabled
by default with -Wall.  Generally, these are fairly serious bugs in the
code, which developers would like to notice and fix immediately.  This
patch promotes it from a warning to an error, to help developers catch
such mistakes early.

I would not expect this warning to change much based on the compiler
version, so hopefully it won't become a problem for packagers/builders.

See the GCC documentation or 'man gcc' for more details:
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Warning-Options.html#index-Wreturn-type
---
 meson.build | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 505cc6c79bd..0dfe09858bf 100644
--- a/meson.build
+++ b/meson.build
@@ -788,7 +788,8 @@ endif
 # Check for generic C arguments
 c_args = []
 foreach a : ['-Wall', '-Werror=implicit-function-declaration',
- '-Werror=missing-prototypes', '-fno-math-errno',
+ '-Werror=missing-prototypes', '-Werror=return-type',
+ '-fno-math-errno',
  '-fno-trapping-math', '-Qunused-arguments']
   if cc.has_argument(a)
 c_args += a
@@ -808,7 +809,8 @@ endif
 
 # Check for generic C++ arguments
 cpp_args = []
-foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
+foreach a : ['-Wall', '-Werror=return-type',
+ '-fno-math-errno', '-fno-trapping-math',
  '-Qunused-arguments']
   if cpp.has_argument(a)
 cpp_args += a
-- 
2.19.0

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

Re: [Mesa-dev] [PATCH 2/4] radeonsi: use compute shaders for clear_buffer & copy_buffer

[Marek Olšák]

It looks like there is a deadlock in LLVM when 2 shaders are compiled at
the same time. I don't know why it doesn't happen with OpenGL.

Marek

On Thu, Oct 18, 2018 at 3:32 AM Michel Dänzer  wrote:

> On 2018-10-17 6:43 p.m., Marek Olšák wrote:
> > Can you test the attached patch?
>
> Doesn't help, unfortunately. Backtraces with the patch attached.
>
> FWIW, this is on Bonaire.
>
>
> --
> 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] nir: remove some redundant bcsel instructions

[Ian Romanick]

On 10/16/2018 08:49 PM, Timothy Arceri wrote:
> For example:
> 
>vec1 32 ssa_386 = feq ssa_333.x, ssa_6
>vec1 32 ssa_387 = feq ssa_333.x, ssa_2
>vec1 32 ssa_391 = bcsel ssa_387, ssa_388, ssa_324
>vec1 32 ssa_396 = bcsel ssa_386, ssa_324, ssa_391
> 
> Can be simplified to:
> 
>vec1 32 ssa_386 = feq ssa_333.x, ssa_6
>vec1 32 ssa_391 = bcsel ssa_387, ssa_388, ssa_324
> 
> There are a bunch of these in Rise of The Tomb Raiders Vulkan
> shaders. There are also a hadful of shaders helped in shader-db
> but the changes there are smaller.
> 
> For RADV:
> 
> Totals from affected shaders:
> SGPRS: 11184 -> 11168 (-0.14 %)
> VGPRS: 11484 -> 11484 (0.00 %)
> Spilled SGPRs: 1119 -> 1116 (-0.27 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 1210856 -> 1210372 (-0.04 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 360 -> 360 (0.00 %)
> Wait states: 0 -> 0 (0.00 %)
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
> b/src/compiler/nir/nir_opt_algebraic.py
> index cc747250ba5..7530710cbe0 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -34,6 +34,7 @@ a = 'a'
>  b = 'b'
>  c = 'c'
>  d = 'd'
> +e = 'e'
>  
>  # Written in the form (, ) where  is an expression
>  # and  is either an expression or a value.  An expression is
> @@ -525,6 +526,9 @@ optimizations = [
> # The result of this should be hit by constant propagation and, in the
> # next round of opt_algebraic, get picked up by one of the above two.
> (('bcsel', '#a', b, c), ('bcsel', ('ine', 'a', 0), b, c)),
> +   # Remove redundant bcsel
> +   (('bcsel', ('ieq', '#a', b), c, ('bcsel', ('ieq', '#d', b), e, c)), 
> ('bcsel', ('ieq', d, b), e, c)),
> +   (('bcsel', ('feq', '#a', b), c, ('bcsel', ('feq', '#d', b), e, c)), 
> ('bcsel', ('feq', d, b), e, c)),

There are a bunch of similar bcsel-of-bcsel patterns around line 296.  I
think these should go up there.

As for enforcing the a != d restriction, I've been thinking of adding
some extra functions that could be invoked from the 'options->foo' field
to enforce things like this.

It seems like in one of the patches that recognized open-coded flrp I
wanted to detect cases where #a == -2.0 * #b.  Instead I had to just
hard code 2.0 and -1.0 since those were the most common cases.  I think
I was converting (ffma 2.0, a, -1.0) to (flrp -1.0, 1.0, a).  I can't
seem to find that patch. :(  I think I also had a patch where I wanted
to restrict #a == -#b.

>  
> (('bcsel', a, b, b), b),
> (('fcsel', a, b, b), b),
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

[Jose Fonseca]

I still can't make much sense of that github issue thread.

Applications on Windows use opengl32.dll for acceleration, not 
libEGL/libGLESv1/libGLESv2 as these are not provided by the OS.  The 
only place you see these DLLs are things like GLES -> D3D11/GL 
translators like Angle.


So the "missing glapi.dll" is a red herring IMO: the solution is not to 
somehow the build the glapi.dll but rather build mesa so it's never 
needed.  Which is what scons does by default.


What Meson does or not by default I don't know.  It might provide all 
those DLLs, but that doesn't change the fact that windows applications 
will target opengl32.dll for accelleration.



Jose

On 18/10/18 15:46, Liviu Prodea wrote:
Well, all this started in that Github issue thread. That guy @elkhalafy 
was using llvmpipe to get Blender 2.80 to work on his system with 
unsupported (too old) iGPU. I don't know what he did but it resulted in 
Blender failing with missing libglapi.dll. So I researched about how to 
build it and it led me to this build variable gles of type boolean. When 
set to true it builds glapi as a shared library named libglapi.dll. It 
is also a requirement to build libGLESv1_CM.dll and libGLESv2.dll which 
only get build when selecting all build targets or probably I wasn't 
able to find the right target(s).


A Meson build approximation is -Dgles1=true -Dgles2=true which builds 
all 3 DLLs and it is default unlike in Scons case,


On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca 
 wrote:



I don't know what gles=y entails anymore, but if it's broken we should
simply remove it.

That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile
extension, even without gles=y option.

So what exactly are you looking for here?

Jose

On 18/10/18 13:02, Liviu Prodea wrote:
 > scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
 >
 > Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and
 > object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
 > osmesa.obj : error LNK2001: unresolved external symbol
 > __imp___glapi_check_multithread
 > osmesa.obj : error LNK2001: unresolved external symbol
 > __imp___glapi_get_proc_address
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_dispatch
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_nop_handler
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_new_nop_table
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_Context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch_table_size
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_context
 > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_add_dispatch
 > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch
 > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_Dispatch
 > build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120:
 > 12 unresolved externals
 > scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
 > st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_proc_address
 > mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_check_multithread
 > mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_dispatch
 > mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_set_context
 > mesa.lib(context.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_get_dispatch_table_size
 > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol
 > __imp___glapi_add_dispatch
 > build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error
 > LNK1120: 6 unresolved externals
 > scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] 
Error 1120

 > scons: building terminated because of errors.
 >
 > This is a long standing issue. First reported here:
 >
 > 
https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html 

 > 

Re: [Mesa-dev] [PATCH mesa] radv: s/abs/fabsf/ for floats

[Matt Turner]

On Thu, Oct 18, 2018 at 1:28 PM Roland Scheidegger  wrote:
>
> Am 18.10.18 um 19:25 schrieb Matt Turner:
> > On Thu, Oct 18, 2018 at 8:46 AM Eric Engestrom  
> > wrote:
> >>
> >> Fixes: a4c4efad89eceb26cf82 "radv: Rework guard band calculation"
> >> Cc: Bas Nieuwenhuizen 
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >>  src/amd/vulkan/si_cmd_buffer.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/amd/vulkan/si_cmd_buffer.c 
> >> b/src/amd/vulkan/si_cmd_buffer.c
> >> index de057657ee70d354e910..52daf99414790d4764b6 100644
> >> --- a/src/amd/vulkan/si_cmd_buffer.c
> >> +++ b/src/amd/vulkan/si_cmd_buffer.c
> >> @@ -516,16 +516,16 @@ si_write_scissors(struct radeon_cmdbuf *cs, int 
> >> first,
> >> VkRect2D scissor = si_intersect_scissor([i], 
> >> _scissor);
> >>
> >> get_viewport_xform(viewports + i, scale, translate);
> >> -   scale[0] = abs(scale[0]);
> >> -   scale[1] = abs(scale[1]);
> >> +   scale[0] = fabsf(scale[0]);
> >> +   scale[1] = fabsf(scale[1]);
> >>
> >> if (scale[0] < 0.5)
> >
> > You might want to suffix these immediates with f at the same time. As
> > is, this will convert scale[0] to a double before the compairson
> > against 0.5. I'm assuming that scale[0] is a float, which I've
> > inferred from the patch but haven't confirmed.
>
> Not that I don't think doing this isn't good idea, but I think compilers
> are clever enough to figure this out and omit the conversion? At least
> if you don't compile with -O0...

Not in my experience. See commit
23bba717e1178d54927c4968a0466d706a630432 and the preceding patches.

I'm not aware of a reason why the compiler would be required to do the
double conversion, but it seems it does today.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] i965/nir: use vectorization for non-scalar stages

[Jason Ekstrand]

On Thu, Oct 18, 2018 at 3:46 PM Ian Romanick  wrote:

> On 10/18/2018 01:22 PM, Jason Ekstrand wrote:
> > On Thu, Oct 18, 2018 at 3:11 PM Ian Romanick  > > wrote:
> >
> > On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> > > From: Connor Abbott  cwabbo...@gmail.com>>
> > >
> > > Shader-db results on Haswell:
> > >
> > > total instructions in shared programs: 2180337 -> 2154080
> (-1.20%)
> > > instructions in affected programs: 959766 -> 933509 (-2.74%)
> > > helped: 5653
> > > HURT: 2560
> > >
> > > total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> > > cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> > > helped: 3838
> > > HURT: 4868
> >
> > Here's the results I got with these 3 patches on 322a919a41f:
> >
> > total instructions in shared programs: 13674046 -> 13643001 (-0.23%)
> > instructions in affected programs: 1248672 -> 1217627 (-2.49%)
> > helped: 7168
> > HURT: 2841
> > helped stats (abs) min: 1 max: 39 x̄: 5.40 x̃: 3
> > helped stats (rel) min: 0.21% max: 33.33% x̄: 4.55% x̃: 3.54%
> > HURT stats (abs)   min: 1 max: 21 x̄: 2.71 x̃: 3
> > HURT stats (rel)   min: 0.19% max: 22.73% x̄: 3.86% x̃: 3.53%
> > 95% mean confidence interval for instructions value: -3.23 -2.97
> > 95% mean confidence interval for instructions %-change: -2.28% -2.05%
> > Instructions are helped.
> >
> > total cycles in shared programs: 373694400 -> 373745788 (0.01%)
> > cycles in affected programs: 23171532 -> 23222920 (0.22%)
> > helped: 4890
> > HURT: 5632
> > helped stats (abs) min: 2 max: 1268 x̄: 52.04 x̃: 34
> > helped stats (rel) min: 0.04% max: 45.71% x̄: 7.43% x̃: 4.64%
> > HURT stats (abs)   min: 2 max: 6042 x̄: 54.30 x̃: 32
> > HURT stats (rel)   min: 0.05% max: 60.66% x̄: 8.19% x̃: 6.21%
> > 95% mean confidence interval for cycles value: 1.30 8.47
> > 95% mean confidence interval for cycles %-change: 0.73% 1.14%
> > Cycles are HURT.
> >
> > total spills in shared programs: 82569 -> 82572 (<.01%)
> > spills in affected programs: 70 -> 73 (4.29%)
> > helped: 0
> > HURT: 3
> >
> > total fills in shared programs: 93445 -> 93449 (<.01%)
> > fills in affected programs: 71 -> 75 (5.63%)
> > helped: 0
> > HURT: 4
> >
> > This is pretty different from your result... and not good. :(  What
> SHA
> > of master were you on?
> >
> >
> > For one thing, I scrubbed all the non-vec4 programs from the results
> > because this doesn't affect FS.  I'm not sure what master; something
> > from the last two days; I just rebased.  Maybe you have a newer
> shader-db?
>
> I doubt my shader-db is newer.  The last time I updated was when you
> added a bunch of shaders. :)  Scrubbing FS programs should only affect
> the values shown in "total XXX in shader programs", right?  Or did you
> do something other than
>
./report.py <(grep -v SIMD before.txt) <(grep -v SIMD after.txt)
>
> When I do that, I get 'total ...' numbers a bit closer to, but still
> larger than, yours.
>
> Looking at the actual data, the shaders most hurt for cycles are all
> shaders that have been in shader-db for years... lots of Unigine and
> L4D2. :(  The spills / fills hurt are all TES in Tomb Raider.
>

One other thing is that my Haswell numbers were taking by using ./run -p
hsw on a KBL.  It's possible you have more/less features enabled or
something.

--Jason


> > > Most of the hurt programs seem to be because we generate extra
> > MOV's due
> > > to vectorizing things. For example, in
> > > shaders/non-free/steam/anomaly-2/158.shader_test, this:
> > >
> > > add(8)  g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF
> > { align16 NoDDClr 1Q };
> > > add(8)  g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF
> > { align16 NoDDClr 1Q };
> > > add(8)  g116<1>.zwF g12<4,4,1>.xxxyF
> > -g1.4<0,4,1>.xxxyF { align16 NoDDChk 1Q };
> > > add(8)  g117<1>.zwF g12<4,4,1>.xxxyF
> > -g1.4<0,4,1>.zzzwF { align16 NoDDChk 1Q };
> > >
> > > Turns into this:
> > >
> > > add(8)  g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F   {
> > align16 1Q };
> > > add(8)  g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F  {
> > align16 1Q };
> > > mov(8)  g116<1>.xyD g13<4,4,1>.xyyyD{
> > align16 NoDDClr 1Q };
> > > mov(8)  g117<1>.xyD g13<4,4,1>.zwwwD{
> > align16 NoDDClr 1Q };
> > > mov(8)  g116<1>.zwD g14<4,4,1>.xxxyD{
> > align16 NoDDChk 1Q };
> > > mov(8)  g117<1>.zwD g14<4,4,1>.zzzwD{
> > align16 NoDDChk 1Q };
> > >
> > > So we eliminated two add's, but then had to introduce four mov's to
> > > transpose the result.  Some of the hurt is 

Re: [Mesa-dev] [PATCH 3/3] i965/nir: use vectorization for non-scalar stages

[Ian Romanick]

On 10/18/2018 01:22 PM, Jason Ekstrand wrote:
> On Thu, Oct 18, 2018 at 3:11 PM Ian Romanick  > wrote:
> 
> On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> > From: Connor Abbott mailto:cwabbo...@gmail.com>>
> >
> > Shader-db results on Haswell:
> >
> >     total instructions in shared programs: 2180337 -> 2154080 (-1.20%)
> >     instructions in affected programs: 959766 -> 933509 (-2.74%)
> >     helped: 5653
> >     HURT: 2560
> >
> >     total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> >     cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> >     helped: 3838
> >     HURT: 4868
> 
> Here's the results I got with these 3 patches on 322a919a41f:
> 
> total instructions in shared programs: 13674046 -> 13643001 (-0.23%)
> instructions in affected programs: 1248672 -> 1217627 (-2.49%)
> helped: 7168
> HURT: 2841
> helped stats (abs) min: 1 max: 39 x̄: 5.40 x̃: 3
> helped stats (rel) min: 0.21% max: 33.33% x̄: 4.55% x̃: 3.54%
> HURT stats (abs)   min: 1 max: 21 x̄: 2.71 x̃: 3
> HURT stats (rel)   min: 0.19% max: 22.73% x̄: 3.86% x̃: 3.53%
> 95% mean confidence interval for instructions value: -3.23 -2.97
> 95% mean confidence interval for instructions %-change: -2.28% -2.05%
> Instructions are helped.
> 
> total cycles in shared programs: 373694400 -> 373745788 (0.01%)
> cycles in affected programs: 23171532 -> 23222920 (0.22%)
> helped: 4890
> HURT: 5632
> helped stats (abs) min: 2 max: 1268 x̄: 52.04 x̃: 34
> helped stats (rel) min: 0.04% max: 45.71% x̄: 7.43% x̃: 4.64%
> HURT stats (abs)   min: 2 max: 6042 x̄: 54.30 x̃: 32
> HURT stats (rel)   min: 0.05% max: 60.66% x̄: 8.19% x̃: 6.21%
> 95% mean confidence interval for cycles value: 1.30 8.47
> 95% mean confidence interval for cycles %-change: 0.73% 1.14%
> Cycles are HURT.
> 
> total spills in shared programs: 82569 -> 82572 (<.01%)
> spills in affected programs: 70 -> 73 (4.29%)
> helped: 0
> HURT: 3
> 
> total fills in shared programs: 93445 -> 93449 (<.01%)
> fills in affected programs: 71 -> 75 (5.63%)
> helped: 0
> HURT: 4
> 
> This is pretty different from your result... and not good. :(  What SHA
> of master were you on?
> 
> 
> For one thing, I scrubbed all the non-vec4 programs from the results
> because this doesn't affect FS.  I'm not sure what master; something
> from the last two days; I just rebased.  Maybe you have a newer shader-db?

I doubt my shader-db is newer.  The last time I updated was when you
added a bunch of shaders. :)  Scrubbing FS programs should only affect
the values shown in "total XXX in shader programs", right?  Or did you
do something other than

./report.py <(grep -v SIMD before.txt) <(grep -v SIMD after.txt)

When I do that, I get 'total ...' numbers a bit closer to, but still
larger than, yours.

Looking at the actual data, the shaders most hurt for cycles are all
shaders that have been in shader-db for years... lots of Unigine and
L4D2. :(  The spills / fills hurt are all TES in Tomb Raider.

> > Most of the hurt programs seem to be because we generate extra
> MOV's due
> > to vectorizing things. For example, in
> > shaders/non-free/steam/anomaly-2/158.shader_test, this:
> >
> > add(8)          g116<1>.xyF     g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF
> { align16 NoDDClr 1Q };
> > add(8)          g117<1>.xyF     g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF
> { align16 NoDDClr 1Q };
> > add(8)          g116<1>.zwF     g12<4,4,1>.xxxyF
> -g1.4<0,4,1>.xxxyF { align16 NoDDChk 1Q };
> > add(8)          g117<1>.zwF     g12<4,4,1>.xxxyF
> -g1.4<0,4,1>.zzzwF { align16 NoDDChk 1Q };
> >
> > Turns into this:
> >
> > add(8)          g13<1>F         g12<4,4,1>.xyxyF g1.4<0,4,1>F   {
> align16 1Q };
> > add(8)          g14<1>F         g12<4,4,1>.xyxyF -g1.4<0,4,1>F  {
> align16 1Q };
> > mov(8)          g116<1>.xyD     g13<4,4,1>.xyyyD                {
> align16 NoDDClr 1Q };
> > mov(8)          g117<1>.xyD     g13<4,4,1>.zwwwD                {
> align16 NoDDClr 1Q };
> > mov(8)          g116<1>.zwD     g14<4,4,1>.xxxyD                {
> align16 NoDDChk 1Q };
> > mov(8)          g117<1>.zwD     g14<4,4,1>.zzzwD                {
> align16 NoDDChk 1Q };
> >
> > So we eliminated two add's, but then had to introduce four mov's to
> > transpose the result.  Some of the hurt is because vectorization
> is a bit
> > over-aggressive and we vectorize something when we should have left it
> > as a scalar and CSEd it.  Unfortunately, this is all really tricky
> to do
> > as it involves the interactions between many different components.
> > ---
> >  src/intel/compiler/brw_nir.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git 

Re: [Mesa-dev] [PATCH 2/3] anv: Stop generating weak references for instance entrypoints

[Jason Ekstrand]

On Thu, Oct 18, 2018 at 3:24 PM Jason Ekstrand  wrote:

> On Thu, Oct 18, 2018 at 3:17 PM Jan Vesely  wrote:
>
>> Hi,
>>
>> I think this patch breaks the build:
>> https://travis-ci.org/jvesely/mesa/jobs/443356781
>>
>
> Interesting.  It appears that it breaks when you have one of the WSI
> extensions disabled.  I'll take a look.
>

Yeah, in retrospect, it's pretty bogus. I've reverted the patch.  Thanks
for reporting!  It was nice while it lasted because it pointed out an
entrypoint we forgot to implement but it looks like it was a bad idea in
the long term.  Maybe one day, I can come up with something more clever but
not today.

--jason



> --Jason
>
>
>
>> Jan
>>
>> On Tue, 2018-10-16 at 08:18 -0500, Jason Ekstrand wrote:
>> > FYI, patch 1 is required for this patch to build.  It also means this
>> patch
>> > found a nice little bug.  I'll respond to patch 1 in more detail after
>> the
>> > SI call tomorrow.
>> >
>> > --Jason
>> >
>> >
>> > On October 16, 2018 06:49:35 Lionel Landwerlin
>> >  wrote:
>> >
>> > > Reviewed-by: Lionel Landwerlin 
>> > >
>> > > On 15/10/2018 04:47, Jason Ekstrand wrote:
>> > > > We don't need weak references to instance entrypoints because we
>> never
>> > > > have more than one of each so we don't need the NULL fall-back.
>> This
>> > > > also helps us avoid forgetting things because we now get link
>> errors for
>> > > > missing instance entrypoints.
>> > > > ---
>> > > >   src/intel/vulkan/anv_entrypoints_gen.py | 13 -
>> > > >   1 file changed, 13 deletions(-)
>> > > >
>> > > > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
>> > > > b/src/intel/vulkan/anv_entrypoints_gen.py
>> > > > index beb658b8660..25a532fd706 100644
>> > > > --- a/src/intel/vulkan/anv_entrypoints_gen.py
>> > > > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
>> > > > @@ -227,19 +227,6 @@ ${strmap(device_strmap, 'device')}
>> > > >* either pick the correct entry point.
>> > > >*/
>> > > >
>> > > > -% for e in instance_entrypoints:
>> > > > -  % if e.alias:
>> > > > -<% continue %>
>> > > > -  % endif
>> > > > -  % if e.guard is not None:
>> > > > -#ifdef ${e.guard}
>> > > > -  % endif
>> > > > -  ${e.return_type} ${e.prefixed_name('anv')}(${e.decl_params()})
>> > > > __attribute__ ((weak));
>> > > > -  % if e.guard is not None:
>> > > > -#endif // ${e.guard}
>> > > > -  % endif
>> > > > -% endfor
>> > > > -
>> > > >   const struct anv_instance_dispatch_table
>> anv_instance_dispatch_table = {
>> > > >   % for e in instance_entrypoints:
>> > > > % if e.guard is not None:
>> > >
>> > >
>> > > ___
>> > > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] radv: s/abs/fabsf/ for floats

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Oct 18, 2018 at 5:46 PM Eric Engestrom  wrote:
>
> Fixes: a4c4efad89eceb26cf82 "radv: Rework guard band calculation"
> Cc: Bas Nieuwenhuizen 
> Signed-off-by: Eric Engestrom 
> ---
>  src/amd/vulkan/si_cmd_buffer.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
> index de057657ee70d354e910..52daf99414790d4764b6 100644
> --- a/src/amd/vulkan/si_cmd_buffer.c
> +++ b/src/amd/vulkan/si_cmd_buffer.c
> @@ -516,16 +516,16 @@ si_write_scissors(struct radeon_cmdbuf *cs, int first,
> VkRect2D scissor = si_intersect_scissor([i], 
> _scissor);
>
> get_viewport_xform(viewports + i, scale, translate);
> -   scale[0] = abs(scale[0]);
> -   scale[1] = abs(scale[1]);
> +   scale[0] = fabsf(scale[0]);
> +   scale[1] = fabsf(scale[1]);
>
> if (scale[0] < 0.5)
> scale[0] = 0.5;
> if (scale[1] < 0.5)
> scale[1] = 0.5;
>
> -   guardband_x = MIN2(guardband_x, (max_range - 
> abs(translate[0])) / scale[0]);
> -   guardband_y = MIN2(guardband_y, (max_range - 
> abs(translate[1])) / scale[1]);
> +   guardband_x = MIN2(guardband_x, (max_range - 
> fabsf(translate[0])) / scale[0]);
> +   guardband_y = MIN2(guardband_y, (max_range - 
> fabsf(translate[1])) / scale[1]);
>
> radeon_emit(cs, S_028250_TL_X(scissor.offset.x) |
> S_028250_TL_Y(scissor.offset.y) |
> --
> Cheers,
>   Eric
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] radv: s/abs/fabsf/ for floats

[Roland Scheidegger]

Am 18.10.18 um 19:25 schrieb Matt Turner:
> On Thu, Oct 18, 2018 at 8:46 AM Eric Engestrom  
> wrote:
>>
>> Fixes: a4c4efad89eceb26cf82 "radv: Rework guard band calculation"
>> Cc: Bas Nieuwenhuizen 
>> Signed-off-by: Eric Engestrom 
>> ---
>>  src/amd/vulkan/si_cmd_buffer.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
>> index de057657ee70d354e910..52daf99414790d4764b6 100644
>> --- a/src/amd/vulkan/si_cmd_buffer.c
>> +++ b/src/amd/vulkan/si_cmd_buffer.c
>> @@ -516,16 +516,16 @@ si_write_scissors(struct radeon_cmdbuf *cs, int first,
>> VkRect2D scissor = si_intersect_scissor([i], 
>> _scissor);
>>
>> get_viewport_xform(viewports + i, scale, translate);
>> -   scale[0] = abs(scale[0]);
>> -   scale[1] = abs(scale[1]);
>> +   scale[0] = fabsf(scale[0]);
>> +   scale[1] = fabsf(scale[1]);
>>
>> if (scale[0] < 0.5)
> 
> You might want to suffix these immediates with f at the same time. As
> is, this will convert scale[0] to a double before the compairson
> against 0.5. I'm assuming that scale[0] is a float, which I've
> inferred from the patch but haven't confirmed.

Not that I don't think doing this isn't good idea, but I think compilers
are clever enough to figure this out and omit the conversion? At least
if you don't compile with -O0...

Roland

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

Re: [Mesa-dev] [PATCH 2/3] anv: Stop generating weak references for instance entrypoints

[Jason Ekstrand]

On Thu, Oct 18, 2018 at 3:17 PM Jan Vesely  wrote:

> Hi,
>
> I think this patch breaks the build:
> https://travis-ci.org/jvesely/mesa/jobs/443356781
>

Interesting.  It appears that it breaks when you have one of the WSI
extensions disabled.  I'll take a look.

--Jason



> Jan
>
> On Tue, 2018-10-16 at 08:18 -0500, Jason Ekstrand wrote:
> > FYI, patch 1 is required for this patch to build.  It also means this
> patch
> > found a nice little bug.  I'll respond to patch 1 in more detail after
> the
> > SI call tomorrow.
> >
> > --Jason
> >
> >
> > On October 16, 2018 06:49:35 Lionel Landwerlin
> >  wrote:
> >
> > > Reviewed-by: Lionel Landwerlin 
> > >
> > > On 15/10/2018 04:47, Jason Ekstrand wrote:
> > > > We don't need weak references to instance entrypoints because we
> never
> > > > have more than one of each so we don't need the NULL fall-back.  This
> > > > also helps us avoid forgetting things because we now get link errors
> for
> > > > missing instance entrypoints.
> > > > ---
> > > >   src/intel/vulkan/anv_entrypoints_gen.py | 13 -
> > > >   1 file changed, 13 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
> > > > b/src/intel/vulkan/anv_entrypoints_gen.py
> > > > index beb658b8660..25a532fd706 100644
> > > > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > > > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > > > @@ -227,19 +227,6 @@ ${strmap(device_strmap, 'device')}
> > > >* either pick the correct entry point.
> > > >*/
> > > >
> > > > -% for e in instance_entrypoints:
> > > > -  % if e.alias:
> > > > -<% continue %>
> > > > -  % endif
> > > > -  % if e.guard is not None:
> > > > -#ifdef ${e.guard}
> > > > -  % endif
> > > > -  ${e.return_type} ${e.prefixed_name('anv')}(${e.decl_params()})
> > > > __attribute__ ((weak));
> > > > -  % if e.guard is not None:
> > > > -#endif // ${e.guard}
> > > > -  % endif
> > > > -% endfor
> > > > -
> > > >   const struct anv_instance_dispatch_table
> anv_instance_dispatch_table = {
> > > >   % for e in instance_entrypoints:
> > > > % if e.guard is not None:
> > >
> > >
> > > ___
> > > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/3] intel/i965: Enable extension EXT_sRGB_write_control

[Ian Romanick]

On 10/18/2018 09:39 AM, Gert Wollny wrote:
> From: Gert Wollny 
> 
> Enables and passes on i965:
>   dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index d7e02efb54..ca921de8e8 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -76,6 +76,7 @@ intelInitExtensions(struct gl_context *ctx)
> ctx->Extensions.ARB_shading_language_packing = true;
> ctx->Extensions.ARB_shadow = true;
> ctx->Extensions.ARB_sync = true;
> +   ctx->Extensions.EXT_sRGB_write_control = true;

This should be down with the other EXT enables.  The sorting includes
the XYZ tag.

> ctx->Extensions.ARB_texture_border_clamp = true;
> ctx->Extensions.ARB_texture_compression_rgtc = true;
> ctx->Extensions.ARB_texture_cube_map = true;
> 

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

Re: [Mesa-dev] [PATCH 3/3] i965/nir: use vectorization for non-scalar stages

[Jason Ekstrand]

On Thu, Oct 18, 2018 at 3:11 PM Ian Romanick  wrote:

> On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> > From: Connor Abbott 
> >
> > Shader-db results on Haswell:
> >
> > total instructions in shared programs: 2180337 -> 2154080 (-1.20%)
> > instructions in affected programs: 959766 -> 933509 (-2.74%)
> > helped: 5653
> > HURT: 2560
> >
> > total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> > cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> > helped: 3838
> > HURT: 4868
>
> Here's the results I got with these 3 patches on 322a919a41f:
>
> total instructions in shared programs: 13674046 -> 13643001 (-0.23%)
> instructions in affected programs: 1248672 -> 1217627 (-2.49%)
> helped: 7168
> HURT: 2841
> helped stats (abs) min: 1 max: 39 x̄: 5.40 x̃: 3
> helped stats (rel) min: 0.21% max: 33.33% x̄: 4.55% x̃: 3.54%
> HURT stats (abs)   min: 1 max: 21 x̄: 2.71 x̃: 3
> HURT stats (rel)   min: 0.19% max: 22.73% x̄: 3.86% x̃: 3.53%
> 95% mean confidence interval for instructions value: -3.23 -2.97
> 95% mean confidence interval for instructions %-change: -2.28% -2.05%
> Instructions are helped.
>
> total cycles in shared programs: 373694400 -> 373745788 (0.01%)
> cycles in affected programs: 23171532 -> 23222920 (0.22%)
> helped: 4890
> HURT: 5632
> helped stats (abs) min: 2 max: 1268 x̄: 52.04 x̃: 34
> helped stats (rel) min: 0.04% max: 45.71% x̄: 7.43% x̃: 4.64%
> HURT stats (abs)   min: 2 max: 6042 x̄: 54.30 x̃: 32
> HURT stats (rel)   min: 0.05% max: 60.66% x̄: 8.19% x̃: 6.21%
> 95% mean confidence interval for cycles value: 1.30 8.47
> 95% mean confidence interval for cycles %-change: 0.73% 1.14%
> Cycles are HURT.
>
> total spills in shared programs: 82569 -> 82572 (<.01%)
> spills in affected programs: 70 -> 73 (4.29%)
> helped: 0
> HURT: 3
>
> total fills in shared programs: 93445 -> 93449 (<.01%)
> fills in affected programs: 71 -> 75 (5.63%)
> helped: 0
> HURT: 4
>
> This is pretty different from your result... and not good. :(  What SHA
> of master were you on?
>

For one thing, I scrubbed all the non-vec4 programs from the results
because this doesn't affect FS.  I'm not sure what master; something from
the last two days; I just rebased.  Maybe you have a newer shader-db?


> > Most of the hurt programs seem to be because we generate extra MOV's due
> > to vectorizing things. For example, in
> > shaders/non-free/steam/anomaly-2/158.shader_test, this:
> >
> > add(8)  g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF {
> align16 NoDDClr 1Q };
> > add(8)  g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF {
> align16 NoDDClr 1Q };
> > add(8)  g116<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.xxxyF {
> align16 NoDDChk 1Q };
> > add(8)  g117<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.zzzwF {
> align16 NoDDChk 1Q };
> >
> > Turns into this:
> >
> > add(8)  g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F   {
> align16 1Q };
> > add(8)  g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F  {
> align16 1Q };
> > mov(8)  g116<1>.xyD g13<4,4,1>.xyyyD{
> align16 NoDDClr 1Q };
> > mov(8)  g117<1>.xyD g13<4,4,1>.zwwwD{
> align16 NoDDClr 1Q };
> > mov(8)  g116<1>.zwD g14<4,4,1>.xxxyD{
> align16 NoDDChk 1Q };
> > mov(8)  g117<1>.zwD g14<4,4,1>.zzzwD{
> align16 NoDDChk 1Q };
> >
> > So we eliminated two add's, but then had to introduce four mov's to
> > transpose the result.  Some of the hurt is because vectorization is a bit
> > over-aggressive and we vectorize something when we should have left it
> > as a scalar and CSEd it.  Unfortunately, this is all really tricky to do
> > as it involves the interactions between many different components.
> > ---
> >  src/intel/compiler/brw_nir.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> > index 297845b89b7..564fd004a94 100644
> > --- a/src/intel/compiler/brw_nir.c
> > +++ b/src/intel/compiler/brw_nir.c
> > @@ -568,6 +568,12 @@ brw_nir_optimize(nir_shader *nir, const struct
> brw_compiler *compiler,
> >OPT(nir_copy_prop);
> >OPT(nir_opt_dce);
> >OPT(nir_opt_cse);
> > +
> > +  if (!is_scalar) {
> > + OPT(nir_opt_vectorize);
> > + OPT(nir_copy_prop);
> > +  }
> > +
> >OPT(nir_opt_peephole_select, 0);
> >OPT(nir_opt_intrinsics);
> >OPT(nir_opt_algebraic);
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] anv: Stop generating weak references for instance entrypoints

[Jan Vesely]

Hi,

I think this patch breaks the build:
https://travis-ci.org/jvesely/mesa/jobs/443356781

Jan

On Tue, 2018-10-16 at 08:18 -0500, Jason Ekstrand wrote:
> FYI, patch 1 is required for this patch to build.  It also means this patch 
> found a nice little bug.  I'll respond to patch 1 in more detail after the 
> SI call tomorrow.
> 
> --Jason
> 
> 
> On October 16, 2018 06:49:35 Lionel Landwerlin 
>  wrote:
> 
> > Reviewed-by: Lionel Landwerlin 
> > 
> > On 15/10/2018 04:47, Jason Ekstrand wrote:
> > > We don't need weak references to instance entrypoints because we never
> > > have more than one of each so we don't need the NULL fall-back.  This
> > > also helps us avoid forgetting things because we now get link errors for
> > > missing instance entrypoints.
> > > ---
> > >   src/intel/vulkan/anv_entrypoints_gen.py | 13 -
> > >   1 file changed, 13 deletions(-)
> > > 
> > > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
> > > b/src/intel/vulkan/anv_entrypoints_gen.py
> > > index beb658b8660..25a532fd706 100644
> > > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > > @@ -227,19 +227,6 @@ ${strmap(device_strmap, 'device')}
> > >* either pick the correct entry point.
> > >*/
> > > 
> > > -% for e in instance_entrypoints:
> > > -  % if e.alias:
> > > -<% continue %>
> > > -  % endif
> > > -  % if e.guard is not None:
> > > -#ifdef ${e.guard}
> > > -  % endif
> > > -  ${e.return_type} ${e.prefixed_name('anv')}(${e.decl_params()}) 
> > > __attribute__ ((weak));
> > > -  % if e.guard is not None:
> > > -#endif // ${e.guard}
> > > -  % endif
> > > -% endfor
> > > -
> > >   const struct anv_instance_dispatch_table anv_instance_dispatch_table = {
> > >   % for e in instance_entrypoints:
> > > % if e.guard is not None:
> > 
> > 
> > ___
> > 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: 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 3/3] i965/nir: use vectorization for non-scalar stages

[Ian Romanick]

On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> From: Connor Abbott 
> 
> Shader-db results on Haswell:
> 
> total instructions in shared programs: 2180337 -> 2154080 (-1.20%)
> instructions in affected programs: 959766 -> 933509 (-2.74%)
> helped: 5653
> HURT: 2560
> 
> total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> helped: 3838
> HURT: 4868

Here's the results I got with these 3 patches on 322a919a41f:

total instructions in shared programs: 13674046 -> 13643001 (-0.23%)
instructions in affected programs: 1248672 -> 1217627 (-2.49%)
helped: 7168
HURT: 2841
helped stats (abs) min: 1 max: 39 x̄: 5.40 x̃: 3
helped stats (rel) min: 0.21% max: 33.33% x̄: 4.55% x̃: 3.54%
HURT stats (abs)   min: 1 max: 21 x̄: 2.71 x̃: 3
HURT stats (rel)   min: 0.19% max: 22.73% x̄: 3.86% x̃: 3.53%
95% mean confidence interval for instructions value: -3.23 -2.97
95% mean confidence interval for instructions %-change: -2.28% -2.05%
Instructions are helped.

total cycles in shared programs: 373694400 -> 373745788 (0.01%)
cycles in affected programs: 23171532 -> 23222920 (0.22%)
helped: 4890
HURT: 5632
helped stats (abs) min: 2 max: 1268 x̄: 52.04 x̃: 34
helped stats (rel) min: 0.04% max: 45.71% x̄: 7.43% x̃: 4.64%
HURT stats (abs)   min: 2 max: 6042 x̄: 54.30 x̃: 32
HURT stats (rel)   min: 0.05% max: 60.66% x̄: 8.19% x̃: 6.21%
95% mean confidence interval for cycles value: 1.30 8.47
95% mean confidence interval for cycles %-change: 0.73% 1.14%
Cycles are HURT.

total spills in shared programs: 82569 -> 82572 (<.01%)
spills in affected programs: 70 -> 73 (4.29%)
helped: 0
HURT: 3

total fills in shared programs: 93445 -> 93449 (<.01%)
fills in affected programs: 71 -> 75 (5.63%)
helped: 0
HURT: 4

This is pretty different from your result... and not good. :(  What SHA
of master were you on?

> Most of the hurt programs seem to be because we generate extra MOV's due
> to vectorizing things. For example, in
> shaders/non-free/steam/anomaly-2/158.shader_test, this:
> 
> add(8)  g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF { align16 
> NoDDClr 1Q };
> add(8)  g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF { align16 
> NoDDClr 1Q };
> add(8)  g116<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.xxxyF { align16 
> NoDDChk 1Q };
> add(8)  g117<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.zzzwF { align16 
> NoDDChk 1Q };
> 
> Turns into this:
> 
> add(8)  g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F   { align16 1Q 
> };
> add(8)  g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F  { align16 1Q 
> };
> mov(8)  g116<1>.xyD g13<4,4,1>.xyyyD{ align16 
> NoDDClr 1Q };
> mov(8)  g117<1>.xyD g13<4,4,1>.zwwwD{ align16 
> NoDDClr 1Q };
> mov(8)  g116<1>.zwD g14<4,4,1>.xxxyD{ align16 
> NoDDChk 1Q };
> mov(8)  g117<1>.zwD g14<4,4,1>.zzzwD{ align16 
> NoDDChk 1Q };
> 
> So we eliminated two add's, but then had to introduce four mov's to
> transpose the result.  Some of the hurt is because vectorization is a bit
> over-aggressive and we vectorize something when we should have left it
> as a scalar and CSEd it.  Unfortunately, this is all really tricky to do
> as it involves the interactions between many different components.
> ---
>  src/intel/compiler/brw_nir.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 297845b89b7..564fd004a94 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -568,6 +568,12 @@ brw_nir_optimize(nir_shader *nir, const struct 
> brw_compiler *compiler,
>OPT(nir_copy_prop);
>OPT(nir_opt_dce);
>OPT(nir_opt_cse);
> +
> +  if (!is_scalar) {
> + OPT(nir_opt_vectorize);
> + OPT(nir_copy_prop);
> +  }
> +
>OPT(nir_opt_peephole_select, 0);
>OPT(nir_opt_intrinsics);
>OPT(nir_opt_algebraic);
> 

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

Re: [Mesa-dev] [PATCH] radeonsi: fix a radeon kernel clear state error

[Marek Olšák]

Hi Sonny,

Can you send a version that only does >= CIK && drm_major == 3? It's
equivalent to your version but simpler.

Marek

On Thu, Oct 18, 2018 at 12:40 PM Jiang, Sonny  wrote:

> Signed-off-by: Sonny Jiang 
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c  | 7 +--
>  src/gallium/drivers/radeonsi/si_state.c | 5 +++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 9d25748df4..3da44483d6 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -991,8 +991,11 @@ struct pipe_screen *radeonsi_screen_create(struct
> radeon_winsys *ws,
> }
>
> /* The mere presense of CLEAR_STATE in the IB causes random GPU
> hangs
> -* on SI. */
> -   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
> +* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
> +* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu
> kernel.*/
> +   sscreen->has_clear_state = sscreen->info.chip_class > CIK ||
> +  (sscreen->info.chip_class == CIK &&
> +  sscreen->info.drm_major == 3);
>
> sscreen->has_distributed_tess =
> sscreen->info.chip_class >= VI &&
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index 8b2e6e57f4..ba84a5a42a 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
> bool has_clear_state = sscreen->has_clear_state;
> struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
>
> -   /* Only SI can disable CLEAR_STATE for now. */
> -   assert(has_clear_state || sscreen->info.chip_class == SI);
> +   /* SI, radeon kernel CIK disabled CLEAR_STATE. */
> +   assert(has_clear_state || sscreen->info.chip_class == SI ||
> +   (sscreen->info.chip_class == CIK &&
> sscreen->info.drm_major != 3));
>
> if (!pm4)
> return;
> --
> 2.17.1
>
> ___
> 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] [PATCH 3/3] i965/nir: use vectorization for non-scalar stages

[Jason Ekstrand]

On Thu, Oct 18, 2018 at 2:49 PM Ian Romanick  wrote:

> On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> > From: Connor Abbott 
> >
> > Shader-db results on Haswell:
> >
> > total instructions in shared programs: 2180337 -> 2154080 (-1.20%)
> > instructions in affected programs: 959766 -> 933509 (-2.74%)
> > helped: 5653
> > HURT: 2560
> >
> > total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> > cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> > helped: 3838
> > HURT: 4868
>
> In cases like this, the extra statistics generated by my extra changes
> to report.py can be informative.  Give me a few minutes, and I'll gather
> that data.
>
> > Most of the hurt programs seem to be because we generate extra MOV's due
> > to vectorizing things. For example, in
> > shaders/non-free/steam/anomaly-2/158.shader_test, this:
> >
> > add(8)  g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF {
> align16 NoDDClr 1Q };
> > add(8)  g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF {
> align16 NoDDClr 1Q };
> > add(8)  g116<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.xxxyF {
> align16 NoDDChk 1Q };
> > add(8)  g117<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.zzzwF {
> align16 NoDDChk 1Q };
> >
> > Turns into this:
> >
> > add(8)  g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F   {
> align16 1Q };
> > add(8)  g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F  {
> align16 1Q };
> > mov(8)  g116<1>.xyD g13<4,4,1>.xyyyD{
> align16 NoDDClr 1Q };
> > mov(8)  g117<1>.xyD g13<4,4,1>.zwwwD{
> align16 NoDDClr 1Q };
> > mov(8)  g116<1>.zwD g14<4,4,1>.xxxyD{
> align16 NoDDChk 1Q };
> > mov(8)  g117<1>.zwD g14<4,4,1>.zzzwD{
> align16 NoDDChk 1Q };
> >
> > So we eliminated two add's, but then had to introduce four mov's to
> > transpose the result.  Some of the hurt is because vectorization is a bit
> > over-aggressive and we vectorize something when we should have left it
> > as a scalar and CSEd it.  Unfortunately, this is all really tricky to do
> > as it involves the interactions between many different components.
>
> This seems to me like vectorization should be done later in the
> optimization pipeline.  I would have guessed that it would go after the
> regular optimization loop.  Did you try calling it from other places to
> see the effects?
>

No, I've done very little work on this.  I mostly rebased Connor's patches,
got them working again, and sent them to the list.  Someone was asking
about it on IRC in the context of old Mali hardware, I think.  I was
surprised to find we'd never actually landed it so I decided to freshen it
up a bit so that others could at least experiment with it again.  Turns out
that a lot has changed in NIR in the last three years...

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

Re: [Mesa-dev] [PATCH 3/3] i965/nir: use vectorization for non-scalar stages

[Ian Romanick]

On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> From: Connor Abbott 
> 
> Shader-db results on Haswell:
> 
> total instructions in shared programs: 2180337 -> 2154080 (-1.20%)
> instructions in affected programs: 959766 -> 933509 (-2.74%)
> helped: 5653
> HURT: 2560
> 
> total cycles in shared programs: 12339326 -> 12307102 (-0.26%)
> cycles in affected programs: 6102794 -> 6070570 (-0.53%)
> helped: 3838
> HURT: 4868

In cases like this, the extra statistics generated by my extra changes
to report.py can be informative.  Give me a few minutes, and I'll gather
that data.

> Most of the hurt programs seem to be because we generate extra MOV's due
> to vectorizing things. For example, in
> shaders/non-free/steam/anomaly-2/158.shader_test, this:
> 
> add(8)  g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF { align16 
> NoDDClr 1Q };
> add(8)  g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF { align16 
> NoDDClr 1Q };
> add(8)  g116<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.xxxyF { align16 
> NoDDChk 1Q };
> add(8)  g117<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.zzzwF { align16 
> NoDDChk 1Q };
> 
> Turns into this:
> 
> add(8)  g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F   { align16 1Q 
> };
> add(8)  g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F  { align16 1Q 
> };
> mov(8)  g116<1>.xyD g13<4,4,1>.xyyyD{ align16 
> NoDDClr 1Q };
> mov(8)  g117<1>.xyD g13<4,4,1>.zwwwD{ align16 
> NoDDClr 1Q };
> mov(8)  g116<1>.zwD g14<4,4,1>.xxxyD{ align16 
> NoDDChk 1Q };
> mov(8)  g117<1>.zwD g14<4,4,1>.zzzwD{ align16 
> NoDDChk 1Q };
> 
> So we eliminated two add's, but then had to introduce four mov's to
> transpose the result.  Some of the hurt is because vectorization is a bit
> over-aggressive and we vectorize something when we should have left it
> as a scalar and CSEd it.  Unfortunately, this is all really tricky to do
> as it involves the interactions between many different components.

This seems to me like vectorization should be done later in the
optimization pipeline.  I would have guessed that it would go after the
regular optimization loop.  Did you try calling it from other places to
see the effects?

> ---
>  src/intel/compiler/brw_nir.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 297845b89b7..564fd004a94 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -568,6 +568,12 @@ brw_nir_optimize(nir_shader *nir, const struct 
> brw_compiler *compiler,
>OPT(nir_copy_prop);
>OPT(nir_opt_dce);
>OPT(nir_opt_cse);
> +
> +  if (!is_scalar) {
> + OPT(nir_opt_vectorize);
> + OPT(nir_copy_prop);
> +  }
> +
>OPT(nir_opt_peephole_select, 0);
>OPT(nir_opt_intrinsics);
>OPT(nir_opt_algebraic);
> 

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

Re: [Mesa-dev] [PATCH 1/3] intel/peephole_ffma: Fix swizzle propagation

[Ian Romanick]

I was looking at this code just yesterday.  How fortuitous. :)  This
patch is

Reviewed-by: Ian Romanick 

On 10/17/2018 11:33 AM, Jason Ekstrand wrote:
> The num_components value passed into get_mul_for_src is used to only
> compose the parts of the swizzle that we know will be used so we don't
> compose invalid swizzle components.  However, we had a bug where we
> passed the number of components of the add all the way through.  For the
> given source, we need the number of components read from that source.
> In the case where we have a narrow add, say 2 components, that is
> sourced from a chain of wider instructions, we may not compose all the
> swizzles.  All we really need to do is pass through the right number of
> components at each level.
> 
> Fixes: 2231cf0ba3a "nir: Fix output swizzle in get_mul_for_src"
> ---
>  src/intel/compiler/brw_nir_opt_peephole_ffma.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_nir_opt_peephole_ffma.c 
> b/src/intel/compiler/brw_nir_opt_peephole_ffma.c
> index cc225e1847b..7271bdbca43 100644
> --- a/src/intel/compiler/brw_nir_opt_peephole_ffma.c
> +++ b/src/intel/compiler/brw_nir_opt_peephole_ffma.c
> @@ -68,7 +68,7 @@ are_all_uses_fadd(nir_ssa_def *def)
>  }
>  
>  static nir_alu_instr *
> -get_mul_for_src(nir_alu_src *src, int num_components,
> +get_mul_for_src(nir_alu_src *src, unsigned num_components,
>  uint8_t swizzle[4], bool *negate, bool *abs)
>  {
> uint8_t swizzle_tmp[4];
> @@ -93,16 +93,19 @@ get_mul_for_src(nir_alu_src *src, int num_components,
> switch (alu->op) {
> case nir_op_imov:
> case nir_op_fmov:
> -  alu = get_mul_for_src(>src[0], num_components, swizzle, negate, 
> abs);
> +  alu = get_mul_for_src(>src[0], alu->dest.dest.ssa.num_components,
> +swizzle, negate, abs);
>break;
>  
> case nir_op_fneg:
> -  alu = get_mul_for_src(>src[0], num_components, swizzle, negate, 
> abs);
> +  alu = get_mul_for_src(>src[0], alu->dest.dest.ssa.num_components,
> +swizzle, negate, abs);
>*negate = !*negate;
>break;
>  
> case nir_op_fabs:
> -  alu = get_mul_for_src(>src[0], num_components, swizzle, negate, 
> abs);
> +  alu = get_mul_for_src(>src[0], alu->dest.dest.ssa.num_components,
> +swizzle, negate, abs);
>*negate = false;
>*abs = true;
>break;
> 

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

Re: [Mesa-dev] [PATCH 1/1] radeonsi: Bump number of allowed global buffers to 32

[Marek Olšák]

This is OK.

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 18, 2018 at 3:43 PM Jan Vesely  wrote:

> Fixes assertion failure/crash when running luxmark/luxball on clover.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108272
> CC: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Jan Vesely 
> ---
> This is just a stop gap measure. OpenCL does not limit the number of
> global buffers, but we can return CL_MEM_OBJECT_ALLOCATION_FAILURE in
> clEnqueueNDRangeKernel.
> What would be the preferred way? Add PIPE_CAP to query this? allow
> set_global_binding to fail with too many buffers?
>
> thanks,
> Jan
>
>  src/gallium/drivers/radeonsi/si_compute.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.h
> b/src/gallium/drivers/radeonsi/si_compute.h
> index 99b501673c..57c0bde4ac 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.h
> +++ b/src/gallium/drivers/radeonsi/si_compute.h
> @@ -29,7 +29,7 @@
>
>  #include "si_shader.h"
>
> -#define MAX_GLOBAL_BUFFERS 22
> +#define MAX_GLOBAL_BUFFERS 32
>
>  struct si_compute {
> struct pipe_reference reference;
> --
> 2.17.2
>
> ___
> 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 1/1] radeonsi: Bump number of allowed global buffers to 32

[Jan Vesely]

Fixes assertion failure/crash when running luxmark/luxball on clover.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108272
CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely 
---
This is just a stop gap measure. OpenCL does not limit the number of
global buffers, but we can return CL_MEM_OBJECT_ALLOCATION_FAILURE in
clEnqueueNDRangeKernel. 
What would be the preferred way? Add PIPE_CAP to query this? allow
set_global_binding to fail with too many buffers?

thanks,
Jan

 src/gallium/drivers/radeonsi/si_compute.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.h 
b/src/gallium/drivers/radeonsi/si_compute.h
index 99b501673c..57c0bde4ac 100644
--- a/src/gallium/drivers/radeonsi/si_compute.h
+++ b/src/gallium/drivers/radeonsi/si_compute.h
@@ -29,7 +29,7 @@
 
 #include "si_shader.h"
 
-#define MAX_GLOBAL_BUFFERS 22
+#define MAX_GLOBAL_BUFFERS 32
 
 struct si_compute {
struct pipe_reference reference;
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH] mesa: allow EXT_texture_compression_s3tc on ES2

[Marek Olšák]

I think you need something like this:
https://cgit.freedesktop.org/~mareko/mesa/commit/?h=amd-extension-pack=ad774f9db1d735811a8d830ad90a2f8208aa0a7b

I also have:
rgtc:
https://cgit.freedesktop.org/~mareko/mesa/commit/?h=amd-extension-pack=c9c0ffc2d40f0119fb31bf0515f321cd877090dd
bptc:
https://cgit.freedesktop.org/~mareko/mesa/commit/?h=amd-extension-pack=111255b6f8b85119da2c5d29dc19abc422fd7a12

and no time to test them.

Marek

On Thu, Oct 18, 2018 at 11:05 AM Erik Faye-Lund <
erik.faye-l...@collabora.com> wrote:

> The extension is written against both GL 1.2 and GLES 2.0, so let's
> also enable it on GLES 2.0.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/mesa/main/extensions_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index 09bf923bd0e..47db1583135 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -278,7 +278,7 @@ EXT(EXT_texture_buffer  ,
> OES_texture_buffer
>  EXT(EXT_texture_compression_dxt1,
> ANGLE_texture_compression_dxt  , GLL, GLC, ES1, ES2, 2004)
>  EXT(EXT_texture_compression_latc,
> EXT_texture_compression_latc   , GLL,  x ,  x ,  x , 2006)
>  EXT(EXT_texture_compression_rgtc,
> ARB_texture_compression_rgtc   , GLL, GLC,  x ,  x , 2004)
> -EXT(EXT_texture_compression_s3tc,
> EXT_texture_compression_s3tc   , GLL, GLC,  x ,  x , 2000)
> +EXT(EXT_texture_compression_s3tc,
> EXT_texture_compression_s3tc   , GLL, GLC,  x , ES2, 2000)
>  EXT(EXT_texture_cube_map, ARB_texture_cube_map
>, GLL,  x ,  x ,  x , 2001)
>  EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array
>,  x ,  x ,  x ,  31, 2014)
>  EXT(EXT_texture_edge_clamp  , dummy_true
>, GLL,  x ,  x ,  x , 1997)
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: fix check for perftest options size

[Andres Rodriguez]

It was using the debug options array size.

CC: mesa-sta...@lists.freedesktop.org
Reviewed-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 429d47325a3..976c42c98f1 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -484,7 +484,7 @@ static const struct debug_control radv_perftest_options[] = 
{
 const char *
 radv_get_perftest_option_name(int id)
 {
-   assert(id < ARRAY_SIZE(radv_debug_options) - 1);
+   assert(id < ARRAY_SIZE(radv_perftest_options) - 1);
return radv_perftest_options[id].string;
 }
 
-- 
2.17.1

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

[Mesa-dev] [Bug 108355] Civilization VI - Artifacts in mouse cursor

[bugzilla-daemon]

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

--- Comment #9 from Hadrien Nilsson  ---
Created attachment 142083
  --> https://bugs.freedesktop.org/attachment.cgi?id=142083=edit
Xorg log with amdgpu_drv 18.1.0

I think you're right to be doubtful. I looked at the log and "amdgpu_drv.so"
18.1 was not loaded as it's not ABI compatible with the rest of my Xorg
installation. So when the bug disappeared I guess I was running in some kind of
fallback mode that does not have the mouse cursor bug :/

Ubuntu 18.10 will be released soon, so maybe I could wait for that version.
Xorg code will probably be updated then.

-- 
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] mesa: allow EXT_texture_compression_s3tc on ES2

[Ilia Mirkin]

On Thu, Oct 18, 2018 at 2:26 PM Erik Faye-Lund
 wrote:
> On Oct 18, 2018 18:21, Ilia Mirkin  wrote:
>
> Have you verified that this works OK on GLES2? This extension enables
> online compression, which isn't normally available in GLES, and I
> wouldn't be surprised if the current mesa TexImage handlers prevent
> it.
>
> The way I read the extension spec, it doesn't enable online compression on 
> gles2. And from testing, it seems like mesa does the right thing. I'll double 
> check, though...

"""
In extended OpenGL ES 2.0.25 these new tokens are accepted by the
 parameter of TexImage2D, CompressedTexImage2D and
the 
parameter of CompressedTexSubImage2D.
"""

and in the ES 2 section of the modifications:

"""
Modify Section 3.7.2, Alternate Texture Image Specification Commands

(add to the end of section)

When the internal format of the texture object is
COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the
update region specified in TexSubImage2D must be aligned to 4x4
pixel blocks. If  or  are not multiples of 4 an
INVALID_OPERATION error is generated. If  is not a multiple
of 4 and  +  is not equal to the width of the LOD
then an INVALID_OPERATION error is generated.  If  is not
a multiple of 4 and  +  is not equal to the
height of the LOD then an INVALID_OPERATION error is generated.
"""

Since you can pass the compressed internal format to TexImage2D, that
implies online compression.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: allow EXT_texture_compression_s3tc on ES2

[Erik Faye-Lund]

On Oct 18, 2018 18:21, Ilia Mirkin  wrote:Have you verified that this works OK on GLES2? This extension enables

online compression, which isn't normally available in GLES, and I

wouldn't be surprised if the current mesa TexImage handlers prevent

it.


The way I read the extension spec, it doesn't enable online compression on gles2. And from testing, it seems like mesa does the right thing. I'll double check, though...
  -ilia

On Thu, Oct 18, 2018 at 11:05 AM Erik Faye-Lund

 wrote:

>

> The extension is written against both GL 1.2 and GLES 2.0, so let's

> also enable it on GLES 2.0.

>

> Signed-off-by: Erik Faye-Lund 

> ---

>  src/mesa/main/extensions_table.h | 2 +-

>  1 file changed, 1 insertion(+), 1 deletion(-)

>

> diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h

> index 09bf923bd0e..47db1583135 100644

> --- a/src/mesa/main/extensions_table.h

> +++ b/src/mesa/main/extensions_table.h

> @@ -278,7 +278,7 @@ EXT(EXT_texture_buffer  , OES_texture_buffer

>  EXT(EXT_texture_compression_dxt1    , ANGLE_texture_compression_dxt  , GLL, GLC, ES1, ES2, 2004)

>  EXT(EXT_texture_compression_latc    , EXT_texture_compression_latc   , GLL,  x ,  x ,  x , 2006)

>  EXT(EXT_texture_compression_rgtc    , ARB_texture_compression_rgtc   , GLL, GLC,  x ,  x , 2004)

> -EXT(EXT_texture_compression_s3tc    , EXT_texture_compression_s3tc   , GLL, GLC,  x ,  x , 2000)

> +EXT(EXT_texture_compression_s3tc    , EXT_texture_compression_s3tc   , GLL, GLC,  x , ES2, 2000)

>  EXT(EXT_texture_cube_map    , ARB_texture_cube_map   , GLL,  x ,  x ,  x , 2001)

>  EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array ,  x ,  x ,  x ,  31, 2014)

>  EXT(EXT_texture_edge_clamp  , dummy_true , GLL,  x ,  x ,  x , 1997)

> --

> 2.17.1

>

> ___

> 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] [PATCH 2/4] radeonsi: use compute shaders for clear_buffer & copy_buffer

[Jan Vesely]

On Thu, 2018-10-18 at 09:32 +0200, Michel Dänzer wrote:
> On 2018-10-17 6:43 p.m., Marek Olšák wrote:
> > Can you test the attached patch?
> 
> Doesn't help, unfortunately. Backtraces with the patch attached.
> 
> FWIW, this is on Bonaire.

Hi,

fwiw, I don't see this hang on my carrizo/iceland machine.

Jan

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



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 mesa] radv: s/abs/fabsf/ for floats

[Matt Turner]

On Thu, Oct 18, 2018 at 8:46 AM Eric Engestrom  wrote:
>
> Fixes: a4c4efad89eceb26cf82 "radv: Rework guard band calculation"
> Cc: Bas Nieuwenhuizen 
> Signed-off-by: Eric Engestrom 
> ---
>  src/amd/vulkan/si_cmd_buffer.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
> index de057657ee70d354e910..52daf99414790d4764b6 100644
> --- a/src/amd/vulkan/si_cmd_buffer.c
> +++ b/src/amd/vulkan/si_cmd_buffer.c
> @@ -516,16 +516,16 @@ si_write_scissors(struct radeon_cmdbuf *cs, int first,
> VkRect2D scissor = si_intersect_scissor([i], 
> _scissor);
>
> get_viewport_xform(viewports + i, scale, translate);
> -   scale[0] = abs(scale[0]);
> -   scale[1] = abs(scale[1]);
> +   scale[0] = fabsf(scale[0]);
> +   scale[1] = fabsf(scale[1]);
>
> if (scale[0] < 0.5)

You might want to suffix these immediates with f at the same time. As
is, this will convert scale[0] to a double before the compairson
against 0.5. I'm assuming that scale[0] is a float, which I've
inferred from the patch but haven't confirmed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] Mesa 18.2.3 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 18.2.3 is now available. Currently we have:
 - 38 queued
 - 1 nominated (outstanding)
 - and 0 rejected patches

The current queue consists of:

Several fixes and workarounds for different games, inlcuding RAGE, Yakuza and
The Evil Within, Wolfenstein The Old Blood ARMA 3, or No Mans Sky.

A bunch of fixes for different drivers, including r600, nouveau, radeonsi, anv,
radv, virgl, i965, nvc0 or nv50. Worth to mention a fix for GPU hangs in
Radeonsi.

State Trackers also get different fixes and corrections.

Finally, fixes for GLSL and NIR are also in this queue.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 18.2.3 this Friday (19th October), around or shortly after 
17:00
GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 61d782c39dc2b131f5a55f1adfbaad3fbaddb017
Author: Timothy Arceri 

radeonsi: use build-id when available for disk cache

(cherry picked from commit 2169acbf34e99842b6234ee8181e1908aafcf120)


commit 8927cf03bbb64d0be1fbb68f1a505b81d3e8ba26
Author: Jason Ekstrand 

anv: Use separate MOCS settings for external BOs

(cherry picked from commit 7a89a0d9edae638e68e4b4ee8e0cbb34baa9c080)


Cheers,
J.A.


Mesa stable queue
-

Nominated (1)
==
Alex Smith (1):
  ca83d51cfb1 ac/nir: Use context-specific LLVM types


Queued (38)
===
Boyuan Zhang (1):
  st/va: use provided sizes and coords for vlVaGetImage

Dave Airlie (1):
  anv: add missing unlock in error path.

Dylan Baker (1):
  meson: Don't allow building EGL on Windows or MacOS

Emil Velikov (5):
  st/nine: do not double-close the fd on teardown
  egl: make eglSwapInterval a no-op for !window surfaces
  egl: make eglSwapBuffers* a no-op for !window surfaces
  vl/dri3: do full teardown on screen_destroy
  Revert "mesa: remove unnecessary 'sort by year' for the GL extensions"

Eric Engestrom (1):
  radv: add missing meson c++ visibility arguments

Fritz Koenig (1):
  i965: Replace checks for rb->Name with FlipY (v2)

Gert Wollny (1):
  virgl, vtest: Correct the transfer size calculation

Ilia Mirkin (4):
  glsl: fix array assignments of a swizzled vector
  nv50,nvc0: mark RGBX_UINT formats as renderable
  nv50,nvc0: guard against zero-size blits
  nvc0: fix blitting red to srgb8_alpha

Jason Ekstrand (7):
  nir/cf: Remove phi sources if needed in nir_handle_add_jump
  anv: Use separate MOCS settings for external BOs
  intel/fs: Fix a typo in need_matching_subreg_offset
  nir/from_ssa: Don't rewrite derefs destinations to registers
  anv/batch_chain: Don't start a new BO just for BATCH_BUFFER_START
  nir/alu_to_scalar: Use ssa_for_alu_src in hand-rolled expansions
  intel: Don't propagate conditional modifiers if a UD source is negated

Józef Kucia (1):
  radeonsi: avoid sending GS_EMIT in shaders without outputs

Marek Olšák (1):
  drirc: add a workaround for ARMA 3

Samuel Pitoiset (1):
  radv: add a workaround for a VGT hang with prim restart and strips

Tapani Pälli (1):
  glsl: do not attempt assignment if operand type not parsed correctly

Timothy Arceri (11):
  glsl: ignore trailing whitespace when define redefined
  util: disable cache if we have no build-id and timestamp is zero
  util: rename timestamp param in disk_cache_create()
  util: add disk_cache_get_function_identifier()
  radeonsi: use build-id when available for disk cache
  nouveau: use build-id when available for disk cache
  r600: use build-id when available for disk cache
  mesa/st: add force_compat_profile option to driconfig
  util: use force_compat_profile for Wolfenstein The Old Blood
  util: better handle program names from wine
  util: add drirc workarounds for RAGE

Vinson Lee (1):
  r600/sb: Fix constant-logical-operand warning.


Rejected (0)
=


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

[Mesa-dev] [PATCH] radeonsi: fix a radeon kernel clear state error

[Jiang, Sonny]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_pipe.c  | 7 +--
 src/gallium/drivers/radeonsi/si_state.c | 5 +++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9d25748df4..3da44483d6 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -991,8 +991,11 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
}
 
/* The mere presense of CLEAR_STATE in the IB causes random GPU hangs
-* on SI. */
-   sscreen->has_clear_state = sscreen->info.chip_class >= CIK;
+* on SI. Some CLEAR_STATE cause asic hang on radeon kernel, etc.
+* SPI_VS_OUT_CONFIG. So only enable CI CLEAR_STATE on amdgpu kernel.*/
+   sscreen->has_clear_state = sscreen->info.chip_class > CIK ||
+  (sscreen->info.chip_class == CIK &&
+  sscreen->info.drm_major == 3);
 
sscreen->has_distributed_tess =
sscreen->info.chip_class >= VI &&
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 8b2e6e57f4..ba84a5a42a 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -4899,8 +4899,9 @@ static void si_init_config(struct si_context *sctx)
bool has_clear_state = sscreen->has_clear_state;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
 
-   /* Only SI can disable CLEAR_STATE for now. */
-   assert(has_clear_state || sscreen->info.chip_class == SI);
+   /* SI, radeon kernel CIK disabled CLEAR_STATE. */
+   assert(has_clear_state || sscreen->info.chip_class == SI ||
+   (sscreen->info.chip_class == CIK && sscreen->info.drm_major != 
3));
 
if (!pm4)
return;
-- 
2.17.1

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

[Mesa-dev] [PATCH v3 3/3] intel/i965: Enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

Enables and passes on i965:
  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*

Signed-off-by: Gert Wollny 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index d7e02efb54..ca921de8e8 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -76,6 +76,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_shading_language_packing = true;
ctx->Extensions.ARB_shadow = true;
ctx->Extensions.ARB_sync = true;
+   ctx->Extensions.EXT_sRGB_write_control = true;
ctx->Extensions.ARB_texture_border_clamp = true;
ctx->Extensions.ARB_texture_compression_rgtc = true;
ctx->Extensions.ARB_texture_cube_map = true;
-- 
2.18.1

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

[Mesa-dev] [PATCH v3 1/3] mesa/core: Add support for EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

This GLES extension gives the applications the control over deciding whether
the conversion from linear space to sRGB is necessary by enabling or
disabling this conversion at framebuffer write or blending time just
like it is possible for desktop GL.

v2: - Correct the extension table to list the extension as GLES only
- drop EXTRA_API_ES3, the requirements for get operations listed
  here get OR-ed. (both Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
 src/mesa/main/enable.c   | 4 ++--
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/get.c  | 5 +
 src/mesa/main/get_hash_params.py | 1 +
 src/mesa/main/mtypes.h   | 1 +
 5 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index bd3e493da5..06c5a0eb68 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -1125,7 +1125,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB, cap);
  _mesa_set_framebuffer_srgb(ctx, state);
@@ -1765,7 +1765,7 @@ _mesa_IsEnabled( GLenum cap )
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB);
  return ctx->Color.sRGBEnabled;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 09bf923bd0..8679ee2fc5 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -265,6 +265,7 @@ EXT(EXT_shader_integer_mix  , 
EXT_shader_integer_mix
 EXT(EXT_shader_io_blocks, dummy_true   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_shader_samples_identical, EXT_shader_samples_identical 
  , GLL, GLC,  x ,  31, 2015)
 EXT(EXT_shadow_funcs, ARB_shadow   
  , GLL,  x ,  x ,  x , 2002)
+EXT(EXT_sRGB_write_control  , EXT_sRGB_write_control   
  ,   x,  x ,  x ,  30, 2013)
 EXT(EXT_stencil_two_side, EXT_stencil_two_side 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_stencil_wrap, dummy_true   
  , GLL,  x ,  x ,  x , 2002)
 EXT(EXT_subtexture  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 1b1679e8bf..3a77bc6f8d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -394,6 +394,11 @@ static const int extra_ARB_compute_shader_es31[] = {
EXTRA_END
 };
 
+static const int extra_EXT_sRGB_write_control_es30[] = {
+   EXT(EXT_sRGB_write_control),
+   EXTRA_END
+};
+
 static const int extra_ARB_shader_storage_buffer_object_es31[] = {
EXT(ARB_shader_storage_buffer_object),
EXTRA_API_ES31,
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 1840db6ebb..822fab8151 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -262,6 +262,7 @@ descriptor=[
 # Enums in GLES2, GLES3
 { "apis": ["GLES2", "GLES3"], "params": [
   [ "GPU_DISJOINT_EXT", "LOC_CUSTOM, TYPE_INT, 0, 
extra_EXT_disjoint_timer_query" ],
+  [ "FRAMEBUFFER_SRGB_EXT", "CONTEXT_BOOL(Color.sRGBEnabled), 
extra_EXT_sRGB_write_control_es30" ],
 ]},
 
 { "apis": ["GL", "GL_CORE", "GLES2"], "params": [
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9ed49b7ff2..31cf62fdb6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4253,6 +4253,7 @@ struct gl_extensions
GLboolean EXT_semaphore_fd;
GLboolean EXT_shader_integer_mix;
GLboolean EXT_shader_samples_identical;
+   GLboolean EXT_sRGB_write_control;
GLboolean EXT_stencil_two_side;
GLboolean EXT_texture_array;
GLboolean EXT_texture_compression_latc;
-- 
2.18.1

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

[Mesa-dev] [PATCH v3 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

The series now also correct for the Gallium drivers. 

best, 
Gert 

Gert Wollny (3):
  mesa/core: Add support for EXT_sRGB_write_control
  mesa/st: enable EXT_sRGB_write_control for drivers that support it
  intel/i965: Enable extension EXT_sRGB_write_control

 src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
 src/mesa/main/enable.c   |  4 +--
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/get.c  |  5 +++
 src/mesa/main/get_hash_params.py |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/state_tracker/st_extensions.c   |  6 
 src/mesa/state_tracker/st_manager.c  | 37 
 8 files changed, 40 insertions(+), 16 deletions(-)

-- 
2.18.1

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

[Mesa-dev] [PATCH v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Gert Wollny]

From: Gert Wollny 

With this patch the extension EXT_sRGB_write_control is enabled for
gallium drivers that support sRGB formats as render targets.

Tested (and pass) on r600 (evergreen) and softpipe:

  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*

with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for this), and

  
dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum

when extension is manually disabled via MESA_EXTENSION_OVERRIDE

v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
- Correct handling by moving extension initialization to the
  place where gallium/st actually takes care of this. This also
  fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
- reinstate check for desktop GL and add check for the extension
  when creating the framebuffer

v3: Only create sRGB renderbuffers based on Visual.srgbCapable when
on desktop GL.

Signed-off-by: Gert Wollny 
---
 src/mesa/state_tracker/st_extensions.c |  6 +
 src/mesa/state_tracker/st_manager.c| 37 --
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 798ee60875..401609d728 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1169,6 +1169,12 @@ void st_init_extensions(struct pipe_screen *screen,
  void_formats, 32,
  PIPE_BIND_RENDER_TARGET);
 
+  extensions->EXT_sRGB_write_control =
+ screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_SRGB,
+ PIPE_TEXTURE_2D, 0, 0,
+ (PIPE_BIND_DISPLAY_TARGET |
+  PIPE_BIND_RENDER_TARGET));
+
   if (extensions->AMD_framebuffer_multisample_advanced) {
  /* AMD_framebuffer_multisample_advanced */
  /* This can be greater than storage samples. */
diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index ceb48dd490..df898beb23 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct st_framebuffer 
*stfb)
  */
 static boolean
 st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
-gl_buffer_index idx)
+gl_buffer_index idx, bool prefer_srgb)
 {
struct gl_renderbuffer *rb;
enum pipe_format format;
@@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
   break;
default:
   format = stfb->iface->visual->color_format;
-  if (stfb->Base.Visual.sRGBCapable)
+  if (prefer_srgb)
  format = util_format_srgb(format);
   sw = FALSE;
   break;
@@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
struct st_framebuffer *stfb;
struct gl_config mode;
gl_buffer_index idx;
+   bool prefer_srgb = false;
 
if (!stfbi)
   return NULL;
@@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
 * format such that util_format_srgb(visual->color_format) can be supported
 * by the pipe driver.  We still need to advertise the capability here.
 *
-* For GLES, however, sRGB framebuffer write is controlled only by the
-* capability of the framebuffer.  There is GL_EXT_sRGB_write_control to
-* give applications the control back, but sRGB write is still enabled by
-* default.  To avoid unexpected results, we should not advertise the
-* capability.  This could change when we add support for
-* EGL_KHR_gl_colorspace.
+* For GLES, however, sRGB framebuffer write is initially only controlled
+* by the capability of the framebuffer, with GL_EXT_sRGB_write_control
+* control is given back to the applications, but GL_FRAMEBUFFER_SRGB is
+* still enabled by default since this is the behaviour when
+* EXT_sRGB_write_control is not available.
 */
-   if (_mesa_is_desktop_gl(st->ctx)) {
+   if (_mesa_is_desktop_gl(st->ctx) ||
+   st->ctx->Extensions.EXT_sRGB_write_control)
+   {
   struct pipe_screen *screen = st->pipe->screen;
   const enum pipe_format srgb_format =
  util_format_srgb(stfbi->visual->color_format);
@@ -475,8 +477,14 @@ st_framebuffer_create(struct st_context *st,
   PIPE_TEXTURE_2D, stfbi->visual->samples,
   stfbi->visual->samples,
   (PIPE_BIND_DISPLAY_TARGET |
-   PIPE_BIND_RENDER_TARGET)))
+   PIPE_BIND_RENDER_TARGET))) {
  mode.sRGBCapable = GL_TRUE;
+ /* Since GL_FRAMEBUFFER_SRGB is enabled by default on GLES we must not
+  * 

[Mesa-dev] [PATCH] anv: Allow presenting via a different GPU

[Alex Smith]

anv_GetPhysicalDeviceSurfaceSupportKHR will already return success for
this, but anv_GetPhysicalDevice{Xcb,Xlib}PresentationSupportKHR do not.
Apps which check for presentation support via the latter (all Feral
Vulkan games at least) will therefore fail.

This allows me to render on an Intel GPU and present to a display
connected to an AMD card (tested HD 530 + Vega 64).

Signed-off-by: Alex Smith 
---
 src/intel/vulkan/anv_wsi_x11.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
index 2feb5f1337..d23cedb316 100644
--- a/src/intel/vulkan/anv_wsi_x11.c
+++ b/src/intel/vulkan/anv_wsi_x11.c
@@ -42,7 +42,7 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
   >wsi_device,
   >instance->alloc,
   queueFamilyIndex,
-  device->local_fd, false,
+  device->local_fd, true,
   connection, visual_id);
 }
 
@@ -58,7 +58,7 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(
   >wsi_device,
   >instance->alloc,
   queueFamilyIndex,
-  device->local_fd, false,
+  device->local_fd, true,
   XGetXCBConnection(dpy), visualID);
 }
 
-- 
2.14.4

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

Re: [Mesa-dev] [PATCH] mesa: allow EXT_texture_compression_s3tc on ES2

[Ilia Mirkin]

Have you verified that this works OK on GLES2? This extension enables
online compression, which isn't normally available in GLES, and I
wouldn't be surprised if the current mesa TexImage handlers prevent
it.

  -ilia
On Thu, Oct 18, 2018 at 11:05 AM Erik Faye-Lund
 wrote:
>
> The extension is written against both GL 1.2 and GLES 2.0, so let's
> also enable it on GLES 2.0.
>
> Signed-off-by: Erik Faye-Lund 
> ---
>  src/mesa/main/extensions_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 09bf923bd0e..47db1583135 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -278,7 +278,7 @@ EXT(EXT_texture_buffer  , 
> OES_texture_buffer
>  EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt  
> , GLL, GLC, ES1, ES2, 2004)
>  EXT(EXT_texture_compression_latc, EXT_texture_compression_latc   
> , GLL,  x ,  x ,  x , 2006)
>  EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc   
> , GLL, GLC,  x ,  x , 2004)
> -EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc   
> , GLL, GLC,  x ,  x , 2000)
> +EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc   
> , GLL, GLC,  x , ES2, 2000)
>  EXT(EXT_texture_cube_map, ARB_texture_cube_map   
> , GLL,  x ,  x ,  x , 2001)
>  EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array 
> ,  x ,  x ,  x ,  31, 2014)
>  EXT(EXT_texture_edge_clamp  , dummy_true 
> , GLL,  x ,  x ,  x , 1997)
> --
> 2.17.1
>
> ___
> 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] [PATCH] vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching

[Eric Engestrom]

On Thursday, 2018-10-18 10:13:39 -0500, Jason Ekstrand wrote:
> This lets us avoid passing the DRM fd around all over the place and gets
> us closer to layer utopia.

Yay!
Reviewed-by: Eric Engestrom 

> ---
>  src/amd/vulkan/radv_wsi.c   |  3 --
>  src/amd/vulkan/radv_wsi_x11.c   |  4 +--
>  src/intel/vulkan/anv_wsi.c  |  4 +--
>  src/intel/vulkan/anv_wsi_x11.c  |  4 +--
>  src/vulkan/wsi/wsi_common.c | 45 +
>  src/vulkan/wsi/wsi_common.h |  5 ++--
>  src/vulkan/wsi/wsi_common_display.c | 22 +-
>  src/vulkan/wsi/wsi_common_private.h |  6 ++--
>  src/vulkan/wsi/wsi_common_wayland.c |  3 --
>  src/vulkan/wsi/wsi_common_x11.c | 34 +++---
>  src/vulkan/wsi/wsi_common_x11.h |  1 -
>  11 files changed, 61 insertions(+), 70 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> index 43103a4ef85..346fb43d675 100644
> --- a/src/amd/vulkan/radv_wsi.c
> +++ b/src/amd/vulkan/radv_wsi.c
> @@ -72,7 +72,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
>   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
>  
>   return wsi_common_get_surface_support(>wsi_device,
> -   device->local_fd,
> queueFamilyIndex,
> surface,
> pSupported);
> @@ -171,7 +170,6 @@ VkResult radv_CreateSwapchainKHR(
>  
>   return wsi_common_create_swapchain(>physical_device->wsi_device,
>  radv_device_to_handle(device),
> -device->physical_device->local_fd,
>  pCreateInfo,
>  alloc,
>  pSwapchain);
> @@ -294,7 +292,6 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
>   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
>  
>   return wsi_common_get_present_rectangles(>wsi_device,
> -  device->local_fd,
>surface,
>pRectCount, pRects);
>  }
> diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
> index 9ef02ccc435..f3ebc791e2d 100644
> --- a/src/amd/vulkan/radv_wsi_x11.c
> +++ b/src/amd/vulkan/radv_wsi_x11.c
> @@ -45,7 +45,7 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
>queueFamilyIndex,
> -  device->local_fd, true,
> +  true,
>connection, visual_id);
>  }
>  
> @@ -60,7 +60,7 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
>queueFamilyIndex,
> -  device->local_fd, true,
> +  true,
>XGetXCBConnection(dpy), visualID);
>  }
>  
> diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
> index 5d672c211c4..024bc1c245d 100644
> --- a/src/intel/vulkan/anv_wsi.c
> +++ b/src/intel/vulkan/anv_wsi.c
> @@ -89,7 +89,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
> ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
>  
> return wsi_common_get_surface_support(>wsi_device,
> - device->local_fd,
>   queueFamilyIndex,
>   surface,
>   pSupported);
> @@ -183,7 +182,7 @@ VkResult anv_CreateSwapchainKHR(
> else
>   alloc = >alloc;
>  
> -   return wsi_common_create_swapchain(wsi_device, _device, device->fd,
> +   return wsi_common_create_swapchain(wsi_device, _device,
>pCreateInfo, alloc, pSwapchain);
>  }
>  
> @@ -303,7 +302,6 @@ VkResult anv_GetPhysicalDevicePresentRectanglesKHR(
> ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
>  
> return wsi_common_get_present_rectangles(>wsi_device,
> -device->local_fd,
>  surface,
>  pRectCount, pRects);
>  }
> diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
> index 45c43f6f17f..bfa76e88e79 100644
> --- a/src/intel/vulkan/anv_wsi_x11.c
> +++ b/src/intel/vulkan/anv_wsi_x11.c
> @@ -41,7 +41,7 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
>queueFamilyIndex,
> -  device->local_fd, false,
> +  false,
>connection, visual_id);
>  }
>  
> @@ -56,7 +56,7 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(
> return 

[Mesa-dev] [PATCH mesa] radv: s/abs/fabsf/ for floats

[Eric Engestrom]

Fixes: a4c4efad89eceb26cf82 "radv: Rework guard band calculation"
Cc: Bas Nieuwenhuizen 
Signed-off-by: Eric Engestrom 
---
 src/amd/vulkan/si_cmd_buffer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index de057657ee70d354e910..52daf99414790d4764b6 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -516,16 +516,16 @@ si_write_scissors(struct radeon_cmdbuf *cs, int first,
VkRect2D scissor = si_intersect_scissor([i], 
_scissor);
 
get_viewport_xform(viewports + i, scale, translate);
-   scale[0] = abs(scale[0]);
-   scale[1] = abs(scale[1]);
+   scale[0] = fabsf(scale[0]);
+   scale[1] = fabsf(scale[1]);
 
if (scale[0] < 0.5)
scale[0] = 0.5;
if (scale[1] < 0.5)
scale[1] = 0.5;
 
-   guardband_x = MIN2(guardband_x, (max_range - abs(translate[0])) 
/ scale[0]);
-   guardband_y = MIN2(guardband_y, (max_range - abs(translate[1])) 
/ scale[1]);
+   guardband_x = MIN2(guardband_x, (max_range - 
fabsf(translate[0])) / scale[0]);
+   guardband_y = MIN2(guardband_y, (max_range - 
fabsf(translate[1])) / scale[1]);
 
radeon_emit(cs, S_028250_TL_X(scissor.offset.x) |
S_028250_TL_Y(scissor.offset.y) |
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH] vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching

[Lionel Landwerlin]

Looks good :


Reviewed-by: Lionel Landwerlin 


On 18/10/2018 16:13, Jason Ekstrand wrote:

This lets us avoid passing the DRM fd around all over the place and gets
us closer to layer utopia.
---
  src/amd/vulkan/radv_wsi.c   |  3 --
  src/amd/vulkan/radv_wsi_x11.c   |  4 +--
  src/intel/vulkan/anv_wsi.c  |  4 +--
  src/intel/vulkan/anv_wsi_x11.c  |  4 +--
  src/vulkan/wsi/wsi_common.c | 45 +
  src/vulkan/wsi/wsi_common.h |  5 ++--
  src/vulkan/wsi/wsi_common_display.c | 22 +-
  src/vulkan/wsi/wsi_common_private.h |  6 ++--
  src/vulkan/wsi/wsi_common_wayland.c |  3 --
  src/vulkan/wsi/wsi_common_x11.c | 34 +++---
  src/vulkan/wsi/wsi_common_x11.h |  1 -
  11 files changed, 61 insertions(+), 70 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 43103a4ef85..346fb43d675 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -72,7 +72,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
  
  	return wsi_common_get_surface_support(>wsi_device,

- device->local_fd,
  queueFamilyIndex,
  surface,
  pSupported);
@@ -171,7 +170,6 @@ VkResult radv_CreateSwapchainKHR(
  
  	return wsi_common_create_swapchain(>physical_device->wsi_device,

   radv_device_to_handle(device),
-  device->physical_device->local_fd,
   pCreateInfo,
   alloc,
   pSwapchain);
@@ -294,7 +292,6 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
  
  	return wsi_common_get_present_rectangles(>wsi_device,

-device->local_fd,
 surface,
 pRectCount, pRects);
  }
diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
index 9ef02ccc435..f3ebc791e2d 100644
--- a/src/amd/vulkan/radv_wsi_x11.c
+++ b/src/amd/vulkan/radv_wsi_x11.c
@@ -45,7 +45,7 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(
 return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
queueFamilyIndex,
-  device->local_fd, true,
+  true,
connection, visual_id);
  }
  
@@ -60,7 +60,7 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(

 return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
queueFamilyIndex,
-  device->local_fd, true,
+  true,
XGetXCBConnection(dpy), visualID);
  }
  
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c

index 5d672c211c4..024bc1c245d 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -89,7 +89,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
 ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
  
 return wsi_common_get_surface_support(>wsi_device,

- device->local_fd,
   queueFamilyIndex,
   surface,
   pSupported);
@@ -183,7 +182,7 @@ VkResult anv_CreateSwapchainKHR(
 else
   alloc = >alloc;
  
-   return wsi_common_create_swapchain(wsi_device, _device, device->fd,

+   return wsi_common_create_swapchain(wsi_device, _device,
pCreateInfo, alloc, pSwapchain);
  }
  
@@ -303,7 +302,6 @@ VkResult anv_GetPhysicalDevicePresentRectanglesKHR(

 ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
  
 return wsi_common_get_present_rectangles(>wsi_device,

-device->local_fd,
  surface,
  pRectCount, pRects);
  }
diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
index 45c43f6f17f..bfa76e88e79 100644
--- a/src/intel/vulkan/anv_wsi_x11.c
+++ b/src/intel/vulkan/anv_wsi_x11.c
@@ -41,7 +41,7 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
 return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
queueFamilyIndex,
-  device->local_fd, false,
+  false,
connection, visual_id);
  }
  
@@ -56,7 +56,7 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(

 return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
queueFamilyIndex,
-  device->local_fd, false,
+  false,
  

[Mesa-dev] [PATCH] vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching

[Jason Ekstrand]

This lets us avoid passing the DRM fd around all over the place and gets
us closer to layer utopia.
---
 src/amd/vulkan/radv_wsi.c   |  3 --
 src/amd/vulkan/radv_wsi_x11.c   |  4 +--
 src/intel/vulkan/anv_wsi.c  |  4 +--
 src/intel/vulkan/anv_wsi_x11.c  |  4 +--
 src/vulkan/wsi/wsi_common.c | 45 +
 src/vulkan/wsi/wsi_common.h |  5 ++--
 src/vulkan/wsi/wsi_common_display.c | 22 +-
 src/vulkan/wsi/wsi_common_private.h |  6 ++--
 src/vulkan/wsi/wsi_common_wayland.c |  3 --
 src/vulkan/wsi/wsi_common_x11.c | 34 +++---
 src/vulkan/wsi/wsi_common_x11.h |  1 -
 11 files changed, 61 insertions(+), 70 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 43103a4ef85..346fb43d675 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -72,7 +72,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
 
return wsi_common_get_surface_support(>wsi_device,
- device->local_fd,
  queueFamilyIndex,
  surface,
  pSupported);
@@ -171,7 +170,6 @@ VkResult radv_CreateSwapchainKHR(
 
return wsi_common_create_swapchain(>physical_device->wsi_device,
   radv_device_to_handle(device),
-  device->physical_device->local_fd,
   pCreateInfo,
   alloc,
   pSwapchain);
@@ -294,7 +292,6 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
 
return wsi_common_get_present_rectangles(>wsi_device,
-device->local_fd,
 surface,
 pRectCount, pRects);
 }
diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
index 9ef02ccc435..f3ebc791e2d 100644
--- a/src/amd/vulkan/radv_wsi_x11.c
+++ b/src/amd/vulkan/radv_wsi_x11.c
@@ -45,7 +45,7 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(
return wsi_get_physical_device_xcb_presentation_support(
   >wsi_device,
   queueFamilyIndex,
-  device->local_fd, true,
+  true,
   connection, visual_id);
 }
 
@@ -60,7 +60,7 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(
return wsi_get_physical_device_xcb_presentation_support(
   >wsi_device,
   queueFamilyIndex,
-  device->local_fd, true,
+  true,
   XGetXCBConnection(dpy), visualID);
 }
 
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 5d672c211c4..024bc1c245d 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -89,7 +89,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
 
return wsi_common_get_surface_support(>wsi_device,
- device->local_fd,
  queueFamilyIndex,
  surface,
  pSupported);
@@ -183,7 +182,7 @@ VkResult anv_CreateSwapchainKHR(
else
  alloc = >alloc;
 
-   return wsi_common_create_swapchain(wsi_device, _device, device->fd,
+   return wsi_common_create_swapchain(wsi_device, _device,
   pCreateInfo, alloc, pSwapchain);
 }
 
@@ -303,7 +302,6 @@ VkResult anv_GetPhysicalDevicePresentRectanglesKHR(
ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
 
return wsi_common_get_present_rectangles(>wsi_device,
-device->local_fd,
 surface,
 pRectCount, pRects);
 }
diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
index 45c43f6f17f..bfa76e88e79 100644
--- a/src/intel/vulkan/anv_wsi_x11.c
+++ b/src/intel/vulkan/anv_wsi_x11.c
@@ -41,7 +41,7 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
return wsi_get_physical_device_xcb_presentation_support(
   >wsi_device,
   queueFamilyIndex,
-  device->local_fd, false,
+  false,
   connection, visual_id);
 }
 
@@ -56,7 +56,7 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(
return wsi_get_physical_device_xcb_presentation_support(
   >wsi_device,
   queueFamilyIndex,
-  device->local_fd, false,
+  false,
   XGetXCBConnection(dpy), visualID);
 }
 
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index ad4b8c9075e..51d8655a5a9 

[Mesa-dev] [PATCH] mesa: allow EXT_texture_compression_s3tc on ES2

[Erik Faye-Lund]

The extension is written against both GL 1.2 and GLES 2.0, so let's
also enable it on GLES 2.0.

Signed-off-by: Erik Faye-Lund 
---
 src/mesa/main/extensions_table.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 09bf923bd0e..47db1583135 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -278,7 +278,7 @@ EXT(EXT_texture_buffer  , 
OES_texture_buffer
 EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt
  , GLL, GLC, ES1, ES2, 2004)
 EXT(EXT_texture_compression_latc, EXT_texture_compression_latc 
  , GLL,  x ,  x ,  x , 2006)
 EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc 
  , GLL, GLC,  x ,  x , 2004)
-EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc 
  , GLL, GLC,  x ,  x , 2000)
+EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc 
  , GLL, GLC,  x , ES2, 2000)
 EXT(EXT_texture_cube_map, ARB_texture_cube_map 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_texture_edge_clamp  , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
-- 
2.17.1

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

Re: [Mesa-dev] correction: only regresses for Gallium drivers

[Gert Wollny]

Am Donnerstag, den 18.10.2018, 16:01 +0200 schrieb Gert Wollny:
> Ignore this series, there are regressions, at least 
> 
>   dEQP-GLES2.functional.texture.specification.
> basic_copyteximage2d.2d_alpha
> 
> glCopyTexImage2D(srgb usage mismatch)

This regresses on gallium drivers (tested r600, llvmpipe, softpipe), on
Intel i965 it can be enabled, so the first and the third patch should
be okay, the second not. 

Best, 
Gert

> 
> Best, 
> Gert 
> 
> Am Donnerstag, den 18.10.2018, 10:46 +0200 schrieb Gert Wollny:
> > From: Gert Wollny 
> > 
> > This is the updated version of the patches following Ilia's
> > pointers,
> > but also correcting some additional parts. 
> > 
> > Changes: 
> > 
> >  - core: Correct the extension table to list the extension as GLES
> > only
> >  - core: drop EXTRA_API_ES3, the requirements for get operations
> > listed
> >   here get OR-ed. (both Ilia Mirkin)
> >  - gallium: always enable the extension when sRGB is supported
> > (Ilia
> > Mirkin).
> >  - gallium: Correct handling by moving extension initialization to
> > the
> >  place where gallium/st actually takes care of this. This also
> >  fixes properly disabling the extension via
> > MESA_EXTENSION_OVERRIDE
> >  - gallium: reinstate check for desktop GL and add check for the
> > extension
> >  when creating the framebuffer
> >  - intel: Also text whether the extension is properly disabled by
> >  MESA_EXTENSION_OVERRIDE 
> > 
> > best, 
> > Gert
> > 
> > Gert Wollny (3):
> >   mesa/core: Add support for EXT_sRGB_write_control
> >   mesa/st: enable EXT_sRGB_write_control for drivers that support
> > it
> >   intel/i965: Enable extension EXT_sRGB_write_control
> > 
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
> >  src/mesa/main/enable.c   |  4 ++--
> >  src/mesa/main/extensions_table.h |  1 +
> >  src/mesa/main/get.c  |  5 +
> >  src/mesa/main/get_hash_params.py |  1 +
> >  src/mesa/main/mtypes.h   |  1 +
> >  src/mesa/state_tracker/st_extensions.c   |  6 ++
> >  src/mesa/state_tracker/st_manager.c  | 13 ++---
> >  8 files changed, 23 insertions(+), 9 deletions(-)
> > 
> 
> ___
> 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] Scons/GLES: shared_glapi and osmesa link failure

[Liviu Prodea]

 Well, all this started in that Github issue thread. That guy @elkhalafy was 
using llvmpipe to get Blender 2.80 to work on his system with unsupported (too 
old) iGPU. I don't know what he did but it resulted in Blender failing with 
missing libglapi.dll. So I researched about how to build it and it led me to 
this build variable gles of type boolean. When set to true it builds glapi as a 
shared library named libglapi.dll. It is also a requirement to build 
libGLESv1_CM.dll and libGLESv2.dll which only get build when selecting all 
build targets or probably I wasn't able to find the right target(s). 

A Meson build approximation is -Dgles1=true -Dgles2=true which builds all 3 
DLLs and it is default unlike in Scons case,

On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca 
 wrote:  
 
 I don't know what gles=y entails anymore, but if it's broken we should 
simply remove it.

That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile 
extension, even without gles=y option.

So what exactly are you looking for here?

Jose

On 18/10/18 13:02, Liviu Prodea wrote:
> scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
> 
> Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and 
> object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
> osmesa.obj : error LNK2001: unresolved external symbol 
> __imp___glapi_check_multithread
> osmesa.obj : error LNK2001: unresolved external symbol 
> __imp___glapi_get_proc_address
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_set_context
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_set_dispatch
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_set_nop_handler
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_new_nop_table
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_Context
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_get_dispatch_table_size
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_get_context
> mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_add_dispatch
> mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_get_dispatch
> mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_Dispatch
> build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: 
> 12 unresolved externals
> scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
> st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_get_proc_address
> mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_check_multithread
> mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_set_dispatch
> mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_set_context
> mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_get_dispatch_table_size
> mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
> __imp___glapi_add_dispatch
> build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error 
> LNK1120: 6 unresolved externals
> scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120
> scons: building terminated because of errors.
> 
> This is a long standing issue. First reported here:
> 
> https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html 
> 
> 
> Encountered again in 2016:
> 
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html 
> 
> 
> and finally by myself in early 2018:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=106843 
> 
> 
> Eric Engestrom suggested me to try the work in progress Meson build for 
> Windows. Unfortunately it has other issues which prevents it from being 
> ready for prime time as I 

[Mesa-dev] [PATCH 1/3] ac: Introduce ac_build_expand()

[Connor Abbott]

And implement ac_bulid_expand_to_vec4() on top of it.

Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit 
buffer loads")
---
 src/amd/common/ac_llvm_build.c | 40 ++
 src/amd/common/ac_llvm_build.h |  3 +++
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 2d78ca1b52a..c54a50dcd86 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -523,39 +523,51 @@ ac_build_gather_values(struct ac_llvm_context *ctx,
return ac_build_gather_values_extended(ctx, values, value_count, 1, 
false, false);
 }
 
-/* Expand a scalar or vector to <4 x type> by filling the remaining channels
- * with undef. Extract at most num_channels components from the input.
+/* Expand a scalar or vector to  by filling the remaining
+ * channels with undef. Extract at most src_channels components from the input.
  */
-LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
-LLVMValueRef value,
-unsigned num_channels)
+LLVMValueRef ac_build_expand(struct ac_llvm_context *ctx,
+LLVMValueRef value,
+unsigned src_channels,
+unsigned dst_channels)
 {
LLVMTypeRef elemtype;
-   LLVMValueRef chan[4];
+   LLVMValueRef chan[dst_channels];
 
if (LLVMGetTypeKind(LLVMTypeOf(value)) == LLVMVectorTypeKind) {
unsigned vec_size = LLVMGetVectorSize(LLVMTypeOf(value));
-   num_channels = MIN2(num_channels, vec_size);
 
-   if (num_channels >= 4)
+   if (src_channels == dst_channels && vec_size == dst_channels)
return value;
 
-   for (unsigned i = 0; i < num_channels; i++)
+   src_channels = MIN2(src_channels, vec_size);
+
+   for (unsigned i = 0; i < src_channels; i++)
chan[i] = ac_llvm_extract_elem(ctx, value, i);
 
elemtype = LLVMGetElementType(LLVMTypeOf(value));
} else {
-   if (num_channels) {
-   assert(num_channels == 1);
+   if (src_channels) {
+   assert(src_channels == 1);
chan[0] = value;
}
elemtype = LLVMTypeOf(value);
}
 
-   while (num_channels < 4)
-   chan[num_channels++] = LLVMGetUndef(elemtype);
+   for (unsigned i = src_channels; i < dst_channels; i++)
+   chan[i] = LLVMGetUndef(elemtype);
+
+   return ac_build_gather_values(ctx, chan, dst_channels);
+}
 
-   return ac_build_gather_values(ctx, chan, 4);
+/* Expand a scalar or vector to <4 x type> by filling the remaining channels
+ * with undef. Extract at most num_channels components from the input.
+ */
+LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
+LLVMValueRef value,
+unsigned num_channels)
+{
+   return ac_build_expand(ctx, value, num_channels, 4);
 }
 
 LLVMValueRef ac_build_round(struct ac_llvm_context *ctx, LLVMValueRef value)
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index f68efbc49ff..1275e4fb698 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -172,6 +172,9 @@ LLVMValueRef
 ac_build_gather_values(struct ac_llvm_context *ctx,
   LLVMValueRef *values,
   unsigned value_count);
+LLVMValueRef ac_build_expand(struct ac_llvm_context *ctx,
+LLVMValueRef value,
+unsigned src_channels, unsigned dst_channels);
 LLVMValueRef ac_build_expand_to_vec4(struct ac_llvm_context *ctx,
 LLVMValueRef value,
 unsigned num_channels);
-- 
2.17.2

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

[Mesa-dev] [PATCH 3/3] Revert "radv: disable VK_SUBGROUP_FEATURE_VOTE_BIT"

[Connor Abbott]

This reverts commit 647c2b90e96a9ab8571baf958a7c67c1e816911a. There was
one recently-introduced bug in ac for dvec3 loads, but the other test
failures were actually bugs in the tests. See
https://github.com/cwabbott0/VK-GL-CTS/tree/voteallequal-fixes
---
 src/amd/vulkan/radv_device.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 6eb37472992..4a705a724ef 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1057,14 +1057,12 @@ void radv_GetPhysicalDeviceProperties2(
(VkPhysicalDeviceSubgroupProperties*)ext;
properties->subgroupSize = 64;
properties->supportedStages = VK_SHADER_STAGE_ALL;
-   /* TODO: Enable VK_SUBGROUP_FEATURE_VOTE_BIT when wwm
-* is fixed in LLVM.
-*/
properties->supportedOperations =

VK_SUBGROUP_FEATURE_ARITHMETIC_BIT |

VK_SUBGROUP_FEATURE_BASIC_BIT |

VK_SUBGROUP_FEATURE_BALLOT_BIT |
-   
VK_SUBGROUP_FEATURE_QUAD_BIT;
+   
VK_SUBGROUP_FEATURE_QUAD_BIT |
+   
VK_SUBGROUP_FEATURE_VOTE_BIT;
if (pdevice->rad_info.chip_class >= VI) {
properties->supportedOperations |=

VK_SUBGROUP_FEATURE_SHUFFLE_BIT |
-- 
2.17.2

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

[Mesa-dev] [PATCH 2/3] ac: Fix loading a dvec3 from an SSBO

[Connor Abbott]

The comment was wrong, since the loop above casts to a type with the
correct bitsize already.

Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit 
buffer loads")
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 402cf2d6655..ee75e2890dd 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1685,8 +1685,8 @@ static LLVMValueRef visit_load_buffer(struct 
ac_nir_context *ctx,
};
 
if (num_bytes > 16 && num_components == 3) {
-   /* we end up with a v4f32 and v2f32 but shuffle fails 
on that */
-   results[1] = ac_build_expand_to_vec4(>ac, 
results[1], 2);
+   /* we end up with a v2i64 and i64 but shuffle fails on 
that */
+   results[1] = ac_build_expand(>ac, results[1], 1, 
2);
}
 
LLVMValueRef swizzle = LLVMConstVector(masks, num_components);
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 1/2] vulkan/wsi: Store the instance allocator in wsi_device

[Eric Engestrom]

On Thursday, 2018-10-18 08:02:42 -0500, Jason Ekstrand wrote:
> On October 18, 2018 05:40:14 Eric Engestrom  wrote:
> 
> > On Wednesday, 2018-10-17 15:14:03 -0500, Jason Ekstrand wrote:
> > > We already have wsi_device and we know the instance allocator at
> > > wsi_device_init time so there's no need to pass it into the physical
> > > device queries.  This also fixes a memory allocation domain bug that can
> > > occur if CreateSwapchain gets called prior to any queries (not likely)
> > > in which case the cached connection gets allocated off the device
> > > instead of the instance.
> > > ---
> > > src/amd/vulkan/radv_wsi.c   |  1 -
> > > src/amd/vulkan/radv_wsi_x11.c   |  2 --
> > > src/intel/vulkan/anv_wsi.c  |  1 -
> > > src/intel/vulkan/anv_wsi_x11.c  |  2 --
> > > src/vulkan/wsi/wsi_common.c |  4 ++--
> > > src/vulkan/wsi/wsi_common.h |  4 +++-
> > > src/vulkan/wsi/wsi_common_display.c |  1 -
> > > src/vulkan/wsi/wsi_common_private.h |  1 -
> > > src/vulkan/wsi/wsi_common_wayland.c |  1 -
> > > src/vulkan/wsi/wsi_common_x11.c | 25 +++--
> > > src/vulkan/wsi/wsi_common_x11.h |  1 -
> > > 11 files changed, 16 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> > > index 6479bea070b..8b165ea3916 100644
> > > --- a/src/amd/vulkan/radv_wsi.c
> > > +++ b/src/amd/vulkan/radv_wsi.c
> > > @@ -75,7 +75,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
> > >device->local_fd,
> > >queueFamilyIndex,
> > >surface,
> > > -  >instance->alloc,
> > >pSupported);
> > > }
> > > 
> > > diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
> > > index c65ac938772..9ef02ccc435 100644
> > > --- a/src/amd/vulkan/radv_wsi_x11.c
> > > +++ b/src/amd/vulkan/radv_wsi_x11.c
> > > @@ -44,7 +44,6 @@ VkBool32 
> > > radv_GetPhysicalDeviceXcbPresentationSupportKHR(
> > > 
> > > return wsi_get_physical_device_xcb_presentation_support(
> > > >wsi_device,
> > > -  >instance->alloc,
> > > queueFamilyIndex,
> > > device->local_fd, true,
> > > connection, visual_id);
> > > @@ -60,7 +59,6 @@ VkBool32 
> > > radv_GetPhysicalDeviceXlibPresentationSupportKHR(
> > > 
> > > return wsi_get_physical_device_xcb_presentation_support(
> > > >wsi_device,
> > > -  >instance->alloc,
> > > queueFamilyIndex,
> > > device->local_fd, true,
> > > XGetXCBConnection(dpy), visualID);
> > > diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
> > > index 5ed1d711689..1c9a54804e8 100644
> > > --- a/src/intel/vulkan/anv_wsi.c
> > > +++ b/src/intel/vulkan/anv_wsi.c
> > > @@ -92,7 +92,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
> > >  device->local_fd,
> > >  queueFamilyIndex,
> > >  surface,
> > > - >instance->alloc,
> > >  pSupported);
> > > }
> > > 
> > > diff --git a/src/intel/vulkan/anv_wsi_x11.c 
> > > b/src/intel/vulkan/anv_wsi_x11.c
> > > index 2feb5f13376..45c43f6f17f 100644
> > > --- a/src/intel/vulkan/anv_wsi_x11.c
> > > +++ b/src/intel/vulkan/anv_wsi_x11.c
> > > @@ -40,7 +40,6 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
> > > 
> > > return wsi_get_physical_device_xcb_presentation_support(
> > > >wsi_device,
> > > -  >instance->alloc,
> > > queueFamilyIndex,
> > > device->local_fd, false,
> > > connection, visual_id);
> > > @@ -56,7 +55,6 @@ VkBool32 
> > > anv_GetPhysicalDeviceXlibPresentationSupportKHR(
> > > 
> > > return wsi_get_physical_device_xcb_presentation_support(
> > > >wsi_device,
> > > -  >instance->alloc,
> > > queueFamilyIndex,
> > > device->local_fd, false,
> > > XGetXCBConnection(dpy), visualID);
> > > diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
> > > index 3416fef3076..1e3c4e0028b 100644
> > > --- a/src/vulkan/wsi/wsi_common.c
> > > +++ b/src/vulkan/wsi/wsi_common.c
> > > @@ -39,6 +39,7 @@ wsi_device_init(struct wsi_device *wsi,
> > > 
> > > memset(wsi, 0, sizeof(*wsi));
> > > 
> > > +   wsi->instance_alloc = *alloc;
> > > wsi->pdevice = pdevice;
> > > 
> > > #define WSI_GET_CB(func) \
> > > @@ -677,13 +678,12 @@ wsi_common_get_surface_support(struct
> > > wsi_device *wsi_device,
> > >int local_fd,
> > >uint32_t queueFamilyIndex,
> > >VkSurfaceKHR _surface,
> > > -   const VkAllocationCallbacks *alloc,
> > >VkBool32* pSupported)
> > > {
> > > ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
> > > struct wsi_interface *iface = wsi_device->wsi[surface->platform];
> > > 
> > > -   return iface->get_support(surface, wsi_device, alloc,
> > > +   return iface->get_support(surface, wsi_device,
> > >  queueFamilyIndex, local_fd, pSupported);
> > > }
> > > 
> > > diff --git 

[Mesa-dev] Ignore this series, was Re: [PATCH v2 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Ignore this series, there are regressions, at least 

  dEQP-GLES2.functional.texture.specification.
basic_copyteximage2d.2d_alpha

glCopyTexImage2D(srgb usage mismatch)

Best, 
Gert 

Am Donnerstag, den 18.10.2018, 10:46 +0200 schrieb Gert Wollny:
> From: Gert Wollny 
> 
> This is the updated version of the patches following Ilia's pointers,
> but also correcting some additional parts. 
> 
> Changes: 
> 
>  - core: Correct the extension table to list the extension as GLES
> only
>  - core: drop EXTRA_API_ES3, the requirements for get operations
> listed
>   here get OR-ed. (both Ilia Mirkin)
>  - gallium: always enable the extension when sRGB is supported (Ilia
> Mirkin).
>  - gallium: Correct handling by moving extension initialization to
> the
>  place where gallium/st actually takes care of this. This also
>  fixes properly disabling the extension via
> MESA_EXTENSION_OVERRIDE
>  - gallium: reinstate check for desktop GL and add check for the
> extension
>  when creating the framebuffer
>  - intel: Also text whether the extension is properly disabled by
>  MESA_EXTENSION_OVERRIDE 
> 
> best, 
> Gert
> 
> Gert Wollny (3):
>   mesa/core: Add support for EXT_sRGB_write_control
>   mesa/st: enable EXT_sRGB_write_control for drivers that support it
>   intel/i965: Enable extension EXT_sRGB_write_control
> 
>  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
>  src/mesa/main/enable.c   |  4 ++--
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/get.c  |  5 +
>  src/mesa/main/get_hash_params.py |  1 +
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/state_tracker/st_extensions.c   |  6 ++
>  src/mesa/state_tracker/st_manager.c  | 13 ++---
>  8 files changed, 23 insertions(+), 9 deletions(-)
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vulkan/wsi: Store the instance allocator in wsi_device

[Jason Ekstrand]

On October 18, 2018 05:40:14 Eric Engestrom  wrote:


On Wednesday, 2018-10-17 15:14:03 -0500, Jason Ekstrand wrote:

We already have wsi_device and we know the instance allocator at
wsi_device_init time so there's no need to pass it into the physical
device queries.  This also fixes a memory allocation domain bug that can
occur if CreateSwapchain gets called prior to any queries (not likely)
in which case the cached connection gets allocated off the device
instead of the instance.
---
src/amd/vulkan/radv_wsi.c   |  1 -
src/amd/vulkan/radv_wsi_x11.c   |  2 --
src/intel/vulkan/anv_wsi.c  |  1 -
src/intel/vulkan/anv_wsi_x11.c  |  2 --
src/vulkan/wsi/wsi_common.c |  4 ++--
src/vulkan/wsi/wsi_common.h |  4 +++-
src/vulkan/wsi/wsi_common_display.c |  1 -
src/vulkan/wsi/wsi_common_private.h |  1 -
src/vulkan/wsi/wsi_common_wayland.c |  1 -
src/vulkan/wsi/wsi_common_x11.c | 25 +++--
src/vulkan/wsi/wsi_common_x11.h |  1 -
11 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 6479bea070b..8b165ea3916 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -75,7 +75,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
   device->local_fd,
   queueFamilyIndex,
   surface,
->instance->alloc,
   pSupported);
}

diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
index c65ac938772..9ef02ccc435 100644
--- a/src/amd/vulkan/radv_wsi_x11.c
+++ b/src/amd/vulkan/radv_wsi_x11.c
@@ -44,7 +44,6 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(

return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, true,
connection, visual_id);
@@ -60,7 +59,6 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(

return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, true,
XGetXCBConnection(dpy), visualID);
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 5ed1d711689..1c9a54804e8 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -92,7 +92,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
 device->local_fd,
 queueFamilyIndex,
 surface,
- >instance->alloc,
 pSupported);
}

diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
index 2feb5f13376..45c43f6f17f 100644
--- a/src/intel/vulkan/anv_wsi_x11.c
+++ b/src/intel/vulkan/anv_wsi_x11.c
@@ -40,7 +40,6 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(

return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, false,
connection, visual_id);
@@ -56,7 +55,6 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(

return wsi_get_physical_device_xcb_presentation_support(
>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, false,
XGetXCBConnection(dpy), visualID);
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 3416fef3076..1e3c4e0028b 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -39,6 +39,7 @@ wsi_device_init(struct wsi_device *wsi,

memset(wsi, 0, sizeof(*wsi));

+   wsi->instance_alloc = *alloc;
wsi->pdevice = pdevice;

#define WSI_GET_CB(func) \
@@ -677,13 +678,12 @@ wsi_common_get_surface_support(struct wsi_device 
*wsi_device,

   int local_fd,
   uint32_t queueFamilyIndex,
   VkSurfaceKHR _surface,
-   const VkAllocationCallbacks *alloc,
   VkBool32* pSupported)
{
ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
struct wsi_interface *iface = wsi_device->wsi[surface->platform];

-   return iface->get_support(surface, wsi_device, alloc,
+   return iface->get_support(surface, wsi_device,
 queueFamilyIndex, local_fd, pSupported);
}

diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 14f65097bb3..424330de566 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -90,6 +90,9 @@ struct wsi_interface;
#define VK_ICD_WSI_PLATFORM_MAX (VK_ICD_WSI_PLATFORM_DISPLAY + 1)

struct wsi_device {
+   /* Allocator for the instance */
+   VkAllocationCallbacks instance_alloc;
+
VkPhysicalDevice pdevice;
VkPhysicalDeviceMemoryProperties memory_props;
uint32_t queue_family_count;
@@ -166,7 +169,6 @@ wsi_common_get_surface_support(struct wsi_device 
*wsi_device,

   int local_fd,
   uint32_t queueFamilyIndex,
   VkSurfaceKHR surface,
-   const VkAllocationCallbacks *alloc,

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

[Jose Fonseca]

I don't know what gles=y entails anymore, but if it's broken we should 
simply remove it.


That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile 
extension, even without gles=y option.


So what exactly are you looking for here?

Jose

On 18/10/18 13:02, Liviu Prodea wrote:

scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa

Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and 
object build\windows-x86\mesa\drivers\osmesa\osmesa.exp
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_nop_handler
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_new_nop_table
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_context
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Dispatch
build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: 
12 unresolved externals

scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error 
LNK1120: 6 unresolved externals

scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120
scons: building terminated because of errors.

This is a long standing issue. First reported here:

https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html 



Encountered again in 2016:

https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html 



and finally by myself in early 2018:

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



Eric Engestrom suggested me to try the work in progress Meson build for 
Windows. Unfortunately it has other issues which prevents it from being 
ready for prime time as I reported here:


https://gitlab.freedesktop.org/dbaker/mesa/issues/2 



I stumbled upon this issue when dealing with this feature request:

https://github.com/pal1000/mesa-dist-win/issues/8 



I was able to get that feature done but with a terribly ugly hack which 
should not even be mentioned.


This issue affects the linking between 

[Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

[Liviu Prodea]

scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and object 
build\windows-x86\mesa\drivers\osmesa\osmesa.exp
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
osmesa.obj : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_nop_handler
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_new_nop_table
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_context
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch
mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_Dispatch
build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: 12 
unresolved externals
scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120
st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_proc_address
mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_check_multithread
mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_dispatch
mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_set_context
mesa.lib(context.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_get_dispatch_table_size
mesa.lib(remap.obj) : error LNK2001: unresolved external symbol 
__imp___glapi_add_dispatch
build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error LNK1120: 6 
unresolved externals
scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120
scons: building terminated because of errors.
This is a long standing issue. First reported here:
https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html

Encountered again in 2016:
https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html
and finally by myself in early 2018:
https://bugs.freedesktop.org/show_bug.cgi?id=106843
Eric Engestrom suggested me to try the work in progress Meson build for 
Windows. Unfortunately it has other issues which prevents it from being ready 
for prime time as I reported here:
https://gitlab.freedesktop.org/dbaker/mesa/issues/2
I stumbled upon this issue when dealing with this feature request:
https://github.com/pal1000/mesa-dist-win/issues/8
I was able to get that feature done but with a terribly ugly hack which should 
not even be mentioned.

This issue affects the linking between osmesa and shared_glapi so the build 
command that triggers it can be as short as:
scons gles=y
or
scons gles=y osmesa
to get to the linking failure as quickly as possible stripping targets that 
build successfully.
I tried to make a proper fix but it is beyond my skill level, despite having 
the gut feeling the fix could be something surprisingly simple. 

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

Re: [Mesa-dev] [PATCH 1/2] vulkan/wsi: Store the instance allocator in wsi_device

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 17/10/2018 21:14, Jason Ekstrand wrote:

We already have wsi_device and we know the instance allocator at
wsi_device_init time so there's no need to pass it into the physical
device queries.  This also fixes a memory allocation domain bug that can
occur if CreateSwapchain gets called prior to any queries (not likely)
in which case the cached connection gets allocated off the device
instead of the instance.
---
  src/amd/vulkan/radv_wsi.c   |  1 -
  src/amd/vulkan/radv_wsi_x11.c   |  2 --
  src/intel/vulkan/anv_wsi.c  |  1 -
  src/intel/vulkan/anv_wsi_x11.c  |  2 --
  src/vulkan/wsi/wsi_common.c |  4 ++--
  src/vulkan/wsi/wsi_common.h |  4 +++-
  src/vulkan/wsi/wsi_common_display.c |  1 -
  src/vulkan/wsi/wsi_common_private.h |  1 -
  src/vulkan/wsi/wsi_common_wayland.c |  1 -
  src/vulkan/wsi/wsi_common_x11.c | 25 +++--
  src/vulkan/wsi/wsi_common_x11.h |  1 -
  11 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 6479bea070b..8b165ea3916 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -75,7 +75,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
  device->local_fd,
  queueFamilyIndex,
  surface,
- >instance->alloc,
  pSupported);
  }
  
diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c

index c65ac938772..9ef02ccc435 100644
--- a/src/amd/vulkan/radv_wsi_x11.c
+++ b/src/amd/vulkan/radv_wsi_x11.c
@@ -44,7 +44,6 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(
  
 return wsi_get_physical_device_xcb_presentation_support(

>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, true,
connection, visual_id);
@@ -60,7 +59,6 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(
  
 return wsi_get_physical_device_xcb_presentation_support(

>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, true,
XGetXCBConnection(dpy), visualID);
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 5ed1d711689..1c9a54804e8 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -92,7 +92,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
   device->local_fd,
   queueFamilyIndex,
   surface,
- >instance->alloc,
   pSupported);
  }
  
diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c

index 2feb5f13376..45c43f6f17f 100644
--- a/src/intel/vulkan/anv_wsi_x11.c
+++ b/src/intel/vulkan/anv_wsi_x11.c
@@ -40,7 +40,6 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
  
 return wsi_get_physical_device_xcb_presentation_support(

>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, false,
connection, visual_id);
@@ -56,7 +55,6 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(
  
 return wsi_get_physical_device_xcb_presentation_support(

>wsi_device,
-  >instance->alloc,
queueFamilyIndex,
device->local_fd, false,
XGetXCBConnection(dpy), visualID);
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 3416fef3076..1e3c4e0028b 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -39,6 +39,7 @@ wsi_device_init(struct wsi_device *wsi,
  
 memset(wsi, 0, sizeof(*wsi));
  
+   wsi->instance_alloc = *alloc;

 wsi->pdevice = pdevice;
  
  #define WSI_GET_CB(func) \

@@ -677,13 +678,12 @@ wsi_common_get_surface_support(struct wsi_device 
*wsi_device,
 int local_fd,
 uint32_t queueFamilyIndex,
 VkSurfaceKHR _surface,
-   const VkAllocationCallbacks *alloc,
 VkBool32* pSupported)
  {
 ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
 struct wsi_interface *iface = wsi_device->wsi[surface->platform];
  
-   return iface->get_support(surface, wsi_device, alloc,

+   return iface->get_support(surface, wsi_device,
   queueFamilyIndex, local_fd, pSupported);
  }
  
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h

index 14f65097bb3..424330de566 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -90,6 +90,9 @@ struct wsi_interface;
  #define VK_ICD_WSI_PLATFORM_MAX (VK_ICD_WSI_PLATFORM_DISPLAY + 1)
  
  

Re: [Mesa-dev] [PATCH 2/2] vulkan/wsi: Implement GetPhysicalDevicePresentRectanglesKHR

[Lionel Landwerlin]

Awesome!

Reviewed-by: Lionel Landwerlin 

On 17/10/2018 21:14, Jason Ekstrand wrote:

This got missed during 1.1 enabling because it was defined as an
interaction between device groups and WSI and it wasn't obvious it was
in the delta.

The idea behind it is that it's supposed to provide a hint to the
application in a multi-GPU setup to indicate which regions of the screen
are being scanned out by which GPU so a multi-device split-screen
rendering application can render each part of the screen on the GPU that
will be presenting it and avoid extra bus traffic between GPUs.  On a
single-GPU setup or one which doesn't support this present mode, we need
to do something.  We choose to return the window size (or a max-size
rect) if the compositor, X server, or crtc is associated with the given
physical device and zero rectangles otherwise.
---
  src/amd/vulkan/radv_wsi.c   | 14 +++
  src/intel/vulkan/anv_wsi.c  | 14 +++
  src/vulkan/wsi/wsi_common.c | 14 +++
  src/vulkan/wsi/wsi_common.h |  7 
  src/vulkan/wsi/wsi_common_display.c | 41 +++
  src/vulkan/wsi/wsi_common_private.h |  5 +++
  src/vulkan/wsi/wsi_common_wayland.c | 21 ++
  src/vulkan/wsi/wsi_common_x11.c | 61 +
  8 files changed, 177 insertions(+)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 8b165ea3916..43103a4ef85 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -284,3 +284,17 @@ VkResult radv_GetDeviceGroupSurfacePresentModesKHR(
  
 return VK_SUCCESS;

  }
+
+VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   uint32_t*   pRectCount,
+   VkRect2D*   pRects)
+{
+   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_present_rectangles(>wsi_device,
+device->local_fd,
+surface,
+pRectCount, pRects);
+}
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 1c9a54804e8..5d672c211c4 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -293,3 +293,17 @@ VkResult anv_GetDeviceGroupSurfacePresentModesKHR(
  
 return VK_SUCCESS;

  }
+
+VkResult anv_GetPhysicalDevicePresentRectanglesKHR(
+VkPhysicalDevicephysicalDevice,
+VkSurfaceKHRsurface,
+uint32_t*   pRectCount,
+VkRect2D*   pRects)
+{
+   ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_present_rectangles(>wsi_device,
+device->local_fd,
+surface,
+pRectCount, pRects);
+}
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 1e3c4e0028b..ad4b8c9075e 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -803,6 +803,20 @@ wsi_common_get_surface_present_modes(struct wsi_device 
*wsi_device,
 pPresentModes);
  }
  
+VkResult

+wsi_common_get_present_rectangles(struct wsi_device *wsi_device,
+  int local_fd,
+  VkSurfaceKHR _surface,
+  uint32_t* pRectCount,
+  VkRect2D* pRects)
+{
+   ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
+   struct wsi_interface *iface = wsi_device->wsi[surface->platform];
+
+   return iface->get_present_rectangles(surface, wsi_device, local_fd,
+pRectCount, pRects);
+}
+
  VkResult
  wsi_common_create_swapchain(struct wsi_device *wsi,
  VkDevice device,
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 424330de566..5b69c573d9e 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -199,6 +199,13 @@ wsi_common_get_surface_present_modes(struct wsi_device 
*wsi_device,
   uint32_t *pPresentModeCount,
   VkPresentModeKHR *pPresentModes);
  
+VkResult

+wsi_common_get_present_rectangles(struct wsi_device *wsi,
+  int local_fd,
+  VkSurfaceKHR surface,
+  uint32_t* pRectCount,
+  VkRect2D* pRects);
+
  VkResult
  wsi_common_get_surface_capabilities2ext(
 struct wsi_device *wsi_device,
diff --git a/src/vulkan/wsi/wsi_common_display.c 

Re: [Mesa-dev] [PATCH 02/15] meson: update required amdgpu version to 2.4.95

[Liu, Leo]

On 2018-10-17 3:03 p.m., boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
>
> VCN jpeg requires new hw ip

Patch 1 & 2 are:

Reviewed-by: Leo Liu 

>
> Signed-off-by: Boyuan Zhang 
> ---
>   meson.build | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 002ce35a60..35e3e934a3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1108,7 +1108,7 @@ dep_libdrm_etnaviv = null_dep
>   dep_libdrm_freedreno = null_dep
>   dep_libdrm_intel = null_dep
>   
> -_drm_amdgpu_ver = '2.4.93'
> +_drm_amdgpu_ver = '2.4.95'
>   _drm_radeon_ver = '2.4.71'
>   _drm_nouveau_ver = '2.4.66'
>   _drm_etnaviv_ver = '2.4.89'
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vulkan/wsi: Store the instance allocator in wsi_device

[Eric Engestrom]

On Wednesday, 2018-10-17 15:14:03 -0500, Jason Ekstrand wrote:
> We already have wsi_device and we know the instance allocator at
> wsi_device_init time so there's no need to pass it into the physical
> device queries.  This also fixes a memory allocation domain bug that can
> occur if CreateSwapchain gets called prior to any queries (not likely)
> in which case the cached connection gets allocated off the device
> instead of the instance.
> ---
>  src/amd/vulkan/radv_wsi.c   |  1 -
>  src/amd/vulkan/radv_wsi_x11.c   |  2 --
>  src/intel/vulkan/anv_wsi.c  |  1 -
>  src/intel/vulkan/anv_wsi_x11.c  |  2 --
>  src/vulkan/wsi/wsi_common.c |  4 ++--
>  src/vulkan/wsi/wsi_common.h |  4 +++-
>  src/vulkan/wsi/wsi_common_display.c |  1 -
>  src/vulkan/wsi/wsi_common_private.h |  1 -
>  src/vulkan/wsi/wsi_common_wayland.c |  1 -
>  src/vulkan/wsi/wsi_common_x11.c | 25 +++--
>  src/vulkan/wsi/wsi_common_x11.h |  1 -
>  11 files changed, 16 insertions(+), 27 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> index 6479bea070b..8b165ea3916 100644
> --- a/src/amd/vulkan/radv_wsi.c
> +++ b/src/amd/vulkan/radv_wsi.c
> @@ -75,7 +75,6 @@ VkResult radv_GetPhysicalDeviceSurfaceSupportKHR(
> device->local_fd,
> queueFamilyIndex,
> surface,
> -   >instance->alloc,
> pSupported);
>  }
>  
> diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
> index c65ac938772..9ef02ccc435 100644
> --- a/src/amd/vulkan/radv_wsi_x11.c
> +++ b/src/amd/vulkan/radv_wsi_x11.c
> @@ -44,7 +44,6 @@ VkBool32 radv_GetPhysicalDeviceXcbPresentationSupportKHR(
>  
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
> -  >instance->alloc,
>queueFamilyIndex,
>device->local_fd, true,
>connection, visual_id);
> @@ -60,7 +59,6 @@ VkBool32 radv_GetPhysicalDeviceXlibPresentationSupportKHR(
>  
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
> -  >instance->alloc,
>queueFamilyIndex,
>device->local_fd, true,
>XGetXCBConnection(dpy), visualID);
> diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
> index 5ed1d711689..1c9a54804e8 100644
> --- a/src/intel/vulkan/anv_wsi.c
> +++ b/src/intel/vulkan/anv_wsi.c
> @@ -92,7 +92,6 @@ VkResult anv_GetPhysicalDeviceSurfaceSupportKHR(
>   device->local_fd,
>   queueFamilyIndex,
>   surface,
> - >instance->alloc,
>   pSupported);
>  }
>  
> diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
> index 2feb5f13376..45c43f6f17f 100644
> --- a/src/intel/vulkan/anv_wsi_x11.c
> +++ b/src/intel/vulkan/anv_wsi_x11.c
> @@ -40,7 +40,6 @@ VkBool32 anv_GetPhysicalDeviceXcbPresentationSupportKHR(
>  
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
> -  >instance->alloc,
>queueFamilyIndex,
>device->local_fd, false,
>connection, visual_id);
> @@ -56,7 +55,6 @@ VkBool32 anv_GetPhysicalDeviceXlibPresentationSupportKHR(
>  
> return wsi_get_physical_device_xcb_presentation_support(
>>wsi_device,
> -  >instance->alloc,
>queueFamilyIndex,
>device->local_fd, false,
>XGetXCBConnection(dpy), visualID);
> diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
> index 3416fef3076..1e3c4e0028b 100644
> --- a/src/vulkan/wsi/wsi_common.c
> +++ b/src/vulkan/wsi/wsi_common.c
> @@ -39,6 +39,7 @@ wsi_device_init(struct wsi_device *wsi,
>  
> memset(wsi, 0, sizeof(*wsi));
>  
> +   wsi->instance_alloc = *alloc;
> wsi->pdevice = pdevice;
>  
>  #define WSI_GET_CB(func) \
> @@ -677,13 +678,12 @@ wsi_common_get_surface_support(struct wsi_device 
> *wsi_device,
> int local_fd,
> uint32_t queueFamilyIndex,
> VkSurfaceKHR _surface,
> -   const VkAllocationCallbacks *alloc,
> VkBool32* pSupported)
>  {
> ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
> struct wsi_interface *iface = wsi_device->wsi[surface->platform];
>  
> -   return iface->get_support(surface, wsi_device, alloc,
> +   return iface->get_support(surface, wsi_device,
>   queueFamilyIndex, local_fd, pSupported);
>  }
>  
> diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
> index 14f65097bb3..424330de566 100644
> --- a/src/vulkan/wsi/wsi_common.h
> +++ 

Re: [Mesa-dev] [PATCH 3/3] mesa: Add missed include guards

[Emil Velikov]

Hi Michał,

On Wed, 17 Oct 2018 at 07:42,  wrote:
>
> From: Michał Janiszewski 
>
> Signed-off-by: Michał Janiszewski 
> ---
>  src/compiler/glsl/ir_builder.h| 5 +
>  src/gallium/drivers/svga/include/svga3d_surfacedefs.h | 5 +
>  src/gallium/winsys/svga/drm/vmw_shader.h  | 1 +
>  src/glx/dri2_priv.h   | 5 +
>  src/glx/drisw_priv.h  | 5 +
>  src/glx/glx_error.h   | 6 ++
>  src/mesa/main/texcompress_bptc_tmp.h  | 5 +
>  src/mesa/main/texcompress_s3tc_tmp.h  | 5 +
>  src/mesa/state_tracker/st_glsl_to_tgsi.h  | 5 +
>  src/mesa/state_tracker/st_shader_cache.h  | 5 +
>  10 files changed, 47 insertions(+)
>
As the diff stat here suggests, the patch coverts multiple, separate
parts of Mesa.
Please split it up, something like 1) glsl 2) svga 3) glx 4) mesa.

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

Re: [Mesa-dev] [PATCH 1/3] gallium: Fix mismatched ifdef-guards

[Emil Velikov]

Hi Michał,

Welcome to Mesa :-)

On Wed, 17 Oct 2018 at 07:42,  wrote:
>
> From: Michał Janiszewski 
>
> Signed-off-by: Michał Janiszewski 
> ---
>  src/gallium/auxiliary/target-helpers/inline_debug_helper.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
This and 2/3 are
Reviewed-by: Emil Velikov 

I'll push them to master in a moment.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 1/1] swr/rast: ignore CreateElementUnorderedAtomicMemCpy

[Emil Velikov]

On Wed, 17 Oct 2018 at 21:43, Alok Hota  wrote:
>
> This function's API changed between LLVM 5 and 6. Compile errors occur
> when building with LLVM 6+ if LLVM 5 was used for a dist tarball
>
> CC: 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107865
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [PATCH v2 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Gert Wollny]

From: Gert Wollny 

With this patch the extension EXT_sRGB_write_control is enabled for
gallium drivers that support sRGB formats as render targets.

Tested (and pass) on r600 (evergreen) and softpipe:

  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*

with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for this), and

  
dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum

when extension is manually disabled via MESA_EXTENSION_OVERRIDE

v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
- Correct handling by moving extension initialization to the
  place where gallium/st actually takes care of this. This also
  fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
- reinstate check for desktop GL and add check for the extension
  when creating the framebuffer

Signed-off-by: Gert Wollny 
---
 src/mesa/state_tracker/st_extensions.c |  6 ++
 src/mesa/state_tracker/st_manager.c| 13 ++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 798ee60875..401609d728 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1169,6 +1169,12 @@ void st_init_extensions(struct pipe_screen *screen,
  void_formats, 32,
  PIPE_BIND_RENDER_TARGET);
 
+  extensions->EXT_sRGB_write_control =
+ screen->is_format_supported(screen, PIPE_FORMAT_R8G8B8A8_SRGB,
+ PIPE_TEXTURE_2D, 0, 0,
+ (PIPE_BIND_DISPLAY_TARGET |
+  PIPE_BIND_RENDER_TARGET));
+
   if (extensions->AMD_framebuffer_multisample_advanced) {
  /* AMD_framebuffer_multisample_advanced */
  /* This can be greater than storage samples. */
diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index ceb48dd490..fa12578031 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -457,14 +457,13 @@ st_framebuffer_create(struct st_context *st,
 * format such that util_format_srgb(visual->color_format) can be supported
 * by the pipe driver.  We still need to advertise the capability here.
 *
-* For GLES, however, sRGB framebuffer write is controlled only by the
-* capability of the framebuffer.  There is GL_EXT_sRGB_write_control to
-* give applications the control back, but sRGB write is still enabled by
-* default.  To avoid unexpected results, we should not advertise the
-* capability.  This could change when we add support for
-* EGL_KHR_gl_colorspace.
+* For GLES sRGB framebuffer write is initially only controlled by the 
+* framebuffer capability, with GL_EXT_sRGB_write_control control is given 
+* back to the applications, but sRGB write is still enabled by default.
 */
-   if (_mesa_is_desktop_gl(st->ctx)) {
+   if (_mesa_is_desktop_gl(st->ctx) ||
+   st->ctx->Extensions.EXT_sRGB_write_control)
+   {
   struct pipe_screen *screen = st->pipe->screen;
   const enum pipe_format srgb_format =
  util_format_srgb(stfbi->visual->color_format);
-- 
2.18.1

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

[Mesa-dev] [PATCH v2 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

This is the updated version of the patches following Ilia's pointers, but also 
correcting some additional parts. 

Changes: 

 - core: Correct the extension table to list the extension as GLES only
 - core: drop EXTRA_API_ES3, the requirements for get operations listed
  here get OR-ed. (both Ilia Mirkin)
 - gallium: always enable the extension when sRGB is supported (Ilia Mirkin).
 - gallium: Correct handling by moving extension initialization to the
 place where gallium/st actually takes care of this. This also
 fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
 - gallium: reinstate check for desktop GL and add check for the extension
 when creating the framebuffer
 - intel: Also text whether the extension is properly disabled by
 MESA_EXTENSION_OVERRIDE 

best, 
Gert

Gert Wollny (3):
  mesa/core: Add support for EXT_sRGB_write_control
  mesa/st: enable EXT_sRGB_write_control for drivers that support it
  intel/i965: Enable extension EXT_sRGB_write_control

 src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
 src/mesa/main/enable.c   |  4 ++--
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/get.c  |  5 +
 src/mesa/main/get_hash_params.py |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/state_tracker/st_extensions.c   |  6 ++
 src/mesa/state_tracker/st_manager.c  | 13 ++---
 8 files changed, 23 insertions(+), 9 deletions(-)

-- 
2.18.1

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

[Mesa-dev] [PATCH v2 3/3] intel/i965: Enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

Enables and passes on i965:
  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*, 

and still passes 
  
dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum
when extension is manually disabled via MESA_EXTENSION_OVERRIDE. 

Signed-off-by: Gert Wollny 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index d7e02efb54..ca921de8e8 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -76,6 +76,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_shading_language_packing = true;
ctx->Extensions.ARB_shadow = true;
ctx->Extensions.ARB_sync = true;
+   ctx->Extensions.EXT_sRGB_write_control = true;
ctx->Extensions.ARB_texture_border_clamp = true;
ctx->Extensions.ARB_texture_compression_rgtc = true;
ctx->Extensions.ARB_texture_cube_map = true;
-- 
2.18.1

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

[Mesa-dev] [PATCH v2 1/3] mesa/core: Add support for EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

This GLES extension gives the applications the control over deciding whether
the conversion from linear space to sRGB is necessary by enabling or
disabling this conversion at framebuffer write or blending time just
like it is possible for desktop GL.

Note, the extension could also be enabled for GLES 2.0 if EXT_sRGB were 
exposed somehow, but for now 3.0 is set as the minimum requirement.

v2: - Correct the extension table to list the extension as GLES only
- drop EXTRA_API_ES3, the requirements for get operations listed
  here get OR-ed. (both Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
 src/mesa/main/enable.c   | 4 ++--
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/get.c  | 5 +
 src/mesa/main/get_hash_params.py | 1 +
 src/mesa/main/mtypes.h   | 1 +
 5 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index bd3e493da5..06c5a0eb68 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -1125,7 +1125,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB, cap);
  _mesa_set_framebuffer_srgb(ctx, state);
@@ -1765,7 +1765,7 @@ _mesa_IsEnabled( GLenum cap )
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB);
  return ctx->Color.sRGBEnabled;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 09bf923bd0..8679ee2fc5 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -265,6 +265,7 @@ EXT(EXT_shader_integer_mix  , 
EXT_shader_integer_mix
 EXT(EXT_shader_io_blocks, dummy_true   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_shader_samples_identical, EXT_shader_samples_identical 
  , GLL, GLC,  x ,  31, 2015)
 EXT(EXT_shadow_funcs, ARB_shadow   
  , GLL,  x ,  x ,  x , 2002)
+EXT(EXT_sRGB_write_control  , EXT_sRGB_write_control   
  ,   x,  x ,  x ,  30, 2013)
 EXT(EXT_stencil_two_side, EXT_stencil_two_side 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_stencil_wrap, dummy_true   
  , GLL,  x ,  x ,  x , 2002)
 EXT(EXT_subtexture  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 1b1679e8bf..3a77bc6f8d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -394,6 +394,11 @@ static const int extra_ARB_compute_shader_es31[] = {
EXTRA_END
 };
 
+static const int extra_EXT_sRGB_write_control_es30[] = {
+   EXT(EXT_sRGB_write_control),
+   EXTRA_END
+};
+
 static const int extra_ARB_shader_storage_buffer_object_es31[] = {
EXT(ARB_shader_storage_buffer_object),
EXTRA_API_ES31,
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 1840db6ebb..822fab8151 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -262,6 +262,7 @@ descriptor=[
 # Enums in GLES2, GLES3
 { "apis": ["GLES2", "GLES3"], "params": [
   [ "GPU_DISJOINT_EXT", "LOC_CUSTOM, TYPE_INT, 0, 
extra_EXT_disjoint_timer_query" ],
+  [ "FRAMEBUFFER_SRGB_EXT", "CONTEXT_BOOL(Color.sRGBEnabled), 
extra_EXT_sRGB_write_control_es30" ],
 ]},
 
 { "apis": ["GL", "GL_CORE", "GLES2"], "params": [
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9ed49b7ff2..31cf62fdb6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4253,6 +4253,7 @@ struct gl_extensions
GLboolean EXT_semaphore_fd;
GLboolean EXT_shader_integer_mix;
GLboolean EXT_shader_samples_identical;
+   GLboolean EXT_sRGB_write_control;
GLboolean EXT_stencil_two_side;
GLboolean EXT_texture_array;
GLboolean EXT_texture_compression_latc;
-- 
2.18.1

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

Re: [Mesa-dev] [PATCH] intel/tools: Remove hardcoded PADDING_SIZE from sanitizer

[Danylo Piliaiev]

On Wed, Oct 17, 2018 at 6:47 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:

> On Wed, Oct 17, 2018 at 06:08:34PM +0300, Danylo Piliaiev wrote:
> > Signed-off-by: Danylo Piliaiev 
> > ---
> >  src/intel/tools/intel_sanitize_gpu.c | 38 +++-
> >  1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/src/intel/tools/intel_sanitize_gpu.c
> b/src/intel/tools/intel_sanitize_gpu.c
> > index 9b49b0bbf2..36c4725a2f 100644
> > --- a/src/intel/tools/intel_sanitize_gpu.c
> > +++ b/src/intel/tools/intel_sanitize_gpu.c
> > @@ -51,14 +51,6 @@ static int (*libc_fcntl)(int fd, int cmd, int param);
> >
> >  #define DRM_MAJOR 226
> >
> > -/* TODO: we want to make sure that the padding forces
> > - * the BO to take another page on the (PP)GTT; 4KB
> > - * may or may not be the page size for the BO. Indeed,
> > - * depending on GPU, kernel version and GEM size, the
> > - * page size can be one of 4KB, 64KB or 2M.
> > - */
> > -#define PADDING_SIZE 4096
> > -
> >  struct refcnt_hash_table {
> > struct hash_table *t;
> > int refcnt;
> > @@ -80,6 +72,8 @@ pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> >
> >  static struct hash_table *fds_to_bo_sizes = NULL;
> >
> > +static long padding_size = 0;
> > +
> >  static inline struct hash_table*
> >  bo_size_table(int fd)
> >  {
> > @@ -166,7 +160,7 @@ padding_is_good(int fd, uint32_t handle)
> > struct drm_i915_gem_mmap mmap_arg = {
> >.handle = handle,
> >.offset = bo_size(fd, handle),
> > -  .size = PADDING_SIZE,
> > +  .size = padding_size,
> >.flags = 0,
> > };
> >
> > @@ -189,17 +183,17 @@ padding_is_good(int fd, uint32_t handle)
> >  * if the bo is not cache coherent we likely need to
> >  * invalidate the cache lines to get it.
> >  */
> > -   gen_invalidate_range(mapped, PADDING_SIZE);
> > +   gen_invalidate_range(mapped, padding_size);
> >
> > expected_value = handle & 0xFF;
> > -   for (uint32_t i = 0; i < PADDING_SIZE; ++i) {
> > +   for (uint32_t i = 0; i < padding_size; ++i) {
> >if (expected_value != mapped[i]) {
> > - munmap(mapped, PADDING_SIZE);
> > + munmap(mapped, padding_size);
> >   return false;
> >}
> >expected_value = next_noise_value(expected_value);
> > }
> > -   munmap(mapped, PADDING_SIZE);
> > +   munmap(mapped, padding_size);
> >
> > return true;
> >  }
> > @@ -207,9 +201,9 @@ padding_is_good(int fd, uint32_t handle)
> >  static int
> >  create_with_padding(int fd, struct drm_i915_gem_create *create)
> >  {
> > -   create->size += PADDING_SIZE;
> > +   create->size += padding_size;
> > int ret = libc_ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, create);
> > -   create->size -= PADDING_SIZE;
> > +   create->size -= padding_size;
> >
> > if (ret != 0)
> >return ret;
> > @@ -218,7 +212,7 @@ create_with_padding(int fd, struct
> drm_i915_gem_create *create)
> > struct drm_i915_gem_mmap mmap_arg = {
> >.handle = create->handle,
> >.offset = create->size,
> > -  .size = PADDING_SIZE,
> > +  .size = padding_size,
> >.flags = 0,
> > };
> >
> > @@ -228,8 +222,8 @@ create_with_padding(int fd, struct
> drm_i915_gem_create *create)
> >
> > noise_values = (uint8_t*) (uintptr_t) mmap_arg.addr_ptr;
> > fill_noise_buffer(noise_values, create->handle & 0xFF,
> > - PADDING_SIZE);
> > -   munmap(noise_values, PADDING_SIZE);
> > + padding_size);
> > +   munmap(noise_values, padding_size);
> >
> > _mesa_hash_table_insert(bo_size_table(fd),
> (void*)(uintptr_t)create->handle,
> > (void*)(uintptr_t)create->size);
> > @@ -427,4 +421,12 @@ init(void)
> > libc_close = dlsym(RTLD_NEXT, "close");
> > libc_fcntl = dlsym(RTLD_NEXT, "fcntl");
> > libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
> > +
> > +   /* We want to make sure that the padding forces
> > +* the BO to take another page on the (PP)GTT.
> > +*/
> > +   padding_size = sysconf(_SC_PAGESIZE);
>
> I don't think this is the page size we want. This is the page size of
> CPU/system memory, which might be different from what the GPU is using
> to map pages. For instance, even if we are using 64K pages for GPU
> mapping, I think this call would still return 4K.
>
> Though I'm not sure if there's an interface to query the kernel which
> page size we are using for the GPU...
>
>
I looked a second time at the kernel code and indeed I somehow missed this,
The page size may be even different between allocation and easily different
from CPU page size. My patch makes no sense, sorry.


> > +   if (padding_size == -1) {
> > +  unreachable("Bad page size");
> > +   }
> >  }
> > --
> > 2.18.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___

[Mesa-dev] [Bug 108355] Civilization VI - Artifacts in mouse cursor

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
(In reply to Hadrien Nilsson from comment #7)
> amdgpu.dc=0 had no effect, but using xf86-video-amdgpu 18.1.0 indeed fixed
> the problem :) Thank you Michel.

Well, that's a surprising result though. Please attach a new Xorg log file from
xf86-video-amdgpu 18.1.0.


> I still do not know if the mouse cursor is displayed as intended (there is a
> shadow which seems to use additive blending instead of alpha blending) but
> at least there are no more artifacts.

For comparison, you can disable the HW cursor with

 Option "SWcursor"

in the /etc/X11/xorg.conf Section "Device".

-- 
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] [PATCH 2/4] radeonsi: use compute shaders for clear_buffer & copy_buffer

[Michel Dänzer]

On 2018-10-17 6:43 p.m., Marek Olšák wrote:
> Can you test the attached patch?

Doesn't help, unfortunately. Backtraces with the patch attached.

FWIW, this is on Bonaire.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
Thread 22 (Thread 0x7f2f6f7fe700 (LWP 7364)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1f2f0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e398d1f2a0, 
cond=0x55e398d1f2c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e398d1f2c8, mutex=0x55e398d1f2a0) at 
pthread_cond_wait.c:655
#3  0x7f2fbb69dcfa in cnd_wait (mtx=0x55e398d1f2a0, cond=0x55e398d1f2c8) at 
../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e398d227f0) at 
../../../src/util/u_queue.c:270
#5  0x7f2fbb69d8e8 in impl_thrd_routine (p=) at 
../../../include/c11/threads_posix.h:87
#6  0x7f2fbccfdf2a in start_thread (arg=0x7f2f6f7fe700) at 
pthread_create.c:463
#7  0x7f2fc1d79edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 21 (Thread 0x7f2f6700 (LWP 7363)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1f2f0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e398d1f2a0, 
cond=0x55e398d1f2c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e398d1f2c8, mutex=0x55e398d1f2a0) at 
pthread_cond_wait.c:655
#3  0x7f2fbb69dcfa in cnd_wait (mtx=0x55e398d1f2a0, cond=0x55e398d1f2c8) at 
../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e398d22640) at 
../../../src/util/u_queue.c:270
#5  0x7f2fbb69d8e8 in impl_thrd_routine (p=) at 
../../../include/c11/threads_posix.h:87
#6  0x7f2fbccfdf2a in start_thread (arg=0x7f2f6700) at 
pthread_create.c:463
#7  0x7f2fc1d79edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 20 (Thread 0x7f2f88ff9700 (LWP 7362)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1f2f0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e398d1f2a0, 
cond=0x55e398d1f2c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e398d1f2c8, mutex=0x55e398d1f2a0) at 
pthread_cond_wait.c:655
#3  0x7f2fbb69dcfa in cnd_wait (mtx=0x55e398d1f2a0, cond=0x55e398d1f2c8) at 
../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e398d22490) at 
../../../src/util/u_queue.c:270
#5  0x7f2fbb69d8e8 in impl_thrd_routine (p=) at 
../../../include/c11/threads_posix.h:87
#6  0x7f2fbccfdf2a in start_thread (arg=0x7f2f88ff9700) at 
pthread_create.c:463
#7  0x7f2fc1d79edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 19 (Thread 0x7f2f897fa700 (LWP 7361)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1f2f0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e398d1f2a0, 
cond=0x55e398d1f2c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e398d1f2c8, mutex=0x55e398d1f2a0) at 
pthread_cond_wait.c:655
#3  0x7f2fbb69dcfa in cnd_wait (mtx=0x55e398d1f2a0, cond=0x55e398d1f2c8) at 
../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e398d222e0) at 
../../../src/util/u_queue.c:270
#5  0x7f2fbb69d8e8 in impl_thrd_routine (p=) at 
../../../include/c11/threads_posix.h:87
#6  0x7f2fbccfdf2a in start_thread (arg=0x7f2f897fa700) at 
pthread_create.c:463
#7  0x7f2fc1d79edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 18 (Thread 0x7f2f89ffb700 (LWP 7360)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1f2f0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55e398d1f2a0, 
cond=0x55e398d1f2c8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55e398d1f2c8, mutex=0x55e398d1f2a0) at 
pthread_cond_wait.c:655
#3  0x7f2fbb69dcfa in cnd_wait (mtx=0x55e398d1f2a0, cond=0x55e398d1f2c8) at 
../../../include/c11/threads_posix.h:155
#4  util_queue_thread_func (input=input@entry=0x55e398d238c0) at 
../../../src/util/u_queue.c:270
#5  0x7f2fbb69d8e8 in impl_thrd_routine (p=) at 
../../../include/c11/threads_posix.h:87
#6  0x7f2fbccfdf2a in start_thread (arg=0x7f2f89ffb700) at 
pthread_create.c:463
#7  0x7f2fc1d79edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7f2f8a7fc700 (LWP 7359)):
#0  0x7f2fbcd03e6c in futex_wait_cancelable (private=, 
expected=0, futex_word=0x55e398d1ed70) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1