Re: [Mesa-dev] [PATCH 5/5] ac: use correct LLVM opcodes for ordered comparisons

2018-02-14 Thread Connor Abbott
On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri  wrote:
>
>
> On 15/02/18 04:39, Marek Olšák wrote:
>>
>> Reviewed-by: Marek Olšák 
>>
>> Marek
>>
>> On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri 
>> wrote:
>>>
>>> Fixes glsl-1.30/execution/isinf-and-isnan* piglit tests for
>>> radeonsi and should fix SPIRV errors when LLVM optimises away
>>> the workarounds in vtn_handle_alu() for handling ordered
>>> comparisons.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104905
>>> ---
>>>   src/amd/common/ac_nir_to_llvm.c | 8 
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>>> b/src/amd/common/ac_nir_to_llvm.c
>>> index a0c5680205..e81f86bb08 100644
>>> --- a/src/amd/common/ac_nir_to_llvm.c
>>> +++ b/src/amd/common/ac_nir_to_llvm.c
>>> @@ -1792,16 +1792,16 @@ static void visit_alu(struct ac_nir_context *ctx,
>>> const nir_alu_instr *instr)
>>>  result = emit_int_cmp(>ac, LLVMIntUGE, src[0],
>>> src[1]);
>>>  break;
>>>  case nir_op_feq:
>>> -   result = emit_float_cmp(>ac, LLVMRealUEQ, src[0],
>>> src[1]);
>>> +   result = emit_float_cmp(>ac, LLVMRealOEQ, src[0],
>>> src[1]);
>>>  break;
>>>  case nir_op_fne:
>>> -   result = emit_float_cmp(>ac, LLVMRealUNE, src[0],
>>> src[1]);
>>> +   result = emit_float_cmp(>ac, LLVMRealONE, src[0],
>>> src[1]);
>
>
> It seems we need to leave this one as is to avoid regressions. This is also
> what radeonsi does.

So, the thing you have to understand is that in LLVM unordered
comparisons are precisely the inverse of the ordered comparisons. That
is, (a <=(ordered) b) == !(a >(unordered b), (a ==(ordered) b) == !(a
!=(unordered) b), and  so on. C defines that all comparsions are
ordered except !=, so that (a == b) == !(a != b) always holds true.
Most hardware follows this convention -- offhand, x86 SSE is the only
ISA I know of with separate ordered and unordered comparisons, and
LLVM appears to have copied the distinction from them, but no one else
has both. I'm not even sure if it's in the IEEE spec. GLSL follows the
C convention, so glsl_to_nir just uses nir_op_fne to mean unordered
not-equal. spirv_to_nir generates some extra instructions, which then
get stripped away later... sigh.

I think the right way to untangle this mess is to define that the NIR
opcodes should always match the C convention. The separate ordered and
unordered opcodes are unnecesary, since one is just the logical
negation of the other, and LLVM was a little overzealous -- I'm sure
they would get rid of the distinction if they had the chance -- and
then they were blindly copied to SPIR-V. spirv_to_nir should just
negate the result if necessary rather than emitting the extra code to
handle NaN, and ac should use ordered except for not-equals.

>
>
>>>  break;
>>>  case nir_op_flt:
>>> -   result = emit_float_cmp(>ac, LLVMRealULT, src[0],
>>> src[1]);
>>> +   result = emit_float_cmp(>ac, LLVMRealOLT, src[0],
>>> src[1]);
>>>  break;
>>>  case nir_op_fge:
>>> -   result = emit_float_cmp(>ac, LLVMRealUGE, src[0],
>>> src[1]);
>>> +   result = emit_float_cmp(>ac, LLVMRealOGE, src[0],
>>> src[1]);
>>>  break;
>>>  case nir_op_ufeq:
>>>  result = emit_float_cmp(>ac, LLVMRealUEQ, src[0],
>>> src[1]);
>>> --
>>> 2.14.3
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 5/5] ac: use correct LLVM opcodes for ordered comparisons

2018-02-14 Thread Timothy Arceri



On 15/02/18 04:39, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri  wrote:

Fixes glsl-1.30/execution/isinf-and-isnan* piglit tests for
radeonsi and should fix SPIRV errors when LLVM optimises away
the workarounds in vtn_handle_alu() for handling ordered
comparisons.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104905
---
  src/amd/common/ac_nir_to_llvm.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index a0c5680205..e81f86bb08 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1792,16 +1792,16 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
 result = emit_int_cmp(>ac, LLVMIntUGE, src[0], src[1]);
 break;
 case nir_op_feq:
-   result = emit_float_cmp(>ac, LLVMRealUEQ, src[0], src[1]);
+   result = emit_float_cmp(>ac, LLVMRealOEQ, src[0], src[1]);
 break;
 case nir_op_fne:
-   result = emit_float_cmp(>ac, LLVMRealUNE, src[0], src[1]);
+   result = emit_float_cmp(>ac, LLVMRealONE, src[0], src[1]);


It seems we need to leave this one as is to avoid regressions. This is 
also what radeonsi does.



 break;
 case nir_op_flt:
-   result = emit_float_cmp(>ac, LLVMRealULT, src[0], src[1]);
+   result = emit_float_cmp(>ac, LLVMRealOLT, src[0], src[1]);
 break;
 case nir_op_fge:
-   result = emit_float_cmp(>ac, LLVMRealUGE, src[0], src[1]);
+   result = emit_float_cmp(>ac, LLVMRealOGE, src[0], src[1]);
 break;
 case nir_op_ufeq:
 result = emit_float_cmp(>ac, LLVMRealUEQ, src[0], src[1]);
--
2.14.3

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

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


[Mesa-dev] [PATCH] radeonsi/nir: set TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL correctly

2018-02-14 Thread Timothy Arceri
We set this for post_depth_coverage in addition to early_fragment_tests.
---

 This doesn't fix any piglit tests but it's what the glsl->tgsi state
 tracker does.

 src/gallium/drivers/radeonsi/si_shader_nir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 501e8bab03..8094f1f584 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -292,7 +292,8 @@ void si_nir_scan_shader(const struct nir_shader *nir,
}
 
if (nir->info.stage == MESA_SHADER_FRAGMENT) {
-   info->properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL] = 
nir->info.fs.early_fragment_tests;
+   info->properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL] =
+   nir->info.fs.early_fragment_tests | 
nir->info.fs.post_depth_coverage;
info->properties[TGSI_PROPERTY_FS_POST_DEPTH_COVERAGE] = 
nir->info.fs.post_depth_coverage;
 
if (nir->info.fs.depth_layout != FRAG_DEPTH_LAYOUT_NONE) {
-- 
2.14.3

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


[Mesa-dev] [PATCH] svga: call tgsi_scan_shader() for dummy shaders

2018-02-14 Thread Brian Paul
If we fail to compile the normal VS or FS we fall back to a simple/
dummy shader.  We need to rescan the the shader to update the shader
info.  Otherwise, this can lead to further translations failures
because the shader info doesn't match the actual shader.

Found by adding some extra debug assertions in the state-update code
while debugging something else.

v2: also update shader generic_inputs/outputs, etc. per Charmaine
---
 src/gallium/drivers/svga/svga_state_fs.c | 4 
 src/gallium/drivers/svga/svga_state_vs.c | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_state_fs.c 
b/src/gallium/drivers/svga/svga_state_fs.c
index 5e56899..eeb1ba6 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -115,6 +115,10 @@ get_compiled_dummy_shader(struct svga_context *svga,
FREE((void *) fs->base.tokens);
fs->base.tokens = dummy;
 
+   tgsi_scan_shader(fs->base.tokens, >base.info);
+   fs->generic_inputs = svga_get_generic_inputs_mask(>base.info);
+   svga_remap_generics(fs->generic_inputs, fs->generic_remap_table);
+
variant = translate_fragment_program(svga, fs, key);
return variant;
 }
diff --git a/src/gallium/drivers/svga/svga_state_vs.c 
b/src/gallium/drivers/svga/svga_state_vs.c
index a0ab868..3dfc9f4 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -105,6 +105,9 @@ get_compiled_dummy_vertex_shader(struct svga_context *svga,
FREE((void *) vs->base.tokens);
vs->base.tokens = dummy;
 
+   tgsi_scan_shader(vs->base.tokens, >base.info);
+   vs->generic_outputs = svga_get_generic_outputs_mask(>base.info);
+
variant = translate_vertex_program(svga, vs, key);
return variant;
 }
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH 1/3] svga: call tgsi_scan_shader() for dummy shaders

2018-02-14 Thread Brian Paul

On 02/14/2018 03:46 PM, Charmaine Lee wrote:



From: Brian Paul 
Sent: Wednesday, February 14, 2018 1:15 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH 1/3] svga: call tgsi_scan_shader() for dummy shaders



If we fail to compile the normal VS or FS we fall back to a simple/
dummy shader.  We need to rescan the the shader to update the shader
info.  Otherwise, this can lead to further translations failures
because the shader info doesn't match the actual shader.

Found by adding some extra debug assertions in the state-update code
while debugging something else.
---
src/gallium/drivers/svga/svga_state_fs.c | 2 ++
src/gallium/drivers/svga/svga_state_vs.c | 2 ++
2 files changed, 4 insertions(+)



diff --git a/src/gallium/drivers/svga/svga_state_fs.c 
b/src/gallium/drivers/svga/svga_state_fs.c
index 5e56899..f185a68 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -115,6 +115,8 @@ get_compiled_dummy_shader(struct svga_context *svga,
FREE((void *) fs->base.tokens);
fs->base.tokens = dummy;



+   tgsi_scan_shader(fs->base.tokens, >base.info);
+


To be complete, we need to get the generic_inputs mask and call 
svga_remap_generics again.


Will do, though, these dummy shaders have no generic inputs/outputs.

v2 coming...

-Brian






variant = translate_fragment_program(svga, fs, key);
return variant;
}
diff --git a/src/gallium/drivers/svga/svga_state_vs.c 
b/src/gallium/drivers/svga/svga_state_vs.c
index a0ab868..1dcc161 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -105,6 +105,8 @@ get_compiled_dummy_vertex_shader(struct svga_context *svga,
FREE((void *) vs->base.tokens);
vs->base.tokens = dummy;



+   tgsi_scan_shader(vs->base.tokens, >base.info);
+

Need to set the generic_outputs mask again.



variant = translate_vertex_program(svga, vs, key);
return variant;



-Charmaine



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


Re: [Mesa-dev] [PATCH 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)

2018-02-14 Thread Dieter Nützel

For the series:

Tested-by: Dieter Nützel 

on RX580 with SPECviewperf from the phoronix test suite. ;-)

Viewset Composite   Mulitsample Performance
3dsmax-0411.97  no result
catia-02 9.19   no result
ensight-03   not Successful
maya-02  41.69  no result
proe-04  6.82   no result
sw-0115.09  no result
tcvis-01 5.13   no result
ugnx-01  13.66  no result

Are these numbers 'right'?
Any other (special) tests wanted?

Cheers,
Dieter

Am 15.02.2018 01:11, schrieb Marek Olšák:

Hi,

This is the second version of GL 3.1 compatibility support patches.
There is also ARB_enhanced_layouts for the compatibility context and
other related changes.

Please review.

Thanks,
Marek
___
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 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)

2018-02-14 Thread Marek Olšák
i965 doesn't report GL 3.1 because it doesn't expose TBOs in the
default GL profile.

Marek

On Thu, Feb 15, 2018 at 2:49 AM, Mike Lothian  wrote:
> On 15 February 2018 at 00:11, Marek Olšák  wrote:
>> Hi,
>>
>> This is the second version of GL 3.1 compatibility support patches.
>> There is also ARB_enhanced_layouts for the compatibility context and
>> other related changes.
>>
>> Please review.
>>
>> Thanks,
>> Marek
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> So I've done my best to test this. These are the diffs between the
> glxinfo reports before and after on radeonsi and i965
>
>
> fireburn@axion ~ $ diff -u glxinfo.amdgpu.core glxinfo.amdgpu.compat
> --- glxinfo.amdgpu.core 2018-02-15 01:05:48.081778762 +
> +++ glxinfo.amdgpu.compat   2018-02-15 01:39:04.727660602 +
> @@ -105,7 +105,7 @@
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 4.5
> -Max compat profile version: 3.0
> +Max compat profile version: 3.1
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.1
> Memory info (GL_ATI_meminfo):
> @@ -121,7 +121,7 @@
> Currently available dedicated video memory: 4089 MB
> OpenGL vendor string: X.Org
> OpenGL renderer string: AMD Radeon R9 M295X (TONGA / DRM 3.25.0 /
> 4.15.0-rc8-agd5f+, LLVM 7.0.0)
> -OpenGL core profile version string: 4.5 (Core Profile) Mesa
> 18.1.0-devel (git-0cd37f9178)
> +OpenGL core profile version string: 4.5 (Core Profile) Mesa
> 18.1.0-devel (git-c6694793e1)
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> @@ -325,8 +325,8 @@
> GL_S3_s3tc
>
>
> -OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
> -OpenGL shading language version string: 1.30
> +OpenGL version string: 3.1 Mesa 18.1.0-devel (git-c6694793e1)
> +OpenGL shading language version string: 1.40
> OpenGL context flags: (none)
> OpenGL extensions:
> GL_AMD_conservative_depth
> @@ -350,6 +350,7 @@
> GL_ARB_clear_texture
> GL_ARB_clip_control
> GL_ARB_color_buffer_float
> +GL_ARB_compatibility
> GL_ARB_compressed_texture_pixel_storage
> GL_ARB_compute_shader
> GL_ARB_compute_variable_group_size
> @@ -367,6 +368,7 @@
> GL_ARB_draw_buffers_blend
> GL_ARB_draw_elements_base_vertex
> GL_ARB_draw_instanced
> +GL_ARB_enhanced_layouts
> GL_ARB_explicit_attrib_location
> GL_ARB_explicit_uniform_location
> GL_ARB_fragment_coord_conventions
> @@ -588,7 +590,7 @@
> GL_SUN_multi_draw_arrays
>
>
> -OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
> (git-0cd37f9178)
> +OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
> (git-c6694793e1)
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
> OpenGL ES profile extensions:
> GL_ANGLE_texture_compression_dxt3
> fireburn@axion ~ $ diff -u glxinfo.intel.core glxinfo.intel.compat
> --- glxinfo.intel.core  2018-02-15 01:05:53.581770479 +
> +++ glxinfo.intel.compat2018-02-15 01:38:54.077684665 +
> @@ -111,7 +111,7 @@
> Max GLES[23] profile version: 3.2
> OpenGL vendor string: Intel Open Source Technology Center
> OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
> -OpenGL core profile version string: 4.5 (Core Profile) Mesa
> 18.1.0-devel (git-0cd37f9178)
> +OpenGL core profile version string: 4.5 (Core Profile) Mesa
> 18.1.0-devel (git-c6694793e1)
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> @@ -309,8 +309,8 @@
> GL_S3_s3tc
>
>
> -OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
> -OpenGL shading language version string: 1.30
> +OpenGL version string: 3.0 Mesa 18.1.0-devel (git-c6694793e1)
> +OpenGL shading language version string: 1.40
> OpenGL context flags: (none)
> OpenGL extensions:
> GL_3DFX_texture_compression_FXT1
> @@ -557,7 +557,7 @@
> GL_SUN_multi_draw_arrays
>
>
> -OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
> (git-0cd37f9178)
> +OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
> (git-c6694793e1)
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
> OpenGL ES profile extensions:
> GL_ANDROID_extension_pack_es31a
>
> I'm not aware of anything that uses OpenGL 3.1 Compat or the
> ARB_compatability extension, but if you know of anything I'll test it
> directly
>
> Should i965 show the extra extensions or a higher compat version as
> well as the bump to the GLSL version?
>
> My games continue to work after this change is applied
>
> Tested-by: Mike Lothian 
___
mesa-dev mailing list

Re: [Mesa-dev] [Clover] compilation error (WriteBitcodeToFile) with latest LLVM git version

2018-02-14 Thread Jan Vesely
On Thu, 2018-02-15 at 01:18 +0100, Dieter Nützel wrote:
> Hello Jan,
> 
> new compilation error with latest LLVM git (7.0.0).
> Without --enable-opencl build is fine.
> 
> make[4]: Verzeichnis „/opt/mesa/src/gallium/state_trackers/clover“ wird 
> betreten
>CXX  llvm/codegen/libclllvm_la-bitcode.lo
> llvm/codegen/bitcode.cpp: In function ‘std::vector 
> {anonymous}::emit_code(const llvm::Module&)’:
> llvm/codegen/bitcode.cpp:69:26: error: invalid initialization of 
> reference of type ‘const llvm::Module&’ from expression of type ‘const 
> llvm::Module*’
> WriteBitcodeToFile(, os);
>^~~~
> In file included from llvm/codegen/bitcode.cpp:45:0:
> /usr/local/include/llvm/Bitcode/BitcodeWriter.h:129:8: note: in passing 
> argument 1 of ‘void llvm::WriteBitcodeToFile(const llvm::Module&, 
> llvm::raw_ostream&, bool, const llvm::ModuleSummaryIndex*, bool, 
> llvm::ModuleHash*)’
> void WriteBitcodeToFile(const Module , raw_ostream ,
>  ^~
> llvm/codegen/bitcode.cpp: At global scope:
> llvm/codegen/bitcode.cpp:54:4: warning: 
> ‘std::map 
> {anonymous}::get_symbol_offsets(const llvm::Module&)’ defined but not 
> used [-Wunused-function]
>  get_symbol_offsets(const ::llvm::Module ) {
>  ^~
> make[4]: *** [Makefile:913: llvm/codegen/libclllvm_la-bitcode.lo] Fehler 
> 1
> make[4]: Verzeichnis „/opt/mesa/src/gallium/state_trackers/clover“ wird 
> verlassen
> make[3]: *** [Makefile:611: all-recursive] Fehler 1
> make[3]: Verzeichnis „/opt/mesa/src/gallium“ wird verlassen
> make[2]: *** [Makefile:862: all-recursive] Fehler 1
> make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
> make[1]: *** [Makefile:653: all] Fehler 2
> make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
> make: *** [Makefile:666: all-recursive] Fehler 1
> 6.692u 0.608s 0:07.19 101.3%0+0k 0+8io 0pf+0w

looks like fallout from llvm r325155.
I'll take stab at fixing it tomorrow unless someone beats me to it.

Jan

> 
> Thanks,
> Dieter

-- 
Jan Vesely 

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] nir: add is_used_once for fmul(fexp2(a), fexp2(b)) to fexp2(fadd(a, b))

2018-02-14 Thread Ian Romanick
On 02/14/2018 05:36 PM, Ian Romanick wrote:
> Do you have shader-db results?  Did you try having only one is_used_once?

I think you sent out a hastebin link with results before, but it's not
loading now.

> On 02/05/2018 07:07 AM, Samuel Pitoiset wrote:
>> Otherwise the code size increases because the original fexp2()
>> instructions can't be deleted.
>>
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>  src/compiler/nir/nir_opt_algebraic.py | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
>> b/src/compiler/nir/nir_opt_algebraic.py
>> index b30d1df199..d40d59b5cd 100644
>> --- a/src/compiler/nir/nir_opt_algebraic.py
>> +++ b/src/compiler/nir/nir_opt_algebraic.py
>> @@ -336,7 +336,7 @@ optimizations = [
>> (('~flog2', ('frcp', a)), ('fneg', ('flog2', a))),
>> (('~flog2', ('frsq', a)), ('fmul', -0.5, ('flog2', a))),
>> (('~flog2', ('fpow', a, b)), ('fmul', b, ('flog2', a))),
>> -   (('~fmul', ('fexp2', a), ('fexp2', b)), ('fexp2', ('fadd', a, b))),
>> +   (('~fmul', ('fexp2(is_used_once)', a), ('fexp2(is_used_once)', b)), 
>> ('fexp2', ('fadd', a, b))),
>> # Division and reciprocal
>> (('~fdiv', 1.0, a), ('frcp', a)),
>> (('fdiv', a, b), ('fmul', a, ('frcp', b)), 'options->lower_fdiv'),
>>
> 
> ___
> 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 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)

2018-02-14 Thread Mike Lothian
On 15 February 2018 at 00:11, Marek Olšák  wrote:
> Hi,
>
> This is the second version of GL 3.1 compatibility support patches.
> There is also ARB_enhanced_layouts for the compatibility context and
> other related changes.
>
> Please review.
>
> Thanks,
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

So I've done my best to test this. These are the diffs between the
glxinfo reports before and after on radeonsi and i965


fireburn@axion ~ $ diff -u glxinfo.amdgpu.core glxinfo.amdgpu.compat
--- glxinfo.amdgpu.core 2018-02-15 01:05:48.081778762 +
+++ glxinfo.amdgpu.compat   2018-02-15 01:39:04.727660602 +
@@ -105,7 +105,7 @@
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
-Max compat profile version: 3.0
+Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
Memory info (GL_ATI_meminfo):
@@ -121,7 +121,7 @@
Currently available dedicated video memory: 4089 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R9 M295X (TONGA / DRM 3.25.0 /
4.15.0-rc8-agd5f+, LLVM 7.0.0)
-OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-0cd37f9178)
+OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-c6694793e1)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
@@ -325,8 +325,8 @@
GL_S3_s3tc


-OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
-OpenGL shading language version string: 1.30
+OpenGL version string: 3.1 Mesa 18.1.0-devel (git-c6694793e1)
+OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
GL_AMD_conservative_depth
@@ -350,6 +350,7 @@
GL_ARB_clear_texture
GL_ARB_clip_control
GL_ARB_color_buffer_float
+GL_ARB_compatibility
GL_ARB_compressed_texture_pixel_storage
GL_ARB_compute_shader
GL_ARB_compute_variable_group_size
@@ -367,6 +368,7 @@
GL_ARB_draw_buffers_blend
GL_ARB_draw_elements_base_vertex
GL_ARB_draw_instanced
+GL_ARB_enhanced_layouts
GL_ARB_explicit_attrib_location
GL_ARB_explicit_uniform_location
GL_ARB_fragment_coord_conventions
@@ -588,7 +590,7 @@
GL_SUN_multi_draw_arrays


-OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
(git-0cd37f9178)
+OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
(git-c6694793e1)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
GL_ANGLE_texture_compression_dxt3
fireburn@axion ~ $ diff -u glxinfo.intel.core glxinfo.intel.compat
--- glxinfo.intel.core  2018-02-15 01:05:53.581770479 +
+++ glxinfo.intel.compat2018-02-15 01:38:54.077684665 +
@@ -111,7 +111,7 @@
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
-OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-0cd37f9178)
+OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-c6694793e1)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
@@ -309,8 +309,8 @@
GL_S3_s3tc


-OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
-OpenGL shading language version string: 1.30
+OpenGL version string: 3.0 Mesa 18.1.0-devel (git-c6694793e1)
+OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
GL_3DFX_texture_compression_FXT1
@@ -557,7 +557,7 @@
GL_SUN_multi_draw_arrays


-OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
(git-0cd37f9178)
+OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
(git-c6694793e1)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
GL_ANDROID_extension_pack_es31a

I'm not aware of anything that uses OpenGL 3.1 Compat or the
ARB_compatability extension, but if you know of anything I'll test it
directly

Should i965 show the extra extensions or a higher compat version as
well as the bump to the GLSL version?

My games continue to work after this change is applied

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


Re: [Mesa-dev] [PATCH 08/17] loader: Fix compiler warnings about truncating the PCI ID path.

2018-02-14 Thread Ian Romanick
On 02/13/2018 02:31 AM, Eric Anholt wrote:
> Ian Romanick  writes:
> 
>> On 02/10/2018 08:33 AM, Eric Anholt wrote:
>>> My build was producing:
>>>
>>> ../src/loader/loader.c:121:67: warning: ‘%1u’ directive output may be 
>>> truncated writing between 1 and 3 bytes into a region of size 2 
>>> [-Wformat-truncation=]
>>>
>>> and we can avoid this careful calculation by just using asprintf (as we do
>>> elsewhere in the file).
>>>
>>> Cc: Eric Engestrom 
>>> ---
>>>  src/loader/loader.c | 15 +++
>>>  1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>>> index 913b3dcac032..92b4c5204b19 100644
>>> --- a/src/loader/loader.c
>>> +++ b/src/loader/loader.c
>>> @@ -110,17 +110,16 @@ static char *loader_get_dri_config_device_id(void)
>>>  
>>>  static char *drm_construct_id_path_tag(drmDevicePtr device)
>>>  {
>>> -#define PCI_ID_PATH_TAG_LENGTH sizeof("pci-_xx_xx_x")
>>> char *tag = NULL;
>>>  
>>> if (device->bustype == DRM_BUS_PCI) {
>>> -tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
>>> -if (tag == NULL)
>>> -return NULL;
>>> -
>>> -snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
>>> - device->businfo.pci->domain, device->businfo.pci->bus,
>>> - device->businfo.pci->dev, device->businfo.pci->func);
>>> +  if (asprintf(, "pci-%04x_%02x_%02x_%1u",
>>> +   device->businfo.pci->domain,
>>> +   device->businfo.pci->bus,
>>> +   device->businfo.pci->dev,
>>> +   device->businfo.pci->func) < 0) {
>>> + return NULL;
>>
>> Won't tag be NULL on failure?  Then you could just
>>
>>   asprintf(, "pci-%04x_%02x_%02x_%1u",
>>device->businfo.pci->domain,
>>device->businfo.pci->bus,
>>device->businfo.pci->dev,
>>device->businfo.pci->func);
>>   return tag;
> 
> "If memory allocation wasn't possible, or some other error occurs, these
> functions will return -1, and the contents of strp are undefined."

Boo.

Reviewed-by: Ian Romanick 





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


[Mesa-dev] [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

2018-02-14 Thread Rodrigo Vivi
Let's sync CNL ids with Spec and kernel.

Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
Add Cannonlake PCI IDs for another SKU.")' and
commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'

Cc: James Ausmus 
Cc: Lucas De Marchi 
Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
---
 intel/intel_chipset.h | 52 +++
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 3818e71e..01d250e8 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -241,16 +241,20 @@
 #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
 #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
 
-#define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52
-#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
-#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
-#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
-#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
-#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
-#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
-#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
-#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
-#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
+#define PCI_CHIP_CANNONLAKE_0  0x5A51
+#define PCI_CHIP_CANNONLAKE_1  0x5A59
+#define PCI_CHIP_CANNONLAKE_2  0x5A41
+#define PCI_CHIP_CANNONLAKE_3  0x5A49
+#define PCI_CHIP_CANNONLAKE_4  0x5A52
+#define PCI_CHIP_CANNONLAKE_5  0x5A5A
+#define PCI_CHIP_CANNONLAKE_6  0x5A42
+#define PCI_CHIP_CANNONLAKE_7  0x5A4A
+#define PCI_CHIP_CANNONLAKE_8  0x5A50
+#define PCI_CHIP_CANNONLAKE_9  0x5A40
+#define PCI_CHIP_CANNONLAKE_10 0x5A54
+#define PCI_CHIP_CANNONLAKE_11 0x5A5C
+#define PCI_CHIP_CANNONLAKE_12 0x5A44
+#define PCI_CHIP_CANNONLAKE_13 0x5A4C
 
 #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
@@ -515,20 +519,20 @@
 IS_GEMINILAKE(devid) || \
 IS_COFFEELAKE(devid))
 
-#define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
|| \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
-(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
-
-#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
|| \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
-
-#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid) || \
-IS_CNL_Y(devid))
+#define IS_CANNONLAKE(devid)   ((devid) == PCI_CHIP_CANNONLAKE_0 || \
+(devid) == PCI_CHIP_CANNONLAKE_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_3 || \
+(devid) == PCI_CHIP_CANNONLAKE_4 || \
+(devid) == PCI_CHIP_CANNONLAKE_5 || \
+(devid) == PCI_CHIP_CANNONLAKE_6 || \
+(devid) == PCI_CHIP_CANNONLAKE_7 || \
+(devid) == PCI_CHIP_CANNONLAKE_8 || \
+(devid) == PCI_CHIP_CANNONLAKE_9 || \
+(devid) == PCI_CHIP_CANNONLAKE_10 || \
+(devid) == PCI_CHIP_CANNONLAKE_11 || \
+(devid) == PCI_CHIP_CANNONLAKE_12 || \
+(devid) == PCI_CHIP_CANNONLAKE_13)
 
 #define IS_GEN10(devid)(IS_CANNONLAKE(devid))
 
-- 
2.13.6

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


Re: [Mesa-dev] [PATCH] nir: add is_used_once for fmul(fexp2(a), fexp2(b)) to fexp2(fadd(a, b))

2018-02-14 Thread Ian Romanick
Do you have shader-db results?  Did you try having only one is_used_once?

On 02/05/2018 07:07 AM, Samuel Pitoiset wrote:
> Otherwise the code size increases because the original fexp2()
> instructions can't be deleted.
> 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
> b/src/compiler/nir/nir_opt_algebraic.py
> index b30d1df199..d40d59b5cd 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -336,7 +336,7 @@ optimizations = [
> (('~flog2', ('frcp', a)), ('fneg', ('flog2', a))),
> (('~flog2', ('frsq', a)), ('fmul', -0.5, ('flog2', a))),
> (('~flog2', ('fpow', a, b)), ('fmul', b, ('flog2', a))),
> -   (('~fmul', ('fexp2', a), ('fexp2', b)), ('fexp2', ('fadd', a, b))),
> +   (('~fmul', ('fexp2(is_used_once)', a), ('fexp2(is_used_once)', b)), 
> ('fexp2', ('fadd', a, b))),
> # Division and reciprocal
> (('~fdiv', 1.0, a), ('frcp', a)),
> (('fdiv', a, b), ('fmul', a, ('frcp', b)), 'options->lower_fdiv'),
> 

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


Re: [Mesa-dev] [PATCH] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread Marek Olšák
Pushed, thanks!

Marek

On Thu, Feb 15, 2018 at 1:12 AM, Gurchetan Singh
 wrote:
> On Wed, Feb 14, 2018 at 3:57 PM, Marek Olšák  wrote:
>> Do you have commit access?
>
> No, would appreciate a merge ;-)
>
>> Marek
>>
>> On Thu, Feb 15, 2018 at 12:40 AM, gurchetansi...@chromium.org
>>  wrote:
>>> From: Gurchetan Singh 
>>>
>>> The ARB_viewport_array spec says:
>>>
>>> "Dependencies
>>> OpenGL 1.0 is required.
>>>
>>> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 
>>> extensions
>>> are required.
>>>
>>> This extension is written against the OpenGL 3.2 (Compatibility)
>>> Specification."
>>>
>>> As such, we should ignore it for GLES2 contexts.
>>>
>>> Fixes:
>>> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
>>> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>>>
>>> on llvmpipe and virgl.
>>>
>>> v2: Use _mesa_has_* (Ilia)
>>> ---
>>>  src/mesa/main/viewport.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
>>> index fc384909e6..398cc63685 100644
>>> --- a/src/mesa/main/viewport.c
>>> +++ b/src/mesa/main/viewport.c
>>> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, 
>>> GLfloat *y,
>>>  * determined by calling GetFloatv with the symbolic constant
>>>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>>>  */
>>> -   if (ctx->Extensions.ARB_viewport_array ||
>>> -   (ctx->Extensions.OES_viewport_array &&
>>> -_mesa_is_gles31(ctx))) {
>>> +   if (_mesa_has_ARB_viewport_array(ctx) ||
>>> +   _mesa_has_OES_viewport_array(ctx)) {
>>>*x = CLAMP(*x,
>>>   ctx->Const.ViewportBounds.Min, 
>>> ctx->Const.ViewportBounds.Max);
>>>*y = CLAMP(*y,
>>> --
>>> 2.13.5
>>>
>>> ___
>>> 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] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105098

--- Comment #4 from Lukas Kahnert  ---
I use a Vega64 Liquid Edition

I found out that if you change fragColor or outColor in the shader source to a
fixed value the issue is not triggered(it doesn't freeze immediately). Maybe
the bug is hidden in the gl_VertexIndex variable or the color array itself.

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


[Mesa-dev] [Clover] compilation error (WriteBitcodeToFile) with latest LLVM git version

2018-02-14 Thread Dieter Nützel

Hello Jan,

new compilation error with latest LLVM git (7.0.0).
Without --enable-opencl build is fine.

make[4]: Verzeichnis „/opt/mesa/src/gallium/state_trackers/clover“ wird 
betreten

  CXX  llvm/codegen/libclllvm_la-bitcode.lo
llvm/codegen/bitcode.cpp: In function ‘std::vector 
{anonymous}::emit_code(const llvm::Module&)’:
llvm/codegen/bitcode.cpp:69:26: error: invalid initialization of 
reference of type ‘const llvm::Module&’ from expression of type ‘const 
llvm::Module*’

   WriteBitcodeToFile(, os);
  ^~~~
In file included from llvm/codegen/bitcode.cpp:45:0:
/usr/local/include/llvm/Bitcode/BitcodeWriter.h:129:8: note: in passing 
argument 1 of ‘void llvm::WriteBitcodeToFile(const llvm::Module&, 
llvm::raw_ostream&, bool, const llvm::ModuleSummaryIndex*, bool, 
llvm::ModuleHash*)’

   void WriteBitcodeToFile(const Module , raw_ostream ,
^~
llvm/codegen/bitcode.cpp: At global scope:
llvm/codegen/bitcode.cpp:54:4: warning: 
‘std::map 
{anonymous}::get_symbol_offsets(const llvm::Module&)’ defined but not 
used [-Wunused-function]

get_symbol_offsets(const ::llvm::Module ) {
^~
make[4]: *** [Makefile:913: llvm/codegen/libclllvm_la-bitcode.lo] Fehler 
1
make[4]: Verzeichnis „/opt/mesa/src/gallium/state_trackers/clover“ wird 
verlassen

make[3]: *** [Makefile:611: all-recursive] Fehler 1
make[3]: Verzeichnis „/opt/mesa/src/gallium“ wird verlassen
make[2]: *** [Makefile:862: all-recursive] Fehler 1
make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
make[1]: *** [Makefile:653: all] Fehler 2
make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
make: *** [Makefile:666: all-recursive] Fehler 1
6.692u 0.608s 0:07.19 101.3%0+0k 0+8io 0pf+0w

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


[Mesa-dev] [Bug 105105] Suffixless KHR_robustness functions aren't exposed in ES 3.2

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105105

Bug ID: 105105
   Summary: Suffixless KHR_robustness functions aren't exposed in
ES 3.2
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: kenn...@whitecape.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: i...@freedesktop.org

These two tests fail on i965:

   KHR-NoContext.es32.robustness.readnpixels
   KHR-NoContext.es32.robustness.getnuniform

The readnpixels test does:

   PFNGLREADNPIXELS pReadnPixels =
(PFNGLREADNPIXELS)context->getRenderContext().getProcAddress("glReadnPixels");

and then calls that function pointer...but ends up in generic_nop().

It looks like the suffixless versions aren't getting exposed correctly, despite
being part of ES 3.2.

There's a fair bit of complex aliasing going on for ARB/KHR/suffixless, and I'm
getting a bit lost trying to figure out the right mapi/glapi/gen XML snippets
to do the right thing.

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


[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105098

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #3 from Bas Nieuwenhuizen  ---
What GPU do you have in your hanging system?

FWIW I can reproduce the 15*.cpp + 09* shaders hang here, let me see what I can
come up with.

-- 
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] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread Gurchetan Singh
On Wed, Feb 14, 2018 at 3:57 PM, Marek Olšák  wrote:
> Do you have commit access?

No, would appreciate a merge ;-)

> Marek
>
> On Thu, Feb 15, 2018 at 12:40 AM, gurchetansi...@chromium.org
>  wrote:
>> From: Gurchetan Singh 
>>
>> The ARB_viewport_array spec says:
>>
>> "Dependencies
>> OpenGL 1.0 is required.
>>
>> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
>> are required.
>>
>> This extension is written against the OpenGL 3.2 (Compatibility)
>> Specification."
>>
>> As such, we should ignore it for GLES2 contexts.
>>
>> Fixes:
>> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
>> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>>
>> on llvmpipe and virgl.
>>
>> v2: Use _mesa_has_* (Ilia)
>> ---
>>  src/mesa/main/viewport.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
>> index fc384909e6..398cc63685 100644
>> --- a/src/mesa/main/viewport.c
>> +++ b/src/mesa/main/viewport.c
>> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat 
>> *y,
>>  * determined by calling GetFloatv with the symbolic constant
>>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>>  */
>> -   if (ctx->Extensions.ARB_viewport_array ||
>> -   (ctx->Extensions.OES_viewport_array &&
>> -_mesa_is_gles31(ctx))) {
>> +   if (_mesa_has_ARB_viewport_array(ctx) ||
>> +   _mesa_has_OES_viewport_array(ctx)) {
>>*x = CLAMP(*x,
>>   ctx->Const.ViewportBounds.Min, 
>> ctx->Const.ViewportBounds.Max);
>>*y = CLAMP(*y,
>> --
>> 2.13.5
>>
>> ___
>> 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 5/6] mesa: replace some API_OPENGL_CORE checks with _mesa_is_desktop_gl

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

This is more accurate with respect to the compatibility profile.
---
 src/mesa/main/get.c   | 2 +-
 src/mesa/main/varray.c| 6 +++---
 src/mesa/vbo/vbo_attrib_tmp.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 13d5e85..7c3b9dd 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -2548,21 +2548,21 @@ find_value_indexed(const char *func, GLenum pname, 
GLuint index, union value *v)
   if (index >= _mesa_max_tex_unit(ctx))
  goto invalid_value;
 
   v->value_int = ctx->Texture.Unit[index].CurrentTex[target]->Name;
   return TYPE_INT;
}
 
case GL_SAMPLER_BINDING: {
   struct gl_sampler_object *samp;
 
-  if (ctx->API != API_OPENGL_CORE)
+  if (!_mesa_is_desktop_gl(ctx) || ctx->Version < 33)
  goto invalid_enum;
   if (index >= _mesa_max_tex_unit(ctx))
  goto invalid_value;
 
   samp = ctx->Texture.Unit[index].Sampler;
   v->value_int = samp ? samp->Name : 0;
   return TYPE_INT;
}
 
case GL_MAX_COMPUTE_WORK_GROUP_COUNT:
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index d55f74e..d9c926b 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -512,21 +512,21 @@ validate_array(struct gl_context *ctx, const char *func,
   _mesa_error(ctx, GL_INVALID_OPERATION, "%s(no array object bound)",
   func);
   return;
}
 
if (stride < 0) {
   _mesa_error( ctx, GL_INVALID_VALUE, "%s(stride=%d)", func, stride );
   return;
}
 
-   if (ctx->API == API_OPENGL_CORE && ctx->Version >= 44 &&
+   if (_mesa_is_desktop_gl(ctx) && ctx->Version >= 44 &&
stride > ctx->Const.MaxVertexAttribStride) {
   _mesa_error(ctx, GL_INVALID_VALUE, "%s(stride=%d > "
   "GL_MAX_VERTEX_ATTRIB_STRIDE)", func, stride);
   return;
}
 
/* Page 29 (page 44 of the PDF) of the OpenGL 3.3 spec says:
 *
 * "An INVALID_OPERATION error is generated under any of the following
 * conditions:
@@ -2148,21 +2148,21 @@ vertex_array_vertex_buffer_err(struct gl_context *ctx,
   func, (int64_t) offset);
   return;
}
 
if (stride < 0) {
   _mesa_error(ctx, GL_INVALID_VALUE,
   "%s(stride=%d < 0)", func, stride);
   return;
}
 
-   if (((ctx->API == API_OPENGL_CORE && ctx->Version >= 44) || 
_mesa_is_gles31(ctx)) &&
+   if (((_mesa_is_desktop_gl(ctx) && ctx->Version >= 44) || 
_mesa_is_gles31(ctx)) &&
stride > ctx->Const.MaxVertexAttribStride) {
   _mesa_error(ctx, GL_INVALID_VALUE, "%s(stride=%d > "
   "GL_MAX_VERTEX_ATTRIB_STRIDE)", func, stride);
   return;
}
 
vertex_array_vertex_buffer(ctx, vao, bindingIndex, buffer, offset,
   stride, false, func);
 }
 
@@ -2302,21 +2302,21 @@ vertex_array_vertex_buffers(struct gl_context *ctx,
 continue;
  }
 
  if (strides[i] < 0) {
 _mesa_error(ctx, GL_INVALID_VALUE,
 "%s(strides[%u]=%d < 0)",
 func, i, strides[i]);
 continue;
  }
 
- if (ctx->API == API_OPENGL_CORE && ctx->Version >= 44 &&
+ if (_mesa_is_desktop_gl(ctx) && ctx->Version >= 44 &&
  strides[i] > ctx->Const.MaxVertexAttribStride) {
 _mesa_error(ctx, GL_INVALID_VALUE,
 "%s(strides[%u]=%d > "
 "GL_MAX_VERTEX_ATTRIB_STRIDE)", func, i, strides[i]);
 continue;
  }
   }
 
   if (buffers[i]) {
  struct gl_vertex_buffer_binding *binding =
diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
index fd24e57..796b388 100644
--- a/src/mesa/vbo/vbo_attrib_tmp.h
+++ b/src/mesa/vbo/vbo_attrib_tmp.h
@@ -143,37 +143,37 @@ static inline float conv_i10_to_norm_float(const struct 
gl_context *ctx, int i10
 *
 *f = max{c/(2^(b-1) - 1), -1.0} (2.3)
 *
 * Comments below this equation state: "In general, this representation is
 * used for signed normalized fixed-point texture or floating point values."
 *
 * OpenGL 4.2+ and ES 3.0 remedy this and state that equation 2.3 (above)
 * is used in every case.  They remove equation 2.2 completely.
 */
if (_mesa_is_gles3(ctx) ||
-   (ctx->API == API_OPENGL_CORE && ctx->Version >= 42)) {
+   (_mesa_is_desktop_gl(ctx) && ctx->Version >= 42)) {
   /* Equation 2.3 above. */
   float f = ((float) val.x) / 511.0F;
   return MAX2(f, -1.0f);
} else {
   /* Equation 2.2 above. */
   return (2.0F * (float)val.x + 1.0F) * (1.0F  / 1023.0F);
}
 }
 
 static inline float conv_i2_to_norm_float(const struct gl_context *ctx, int i2)
 {
struct attr_bits_2 val;
val.x = i2;
 
if (_mesa_is_gles3(ctx) ||
-   (ctx->API == 

[Mesa-dev] [PATCH 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)

2018-02-14 Thread Marek Olšák
Hi,

This is the second version of GL 3.1 compatibility support patches.
There is also ARB_enhanced_layouts for the compatibility context and
other related changes.

Please review.

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


[Mesa-dev] [PATCH 2/6] mesa: enable OpenGL 3.1 with ARB_compatibility

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

---
 docs/features.txt  |  8 
 docs/relnotes/18.1.0.html  |  5 +++--
 src/mesa/drivers/dri/common/dri_util.c |  8 
 src/mesa/main/version.c| 16 ++--
 4 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 1672460..5eae34b 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -17,24 +17,24 @@ DONE (, ...)
 all the drivers in the brackets.
 
 in progress
 The extension is started but not finished yet.
 
 not started
 The extension isn't started yet.
 
 # OpenGL Core and Compatibility context support
 
-OpenGL 3.1 and later versions are only supported with the Core profile.
-There are no plans to support GL_ARB_compatibility. The last supported OpenGL
-version with all deprecated features is 3.0. Some of the later GL features
-are exposed in the 3.0 context as extensions.
+Some drivers do not support the Compatibility profile or ARB_compatibility.
+Such drivers are limited to OpenGL 3.0 if the Core profile is not requested
+by applications. Some of the later GL features are exposed in the 3.0 context
+as extensions.
 
 
 Feature Status
 --- 

 
 GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
llvmpipe, softpipe, swr
 
   glBindFragDataLocation, glGetFragDataLocation DONE
   GL_NV_conditional_render (Conditional rendering)  DONE ()
   GL_ARB_map_buffer_range (Map buffer subranges)DONE ()
diff --git a/docs/relnotes/18.1.0.html b/docs/relnotes/18.1.0.html
index b8a0cd0..d272e72 100644
--- a/docs/relnotes/18.1.0.html
+++ b/docs/relnotes/18.1.0.html
@@ -19,38 +19,39 @@
 
 Mesa 18.1.0 is a new development release. People who are concerned
 with stability and reliability should stick with a previous release or
 wait for Mesa 18.1.1.
 
 
 Mesa 18.1.0 implements the OpenGL 4.5 API, but the version reported by
 glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
 glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
 Some drivers don't support all the features required in OpenGL 4.5.  OpenGL
-4.5 is only available if requested at context creation
-because compatibility contexts are not supported.
+4.5 is only available if requested at context creation.
+Compatibility contexts may report a lower version depending on each driver.
 
 
 
 SHA256 checksums
 
 TBD.
 
 
 
 New features
 
 
 Note: some of the new features are only available with certain drivers.
 
 
 
+OpenGL 3.1 with ARB_compatibility on nv50, nvc0, r600, radeonsi, softpipe, 
llvmpipe, svga
 GL_EXT_semaphore on radeonsi
 GL_EXT_semaphore_fd on radeonsi
 
 
 Bug fixes
 
 
 TBD
 
 
diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index e6a7d23..a34f38d 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -374,28 +374,20 @@ driCreateContextAttribs(__DRIscreen *screen, int api,
default:
/* We can't create a context that satisfies the requirements of an
 * attribute that we don't understand.  Return failure.
 */
assert(!"Should not get here.");
*error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
return NULL;
}
 }
 
-/* Mesa does not support the GL_ARB_compatibilty extension or the
- * compatibility profile.  This means that we treat a API_OPENGL_COMPAT 
3.1 as
- * API_OPENGL_CORE and reject API_OPENGL_COMPAT 3.2+.
- */
-if (mesa_api == API_OPENGL_COMPAT &&
-ctx_config.major_version == 3 && ctx_config.minor_version == 1)
-   mesa_api = API_OPENGL_CORE;
-
 if (mesa_api == API_OPENGL_COMPAT
 && ((ctx_config.major_version > 3)
 || (ctx_config.major_version == 3 &&
 ctx_config.minor_version >= 2))) {
*error = __DRI_CTX_ERROR_BAD_API;
return NULL;
 }
 
 /* The latest version of EGL_KHR_create_context spec says:
  *
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index d26baab..a280690 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -573,25 +573,25 @@ compute_version_es2(const struct gl_extensions 
*extensions,
   return 0;
}
 }
 
 GLuint
 _mesa_get_version(const struct gl_extensions *extensions,
   struct gl_constants *consts, gl_api api)
 {
switch (api) {
case API_OPENGL_COMPAT:
-  /* Disable GLSL 1.40 and later for legacy contexts.
-   * This disallows creation of the GL 3.1 compatibility context. */
+  /* Disable higher GLSL versions for legacy contexts.
+   * This disallows creation of higher compatibility contexts. */
   if (!consts->AllowHigherCompatVersion) {
- if (consts->GLSLVersion > 130) {
-

[Mesa-dev] [PATCH 4/6] mesa: add some of missing compatibility support for ARB_bindless_texture

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

The extension is exposed in the compatibility profile.
---
 src/mapi/glapi/gen/apiexec.py | 2 +-
 src/mesa/main/api_loopback.c  | 8 
 src/mesa/main/vtxfmt.c| 9 +
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
index 7da0818..b5e0ad4 100644
--- a/src/mapi/glapi/gen/apiexec.py
+++ b/src/mapi/glapi/gen/apiexec.py
@@ -284,12 +284,12 @@ functions = {
 "ProgramUniform1ui64ARB": exec_info(core=31),
 "ProgramUniform2ui64ARB": exec_info(core=31),
 "ProgramUniform3ui64ARB": exec_info(core=31),
 "ProgramUniform4ui64ARB": exec_info(core=31),
 "ProgramUniform1ui64vARB": exec_info(core=31),
 "ProgramUniform2ui64vARB": exec_info(core=31),
 "ProgramUniform3ui64vARB": exec_info(core=31),
 "ProgramUniform4ui64vARB": exec_info(core=31),
 
 # GL_ARB_bindless_texture
-"GetVertexAttribLui64vARB": exec_info(core=31),
+"GetVertexAttribLui64vARB": exec_info(compatibility=30, core=31),
 }
diff --git a/src/mesa/main/api_loopback.c b/src/mesa/main/api_loopback.c
index b552d17..4eab811 100644
--- a/src/mesa/main/api_loopback.c
+++ b/src/mesa/main/api_loopback.c
@@ -1783,29 +1783,29 @@ _mesa_loopback_init_api_table(const struct gl_context 
*ctx,
   SET_VertexAttrib4Niv(dest, _mesa_VertexAttrib4Niv);
   SET_VertexAttrib4Nuiv(dest, _mesa_VertexAttrib4Nuiv);
 
   /* GL_EXT_gpu_shader4, GL 3.0 */
   SET_VertexAttribI1iv(dest, _mesa_VertexAttribI1iv);
   SET_VertexAttribI1uiv(dest, _mesa_VertexAttribI1uiv);
   SET_VertexAttribI4bv(dest, _mesa_VertexAttribI4bv);
   SET_VertexAttribI4sv(dest, _mesa_VertexAttribI4sv);
   SET_VertexAttribI4ubv(dest, _mesa_VertexAttribI4ubv);
   SET_VertexAttribI4usv(dest, _mesa_VertexAttribI4usv);
+
+  /* GL_ARB_bindless_texture */
+  SET_VertexAttribL1ui64ARB(dest, _mesa_VertexAttribL1ui64ARB);
+  SET_VertexAttribL1ui64vARB(dest, _mesa_VertexAttribL1ui64vARB);
}
 
if (ctx->API == API_OPENGL_CORE) {
   /* GL 4.1 / GL_ARB_vertex_attrib_64bit */
   SET_VertexAttribL1d(dest, _mesa_VertexAttribL1d);
   SET_VertexAttribL2d(dest, _mesa_VertexAttribL2d);
   SET_VertexAttribL3d(dest, _mesa_VertexAttribL3d);
   SET_VertexAttribL4d(dest, _mesa_VertexAttribL4d);
 
   SET_VertexAttribL1dv(dest, _mesa_VertexAttribL1dv);
   SET_VertexAttribL2dv(dest, _mesa_VertexAttribL2dv);
   SET_VertexAttribL3dv(dest, _mesa_VertexAttribL3dv);
   SET_VertexAttribL4dv(dest, _mesa_VertexAttribL4dv);
-
-  /* GL_ARB_bindless_texture */
-  SET_VertexAttribL1ui64ARB(dest, _mesa_VertexAttribL1ui64ARB);
-  SET_VertexAttribL1ui64vARB(dest, _mesa_VertexAttribL1ui64vARB);
}
 }
diff --git a/src/mesa/main/vtxfmt.c b/src/mesa/main/vtxfmt.c
index 293a385..61629a4 100644
--- a/src/mesa/main/vtxfmt.c
+++ b/src/mesa/main/vtxfmt.c
@@ -198,36 +198,37 @@ install_vtxfmt(struct gl_context *ctx, struct 
_glapi_table *tab,
if (_mesa_is_desktop_gl(ctx)) {
   SET_VertexAttribP1ui(tab, vfmt->VertexAttribP1ui);
   SET_VertexAttribP2ui(tab, vfmt->VertexAttribP2ui);
   SET_VertexAttribP3ui(tab, vfmt->VertexAttribP3ui);
   SET_VertexAttribP4ui(tab, vfmt->VertexAttribP4ui);
 
   SET_VertexAttribP1uiv(tab, vfmt->VertexAttribP1uiv);
   SET_VertexAttribP2uiv(tab, vfmt->VertexAttribP2uiv);
   SET_VertexAttribP3uiv(tab, vfmt->VertexAttribP3uiv);
   SET_VertexAttribP4uiv(tab, vfmt->VertexAttribP4uiv);
+
+  /* GL_ARB_bindless_texture */
+  SET_VertexAttribL1ui64ARB(tab, vfmt->VertexAttribL1ui64ARB);
+  SET_VertexAttribL1ui64vARB(tab, vfmt->VertexAttribL1ui64vARB);
}
 
if (ctx->API == API_OPENGL_CORE) {
+  /* GL_ARB_vertex_attrib_64bit */
   SET_VertexAttribL1d(tab, vfmt->VertexAttribL1d);
   SET_VertexAttribL2d(tab, vfmt->VertexAttribL2d);
   SET_VertexAttribL3d(tab, vfmt->VertexAttribL3d);
   SET_VertexAttribL4d(tab, vfmt->VertexAttribL4d);
 
   SET_VertexAttribL1dv(tab, vfmt->VertexAttribL1dv);
   SET_VertexAttribL2dv(tab, vfmt->VertexAttribL2dv);
   SET_VertexAttribL3dv(tab, vfmt->VertexAttribL3dv);
   SET_VertexAttribL4dv(tab, vfmt->VertexAttribL4dv);
-
-  /* GL_ARB_bindless_texture */
-  SET_VertexAttribL1ui64ARB(tab, vfmt->VertexAttribL1ui64ARB);
-  SET_VertexAttribL1ui64vARB(tab, vfmt->VertexAttribL1ui64vARB);
}
 }
 
 
 /**
  * Install per-vertex functions into the API dispatch table for execution.
  */
 void
 _mesa_install_exec_vtxfmt(struct gl_context *ctx, const GLvertexformat *vfmt)
 {
-- 
2.7.4

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


[Mesa-dev] [PATCH 6/6] mesa: rename has_core_gs -> has_gs in get_programiv

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

This is also true for GLES.
---
 src/mesa/main/shaderapi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index d0d2ef9..37d99b5 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -660,21 +660,21 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname,
/* Is transform feedback available in this context?
 */
const bool has_xfb =
   (ctx->API == API_OPENGL_COMPAT && ctx->Extensions.EXT_transform_feedback)
   || ctx->API == API_OPENGL_CORE
   || _mesa_is_gles3(ctx);
 
/* True if geometry shaders (of the form that was adopted into GLSL 1.50
 * and GL 3.2) are available in this context
 */
-   const bool has_core_gs = _mesa_has_geometry_shaders(ctx);
+   const bool has_gs = _mesa_has_geometry_shaders(ctx);
const bool has_tess = _mesa_has_tessellation(ctx);
 
/* Are uniform buffer objects available in this context?
 */
const bool has_ubo =
   (ctx->API == API_OPENGL_COMPAT &&
ctx->Extensions.ARB_uniform_buffer_object)
   || ctx->API == API_OPENGL_CORE
   || _mesa_is_gles3(ctx);
 
@@ -761,45 +761,45 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname,
 
   *params = max_len;
   return;
}
case GL_TRANSFORM_FEEDBACK_BUFFER_MODE:
   if (!has_xfb)
  break;
   *params = shProg->TransformFeedback.BufferMode;
   return;
case GL_GEOMETRY_VERTICES_OUT:
-  if (!has_core_gs)
+  if (!has_gs)
  break;
   if (check_gs_query(ctx, shProg)) {
  *params = shProg->_LinkedShaders[MESA_SHADER_GEOMETRY]->
 Program->info.gs.vertices_out;
   }
   return;
case GL_GEOMETRY_SHADER_INVOCATIONS:
-  if (!has_core_gs || !ctx->Extensions.ARB_gpu_shader5)
+  if (!has_gs || !ctx->Extensions.ARB_gpu_shader5)
  break;
   if (check_gs_query(ctx, shProg)) {
  *params = shProg->_LinkedShaders[MESA_SHADER_GEOMETRY]->
 Program->info.gs.invocations;
   }
   return;
case GL_GEOMETRY_INPUT_TYPE:
-  if (!has_core_gs)
+  if (!has_gs)
  break;
   if (check_gs_query(ctx, shProg)) {
  *params = shProg->_LinkedShaders[MESA_SHADER_GEOMETRY]->
 Program->info.gs.input_primitive;
   }
   return;
case GL_GEOMETRY_OUTPUT_TYPE:
-  if (!has_core_gs)
+  if (!has_gs)
  break;
   if (check_gs_query(ctx, shProg)) {
  *params = shProg->_LinkedShaders[MESA_SHADER_GEOMETRY]->
 Program->info.gs.output_primitive;
   }
   return;
case GL_ACTIVE_UNIFORM_BLOCK_MAX_NAME_LENGTH: {
   unsigned i;
   GLint max_len = 0;
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 3/6] mesa: expose ARB_enhanced_layouts in the compatibility profile

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

GLSL 1.40 is required.
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++-
 src/mesa/main/extensions_table.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index cc961e0..5a6b12e 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -165,21 +165,22 @@ intelInitExtensions(struct gl_context *ctx)
 
if (devinfo->gen == 6)
   ctx->Extensions.ARB_transform_feedback2 = true;
 
if (devinfo->gen >= 6) {
   ctx->Extensions.ARB_blend_func_extended =
  !driQueryOptionb(>optionCache, "disable_blend_func_extended");
   ctx->Extensions.ARB_conditional_render_inverted = true;
   ctx->Extensions.ARB_cull_distance = true;
   ctx->Extensions.ARB_draw_buffers_blend = true;
-  ctx->Extensions.ARB_enhanced_layouts = true;
+  if (ctx->API != API_OPENGL_COMPAT)
+ ctx->Extensions.ARB_enhanced_layouts = true;
   ctx->Extensions.ARB_ES3_compatibility = true;
   ctx->Extensions.ARB_fragment_layer_viewport = true;
   ctx->Extensions.ARB_pipeline_statistics_query = true;
   ctx->Extensions.ARB_sample_shading = true;
   ctx->Extensions.ARB_shading_language_420pack = true;
   if (ctx->API != API_OPENGL_COMPAT) {
  ctx->Extensions.ARB_texture_buffer_object = true;
  ctx->Extensions.ARB_texture_buffer_object_rgb32 = true;
  ctx->Extensions.ARB_texture_buffer_range = true;
   }
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 02c97a2..71c9a57 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -53,21 +53,21 @@ EXT(ARB_debug_output, dummy_true
 EXT(ARB_depth_buffer_float  , ARB_depth_buffer_float   
  , GLL, GLC,  x ,  x , 2008)
 EXT(ARB_depth_clamp , ARB_depth_clamp  
  , GLL, GLC,  x ,  x , 2003)
 EXT(ARB_depth_texture   , ARB_depth_texture
  , GLL,  x ,  x ,  x , 2001)
 EXT(ARB_derivative_control  , ARB_derivative_control   
  , GLL, GLC,  x ,  x , 2014)
 EXT(ARB_direct_state_access , dummy_true   
  ,  x , GLC,  x ,  x , 2014)
 EXT(ARB_draw_buffers, dummy_true   
  , GLL, GLC,  x ,  x , 2002)
 EXT(ARB_draw_buffers_blend  , ARB_draw_buffers_blend   
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_draw_elements_base_vertex   , ARB_draw_elements_base_vertex
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_draw_indirect   , ARB_draw_indirect
  ,  x , GLC,  x ,  x , 2010)
 EXT(ARB_draw_instanced  , ARB_draw_instanced   
  , GLL, GLC,  x ,  x , 2008)
-EXT(ARB_enhanced_layouts, ARB_enhanced_layouts 
  ,  x , GLC,  x ,  x , 2013)
+EXT(ARB_enhanced_layouts, ARB_enhanced_layouts 
  , GLL, GLC,  x ,  x , 2013)
 EXT(ARB_explicit_attrib_location, ARB_explicit_attrib_location 
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_explicit_uniform_location   , ARB_explicit_uniform_location
  , GLL, GLC,  x ,  x , 2012)
 EXT(ARB_fragment_coord_conventions  , ARB_fragment_coord_conventions   
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_fragment_layer_viewport , ARB_fragment_layer_viewport  
  ,  x , GLC,  x ,  x , 2012)
 EXT(ARB_fragment_program, ARB_fragment_program 
  , GLL,  x ,  x ,  x , 2002)
 EXT(ARB_fragment_program_shadow , ARB_fragment_program_shadow  
  , GLL,  x ,  x ,  x , 2003)
 EXT(ARB_fragment_shader , ARB_fragment_shader  
  , GLL, GLC,  x ,  x , 2002)
 EXT(ARB_framebuffer_no_attachments  , ARB_framebuffer_no_attachments   
  , GLL, GLC,  x ,  x , 2012)
 EXT(ARB_framebuffer_object  , ARB_framebuffer_object   
  , GLL, GLC,  x ,  x , 2005)
 EXT(ARB_framebuffer_sRGB, EXT_framebuffer_sRGB 
  , GLL, GLC,  x ,  x , 1998)
-- 
2.7.4

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


[Mesa-dev] [PATCH 1/6] mesa: implement ARB_compatibility

2018-02-14 Thread Marek Olšák
From: Marek Olšák 

---
 src/compiler/glsl/builtin_functions.cpp  | 2 +-
 src/compiler/glsl/builtin_types.cpp  | 2 +-
 src/compiler/glsl/builtin_variables.cpp  | 2 +-
 src/compiler/glsl/glsl_parser_extras.cpp | 1 +
 src/compiler/glsl/glsl_parser_extras.h   | 2 ++
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/mtypes.h   | 1 +
 7 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index 293e8bd..5f772c9 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -97,21 +97,21 @@ using namespace ir_builder;
 static bool
 always_available(const _mesa_glsl_parse_state *)
 {
return true;
 }
 
 static bool
 compatibility_vs_only(const _mesa_glsl_parse_state *state)
 {
return state->stage == MESA_SHADER_VERTEX &&
-  state->language_version <= 130 &&
+  (state->compat_shader || state->ARB_compatibility_enable) &&
   !state->es_shader;
 }
 
 static bool
 fs_only(const _mesa_glsl_parse_state *state)
 {
return state->stage == MESA_SHADER_FRAGMENT;
 }
 
 static bool
diff --git a/src/compiler/glsl/builtin_types.cpp 
b/src/compiler/glsl/builtin_types.cpp
index b64f757..7a01cb4 100644
--- a/src/compiler/glsl/builtin_types.cpp
+++ b/src/compiler/glsl/builtin_types.cpp
@@ -281,21 +281,21 @@ _mesa_glsl_initialize_types(struct _mesa_glsl_parse_state 
*state)
for (unsigned i = 0; i < ARRAY_SIZE(builtin_type_versions); i++) {
   const struct builtin_type_versions *const t = _type_versions[i];
   if (state->is_version(t->min_gl, t->min_es)) {
  add_type(symbols, t->type);
   }
}
 
/* Add deprecated structure types.  While these were deprecated in 1.30,
 * they're still present.  We've removed them in 1.40+ (OpenGL 3.1+).
 */
-   if (state->compat_shader) {
+   if (state->compat_shader || state->ARB_compatibility_enable) {
   for (unsigned i = 0; i < ARRAY_SIZE(deprecated_types); i++) {
  add_type(symbols, deprecated_types[i]);
   }
}
 
/* Add types for enabled extensions.  They may have already been added
 * by the version-based loop, but attempting to add them a second time
 * is harmless.
 */
if (state->ARB_texture_cube_map_array_enable ||
diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index a686cb6..f0210b6 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -434,21 +434,21 @@ private:
const glsl_type * const mat4_t;
 
per_vertex_accumulator per_vertex_in;
per_vertex_accumulator per_vertex_out;
 };
 
 
 builtin_variable_generator::builtin_variable_generator(
exec_list *instructions, struct _mesa_glsl_parse_state *state)
: instructions(instructions), state(state), symtab(state->symbols),
- compatibility(state->compat_shader || !state->is_version(140, 100)),
+ compatibility(state->compat_shader || state->ARB_compatibility_enable),
  bool_t(glsl_type::bool_type), int_t(glsl_type::int_type),
  uint_t(glsl_type::uint_type),
  uint64_t(glsl_type::uint64_t_type),
  float_t(glsl_type::float_type), vec2_t(glsl_type::vec2_type),
  vec3_t(glsl_type::vec3_type), vec4_t(glsl_type::vec4_type),
  uvec3_t(glsl_type::uvec3_type),
  mat3_t(glsl_type::mat3_type), mat4_t(glsl_type::mat4_type)
 {
 }
 
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index d99916d..81d74e9 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -609,20 +609,21 @@ has_##name_str(const struct gl_context *ctx, gl_api api, 
uint8_t version) \
  * Table of extensions that can be enabled/disabled within a shader,
  * and the conditions under which they are supported.
  */
 static const _mesa_glsl_extension _mesa_glsl_supported_extensions[] = {
/* ARB extensions go here, sorted alphabetically.
 */
EXT(ARB_ES3_1_compatibility),
EXT(ARB_ES3_2_compatibility),
EXT(ARB_arrays_of_arrays),
EXT(ARB_bindless_texture),
+   EXT(ARB_compatibility),
EXT(ARB_compute_shader),
EXT(ARB_compute_variable_group_size),
EXT(ARB_conservative_depth),
EXT(ARB_cull_distance),
EXT(ARB_derivative_control),
EXT(ARB_draw_buffers),
EXT(ARB_draw_instanced),
EXT(ARB_enhanced_layouts),
EXT(ARB_explicit_attrib_location),
EXT(ARB_explicit_uniform_location),
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index 508befd..f88cb78 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -602,20 +602,22 @@ struct _mesa_glsl_parse_state {
/* ARB extensions go here, sorted alphabetically.
 */
bool ARB_ES3_1_compatibility_enable;
bool ARB_ES3_1_compatibility_warn;
bool 

[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105098

--- Comment #2 from Lukas Kahnert  ---
>From the VulkanTutorial source most demos trigger the freeze.
For example the triangle demo 15_hello_triangle.cpp with 09_shader_base.frag
and 09_shader_base.vert as shaders.
The command buffers are very simple and if I comment out vkCmdDraw it also
doesn't freeze(well the GPU also does nothing).
Commenting out the semaphores at submit changes nothing. The Validation Layers
report warnings cause of the missing semaphores but after couple of seconds it
also freezes.
I piped the output and read it from ssh but there are no Validation Layer
reports. It's like the GPU stop working at this moment.
I know its a hardware-specific problem because on Intel ANV and RADV(AMD OLAND)
it works.
Is it possible that the GPU hangs if there will be too much draw calls in a
short time frame?

-- 
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] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread Marek Olšák
Do you have commit access?

Marek

On Thu, Feb 15, 2018 at 12:40 AM, gurchetansi...@chromium.org
 wrote:
> From: Gurchetan Singh 
>
> The ARB_viewport_array spec says:
>
> "Dependencies
> OpenGL 1.0 is required.
>
> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
> are required.
>
> This extension is written against the OpenGL 3.2 (Compatibility)
> Specification."
>
> As such, we should ignore it for GLES2 contexts.
>
> Fixes:
> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>
> on llvmpipe and virgl.
>
> v2: Use _mesa_has_* (Ilia)
> ---
>  src/mesa/main/viewport.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
> index fc384909e6..398cc63685 100644
> --- a/src/mesa/main/viewport.c
> +++ b/src/mesa/main/viewport.c
> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat 
> *y,
>  * determined by calling GetFloatv with the symbolic constant
>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>  */
> -   if (ctx->Extensions.ARB_viewport_array ||
> -   (ctx->Extensions.OES_viewport_array &&
> -_mesa_is_gles31(ctx))) {
> +   if (_mesa_has_ARB_viewport_array(ctx) ||
> +   _mesa_has_OES_viewport_array(ctx)) {
>*x = CLAMP(*x,
>   ctx->Const.ViewportBounds.Min, 
> ctx->Const.ViewportBounds.Max);
>*y = CLAMP(*y,
> --
> 2.13.5
>
> ___
> 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 18/18] anv/cmd_buffer: Avoid unnecessary transitions before fast clears

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:33PM -0800, Jason Ekstrand wrote:
> Previously, we would always apply the layout transition at the beginning
> of the subpass and then do the clear whether fast or slow.  This meant
> that there were some cases, specifically when the initial layout is
> VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
> ambiguate followed immediately by a fast-clear.  This probably isn't
> terribly expensive, but it is a waste that we can avoid easily enough
> now that we're doing everything at the same time in begin_subpass.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 62 
> +++---
>  1 file changed, 38 insertions(+), 24 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 7f06441..453aea8 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3335,6 +3335,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>   target_layout = subpass->attachments[i].layout;
>}
>  
> +  /* Clears are based on the image view for 3D surfaces but transitions
> +   * are done on an entire miplevel at a time.
> +   */
> +  uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
> +  uint32_t clear_layer_count = fb->layers;
> +
>if (image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
>   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
>  
> @@ -3348,30 +3354,8 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>  layer_count = fb->layers;
>   }
>  
> - transition_color_buffer(cmd_buffer, image, 
> VK_IMAGE_ASPECT_COLOR_BIT,
> - iview->planes[0].isl.base_level, 1,
> - base_layer, layer_count,
> - att_state->current_layout, target_layout);
> -  } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> - transition_depth_buffer(cmd_buffer, image,
> - att_state->current_layout, target_layout);
> - att_state->aux_usage =
> -anv_layout_to_aux_usage(_buffer->device->info, image,
> -VK_IMAGE_ASPECT_DEPTH_BIT, 
> target_layout);
> -  }
> -  att_state->current_layout = target_layout;
> -
> -  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
> - assert(att_state->pending_clear_aspects == 
> VK_IMAGE_ASPECT_COLOR_BIT);
> -
> - /* Multi-planar images are not supported as attachments */
> - assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> - assert(image->n_planes == 1);
> -
> - uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
> - uint32_t clear_layer_count = fb->layers;
> -
> - if (att_state->fast_clear) {
> + if ((att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) 
> &&
> + att_state->fast_clear) {
>  /* We only support fast-clears on the first layer */
>  assert(iview->planes[0].isl.base_level == 0);
>  assert(iview->planes[0].isl.base_array_layer == 0);
> @@ -3381,6 +3365,13 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>  base_clear_layer++;
>  clear_layer_count--;
>  
> +/* Performing a fast clear takes care of all our transition needs
> + * for the first slice.  Increment the base layer and layer count
> + * so that later transitions don't touch layer 0.
> + */

Why not do the same optimization for depth?

-Nanley

> +base_layer++;
> +layer_count--;
> +
>  genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
>   image, VK_IMAGE_ASPECT_COLOR_BIT,
>   true /* copy from ss */);
> @@ -3401,6 +3392,29 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>  }
>   }
>  
> + if (layer_count > 0) {
> +transition_color_buffer(cmd_buffer, image,
> +VK_IMAGE_ASPECT_COLOR_BIT,
> +iview->planes[0].isl.base_level, 1,
> +base_layer, layer_count,
> +att_state->current_layout, 
> target_layout);
> + }
> +  } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> + transition_depth_buffer(cmd_buffer, image,
> + att_state->current_layout, target_layout);
> + att_state->aux_usage =
> +anv_layout_to_aux_usage(_buffer->device->info, image,
> +VK_IMAGE_ASPECT_DEPTH_BIT, 
> target_layout);
> +  }
> +  att_state->current_layout = target_layout;
> +
> +  if 

[Mesa-dev] [PATCH] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread gurchetansi...@chromium.org
From: Gurchetan Singh 

The ARB_viewport_array spec says:

"Dependencies
OpenGL 1.0 is required.

OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
are required.

This extension is written against the OpenGL 3.2 (Compatibility)
Specification."

As such, we should ignore it for GLES2 contexts.

Fixes:
dEQP-GLES2.functional.state_query.integers.viewport_getinteger
dEQP-GLES2.functional.state_query.integers.viewport_getfloat

on llvmpipe and virgl.

v2: Use _mesa_has_* (Ilia)
---
 src/mesa/main/viewport.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index fc384909e6..398cc63685 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat *y,
 * determined by calling GetFloatv with the symbolic constant
 * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
 */
-   if (ctx->Extensions.ARB_viewport_array ||
-   (ctx->Extensions.OES_viewport_array &&
-_mesa_is_gles31(ctx))) {
+   if (_mesa_has_ARB_viewport_array(ctx) ||
+   _mesa_has_OES_viewport_array(ctx)) {
   *x = CLAMP(*x,
  ctx->Const.ViewportBounds.Min, ctx->Const.ViewportBounds.Max);
   *y = CLAMP(*y,
-- 
2.13.5

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


Re: [Mesa-dev] [PATCH] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread Ilia Mirkin
On Wed, Feb 14, 2018 at 6:22 PM, gurchetansi...@chromium.org
 wrote:
> From: Gurchetan Singh 
>
> The ARB_viewport_array spec says:
>
> "Dependencies
> OpenGL 1.0 is required.
>
> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
> are required.
>
> This extension is written against the OpenGL 3.2 (Compatibility)
> Specification."
>
> As such, we should ignore it for GLES2 contexts.
>
> Fixes:
> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>
> on llvmpipe and virgl.
> ---
>  src/mesa/main/viewport.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
> index fc384909e6..380372772e 100644
> --- a/src/mesa/main/viewport.c
> +++ b/src/mesa/main/viewport.c
> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat 
> *y,
>  * determined by calling GetFloatv with the symbolic constant
>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>  */
> -   if (ctx->Extensions.ARB_viewport_array ||
> -   (ctx->Extensions.OES_viewport_array &&
> -_mesa_is_gles31(ctx))) {
> +   if ((ctx->Extensions.ARB_viewport_array && !_mesa_is_gles(ctx)) ||
> +   (ctx->Extensions.OES_viewport_array && _mesa_is_gles31(ctx))) {

I think you're looking for

_mesa_has_ARB_viewport_array(ctx) ||
_mesa_has_OES_viewport_array(ctx)

which will get all these little details "right". I do hope drivers are
ready for this.

>*x = CLAMP(*x,
>   ctx->Const.ViewportBounds.Min, 
> ctx->Const.ViewportBounds.Max);
>*y = CLAMP(*y,
> --
> 2.13.5
>
> ___
> 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: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Thu, Feb 15, 2018 at 12:22 AM, gurchetansi...@chromium.org
 wrote:
> From: Gurchetan Singh 
>
> The ARB_viewport_array spec says:
>
> "Dependencies
> OpenGL 1.0 is required.
>
> OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
> are required.
>
> This extension is written against the OpenGL 3.2 (Compatibility)
> Specification."
>
> As such, we should ignore it for GLES2 contexts.
>
> Fixes:
> dEQP-GLES2.functional.state_query.integers.viewport_getinteger
> dEQP-GLES2.functional.state_query.integers.viewport_getfloat
>
> on llvmpipe and virgl.
> ---
>  src/mesa/main/viewport.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
> index fc384909e6..380372772e 100644
> --- a/src/mesa/main/viewport.c
> +++ b/src/mesa/main/viewport.c
> @@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat 
> *y,
>  * determined by calling GetFloatv with the symbolic constant
>  * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
>  */
> -   if (ctx->Extensions.ARB_viewport_array ||
> -   (ctx->Extensions.OES_viewport_array &&
> -_mesa_is_gles31(ctx))) {
> +   if ((ctx->Extensions.ARB_viewport_array && !_mesa_is_gles(ctx)) ||
> +   (ctx->Extensions.OES_viewport_array && _mesa_is_gles31(ctx))) {
>*x = CLAMP(*x,
>   ctx->Const.ViewportBounds.Min, 
> ctx->Const.ViewportBounds.Max);
>*y = CLAMP(*y,
> --
> 2.13.5
>
> ___
> 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] mesa: don't clamp just based on ARB_viewport_array extension

2018-02-14 Thread gurchetansi...@chromium.org
From: Gurchetan Singh 

The ARB_viewport_array spec says:

"Dependencies
OpenGL 1.0 is required.

OpenGL 3.2 or the EXT_geometry_shader4 or ARB_geometry_shader4 extensions
are required.

This extension is written against the OpenGL 3.2 (Compatibility)
Specification."

As such, we should ignore it for GLES2 contexts.

Fixes:
dEQP-GLES2.functional.state_query.integers.viewport_getinteger
dEQP-GLES2.functional.state_query.integers.viewport_getfloat

on llvmpipe and virgl.
---
 src/mesa/main/viewport.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index fc384909e6..380372772e 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -51,9 +51,8 @@ clamp_viewport(struct gl_context *ctx, GLfloat *x, GLfloat *y,
 * determined by calling GetFloatv with the symbolic constant
 * VIEWPORT_BOUNDS_RANGE (see section 6.1)."
 */
-   if (ctx->Extensions.ARB_viewport_array ||
-   (ctx->Extensions.OES_viewport_array &&
-_mesa_is_gles31(ctx))) {
+   if ((ctx->Extensions.ARB_viewport_array && !_mesa_is_gles(ctx)) ||
+   (ctx->Extensions.OES_viewport_array && _mesa_is_gles31(ctx))) {
   *x = CLAMP(*x,
  ctx->Const.ViewportBounds.Min, ctx->Const.ViewportBounds.Max);
   *y = CLAMP(*y,
-- 
2.13.5

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


Re: [Mesa-dev] [PATCH] i965: Drop EXEC_OBJECT_CAPTURE defines.

2018-02-14 Thread Jason Ekstrand
rb

On Wed, Feb 14, 2018 at 2:19 PM, Kenneth Graunke 
wrote:

> These only existed to avoid making people update libdrm for new uABI
> headers.  A while ago we imported those headers into the Mesa repo,
> so the dependency is gone and these are no longer useful.
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> index a3745d6667a..005ff19798e 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> @@ -120,9 +120,6 @@ struct brw_bo {
> int refcount;
> const char *name;
>
> -#ifndef EXEC_OBJECT_CAPTURE
> -#define EXEC_OBJECT_CAPTURE(1<<7)
> -#endif
> uint64_t kflags;
>
> /**
> --
> 2.16.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 v3 04/18] anv: Use framebuffer layers for implicit subpass transitions

2018-02-14 Thread Jason Ekstrand
On Wed, Feb 14, 2018 at 2:27 PM, Nanley Chery  wrote:

> On Wed, Feb 14, 2018 at 12:16:19PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> We should probabably add:
>
> Fixes: de3be618016 "anv/cmd_buffer: Rework aux tracking"
>

Done.


> This patch is
> Reviewed-by: Nanley Chery 
>

Thanks!


> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 8b1816a..a16b742 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -3324,7 +3324,7 @@ cmd_buffer_subpass_transition_layouts(struct
> anv_cmd_buffer * const cmd_buffer,
> >   iview->planes[0].isl.base_level);
> >   } else {
> >  base_layer = iview->planes[0].isl.base_array_layer;
> > -layer_count = iview->planes[0].isl.array_len;
> > +layer_count = cmd_state->framebuffer->layers;
> >   }
> >
> >   transition_color_buffer(cmd_buffer, image,
> VK_IMAGE_ASPECT_COLOR_BIT,
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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 10/18] anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass

2018-02-14 Thread Jason Ekstrand
On Wed, Feb 14, 2018 at 2:51 PM, Nanley Chery  wrote:

> On Wed, Feb 14, 2018 at 12:16:25PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_blorp.c   | 242 --
> ---
> >  src/intel/vulkan/anv_private.h |  17 ++-
> >  src/intel/vulkan/genX_cmd_buffer.c |  68 ++-
> >  3 files changed, 186 insertions(+), 141 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index fd32227..6c0c858 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1136,143 +1136,6 @@ enum subpass_stage {
> > SUBPASS_STAGE_RESOLVE,
> >  };
> >
> > -static bool
> > -subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
> > -{
> > -   const struct anv_cmd_state *cmd_state = _buffer->state;
> > -   uint32_t ds = cmd_state->subpass->depth_
> stencil_attachment.attachment;
> > -
> > -   if (ds != VK_ATTACHMENT_UNUSED) {
> > -  assert(ds < cmd_state->pass->attachment_count);
> > -  if (cmd_state->attachments[ds].pending_clear_aspects)
> > - return true;
> > -   }
> > -
> > -   return false;
> > -}
> > -
> > -void
> > -anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
> > -{
> > -   const struct anv_cmd_state *cmd_state = _buffer->state;
> > -   const VkRect2D render_area = cmd_buffer->state.render_area;
> > -
> > -
> > -   if (!subpass_needs_clear(cmd_buffer))
> > -  return;
> > -
> > -   /* Because this gets called within a render pass, we tell blorp not
> to
> > -* trash our depth and stencil buffers.
> > -*/
> > -   struct blorp_batch batch;
> > -   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
> > -BLORP_BATCH_NO_EMIT_DEPTH_STENCIL);
> > -
> > -   VkClearRect clear_rect = {
> > -  .rect = cmd_buffer->state.render_area,
> > -  .baseArrayLayer = 0,
> > -  .layerCount = cmd_buffer->state.framebuffer->layers,
> > -   };
> > -
> > -   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > -
> > -   const uint32_t ds = cmd_state->subpass->depth_
> stencil_attachment.attachment;
> > -   assert(ds == VK_ATTACHMENT_UNUSED || ds <
> cmd_state->pass->attachment_count);
> > -
> > -   if (ds != VK_ATTACHMENT_UNUSED &&
> > -   cmd_state->attachments[ds].pending_clear_aspects) {
> > -
> > -  VkClearAttachment clear_att = {
> > - .aspectMask = cmd_state->attachments[ds].
> pending_clear_aspects,
> > - .clearValue = cmd_state->attachments[ds].clear_value,
> > -  };
> > -
> > -
> > -  const uint8_t gen = cmd_buffer->device->info.gen;
> > -  bool clear_with_hiz = gen >= 8 && 
> > cmd_state->attachments[ds].aux_usage
> ==
> > -ISL_AUX_USAGE_HIZ;
> > -  const struct anv_image_view *iview = fb->attachments[ds];
> > -
> > -  if (clear_with_hiz) {
> > - const bool clear_depth = clear_att.aspectMask &
> > -  VK_IMAGE_ASPECT_DEPTH_BIT;
> > - const bool clear_stencil = clear_att.aspectMask &
> > -VK_IMAGE_ASPECT_STENCIL_BIT;
> > -
> > - /* Check against restrictions for depth buffer clearing. A
> great GPU
> > -  * performance benefit isn't expected when using the HZ
> sequence for
> > -  * stencil-only clears. Therefore, we don't emit a HZ op
> sequence for
> > -  * a stencil clear in addition to using the BLORP-fallback for
> depth.
> > -  */
> > - if (clear_depth) {
> > -if (!blorp_can_hiz_clear_depth(gen,
> iview->planes[0].isl.format,
> > -   iview->image->samples,
> > -   render_area.offset.x,
> > -   render_area.offset.y,
> > -   render_area.offset.x +
> > -   render_area.extent.width,
> > -   render_area.offset.y +
> > -   render_area.extent.height)) {
> > -   clear_with_hiz = false;
> > -} else if (clear_att.clearValue.depthStencil.depth !=
> > -   ANV_HZ_FC_VAL) {
> > -   /* Don't enable fast depth clears for any color not
> equal to
> > -* ANV_HZ_FC_VAL.
> > -*/
> > -   clear_with_hiz = false;
> > -} else if (gen == 8 &&
> > -   anv_can_sample_with_hiz(_
> buffer->device->info,
> > -   iview->image)) {
> > -   /* Only gen9+ supports returning ANV_HZ_FC_VAL when
> sampling a
> > -* fast-cleared portion of a HiZ buffer. Testing has
> revealed
> > -* that Gen8 only supports returning 0.0f. Gens prior to
> gen8 do
> > -* not support this feature at all.
> > -

Re: [Mesa-dev] [PATCH v3 02/18] anv: Be more careful about fast-clear colors

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:17PM -0800, Jason Ekstrand wrote:
> Previously, we just used all the channels regardless of the format.
> This is less than ideal because some channels may have undefined values
> and this should be ok from the client's perspective.  Even though the
> driver should do the correct thing regardless of what is in the
> undefined value, it makes things less deterministic.  In particular, the
> driver may choose to fast-clear or not based on undefined values.  This
> level of nondeterminism is bad.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 46 
> --
>  1 file changed, 19 insertions(+), 27 deletions(-)
> 

Nice find. Patches 1 and 2 are:
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index ce47b8a..8b1816a 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -202,24 +202,6 @@ add_image_view_relocs(struct anv_cmd_buffer *cmd_buffer,
> }
>  }
>  
> -static bool
> -color_is_zero_one(VkClearColorValue value, enum isl_format format)
> -{
> -   if (isl_format_has_int_channel(format)) {
> -  for (unsigned i = 0; i < 4; i++) {
> - if (value.int32[i] != 0 && value.int32[i] != 1)
> -return false;
> -  }
> -   } else {
> -  for (unsigned i = 0; i < 4; i++) {
> - if (value.float32[i] != 0.0f && value.float32[i] != 1.0f)
> -return false;
> -  }
> -   }
> -
> -   return true;
> -}
> -
>  static void
>  color_attachment_compute_aux_usage(struct anv_device * device,
> struct anv_cmd_state * cmd_state,
> @@ -283,13 +265,25 @@ color_attachment_compute_aux_usage(struct anv_device * 
> device,
>  
> assert(iview->image->planes[0].aux_surface.isl.usage & 
> ISL_SURF_USAGE_CCS_BIT);
>  
> +   const struct isl_format_layout *view_fmtl =
> +  isl_format_get_layout(iview->planes[0].isl.format);
> +   union isl_color_value clear_color = {};
> +
> +#define COPY_CLEAR_COLOR_CHANNEL(c, i) \
> +   if (view_fmtl->channels.c.bits) \
> +  clear_color.u32[i] = att_state->clear_value.color.uint32[i]
> +
> +   COPY_CLEAR_COLOR_CHANNEL(r, 0);
> +   COPY_CLEAR_COLOR_CHANNEL(g, 1);
> +   COPY_CLEAR_COLOR_CHANNEL(b, 2);
> +   COPY_CLEAR_COLOR_CHANNEL(a, 3);
> +
> +#undef COPY_CLEAR_COLOR_CHANNEL
> +
> att_state->clear_color_is_zero_one =
> -  color_is_zero_one(att_state->clear_value.color, 
> iview->planes[0].isl.format);
> +  isl_color_value_is_zero_one(clear_color, iview->planes[0].isl.format);
> att_state->clear_color_is_zero =
> -  att_state->clear_value.color.uint32[0] == 0 &&
> -  att_state->clear_value.color.uint32[1] == 0 &&
> -  att_state->clear_value.color.uint32[2] == 0 &&
> -  att_state->clear_value.color.uint32[3] == 0;
> +  isl_color_value_is_zero(clear_color, iview->planes[0].isl.format);
>  
> if (att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT) {
>/* Start off assuming fast clears are possible */
> @@ -341,10 +335,8 @@ color_attachment_compute_aux_usage(struct anv_device * 
> device,
> "LOAD_OP_CLEAR.  Only fast-clearing the first slice");
>}
>  
> -  if (att_state->fast_clear) {
> - memcpy(fast_clear_color->u32, att_state->clear_value.color.uint32,
> -sizeof(fast_clear_color->u32));
> -  }
> +  if (att_state->fast_clear)
> + *fast_clear_color = clear_color;
> } else {
>att_state->fast_clear = false;
> }
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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 15/18] anv/cmd_buffer: Sync clear values in begin_subpass

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:30PM -0800, Jason Ekstrand wrote:
> This is quite a bit cleaner because we now sync the clear values at the
> same time as we do the fast clear.  For loading the clear values into
> the surface state, we now do it once when we handle the LOAD_OP_LOAD
> instead of every subpass.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 148 
> -
>  1 file changed, 48 insertions(+), 100 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 3d120d1..793f590 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3411,97 +3411,6 @@ cmd_buffer_subpass_transition_layouts(struct 
> anv_cmd_buffer * const cmd_buffer,
> }
>  }
>  
> -/* Update the clear value dword(s) in surface state objects or the fast clear
> - * state buffer entry for the color attachments used in this subpass.
> - */
> -static void
> -cmd_buffer_subpass_sync_fast_clear_values(struct anv_cmd_buffer *cmd_buffer)
> -{
> -   assert(cmd_buffer && cmd_buffer->state.subpass);
> -
> -   const struct anv_cmd_state *state = _buffer->state;
> -
> -   /* Iterate through every color attachment used in this subpass. */
> -   for (uint32_t i = 0; i < state->subpass->color_count; ++i) {
> -
> -  /* The attachment should be one of the attachments described in the
> -   * render pass and used in the subpass.
> -   */
> -  const uint32_t a = state->subpass->color_attachments[i].attachment;
> -  if (a == VK_ATTACHMENT_UNUSED)
> - continue;
> -
> -  assert(a < state->pass->attachment_count);
> -
> -  /* Store some information regarding this attachment. */
> -  const struct anv_attachment_state *att_state = >attachments[a];
> -  const struct anv_image_view *iview = 
> state->framebuffer->attachments[a];
> -  const struct anv_render_pass_attachment *rp_att =
> - >pass->attachments[a];
> -
> -  if (att_state->aux_usage == ISL_AUX_USAGE_NONE)
> - continue;
> -
> -  /* The fast clear state entry must be updated if a fast clear is going 
> to
> -   * happen. The surface state must be updated if the clear value from a
> -   * prior fast clear may be needed.
> -   */
> -  if (att_state->pending_clear_aspects && att_state->fast_clear) {
> - /* Update the fast clear state entry. */
> - genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
> -  iview->image,
> -  VK_IMAGE_ASPECT_COLOR_BIT,
> -  true /* copy from ss */);
> -
> - /* Fast-clears impact whether or not a resolve will be necessary. */
> - if (att_state->clear_color_is_zero) {
> -/* This image has the auxiliary buffer enabled. We can mark the
> - * subresource as not needing a resolve because the clear color
> - * will match what's in every RENDER_SURFACE_STATE object when
> - * it's being used for sampling.
> - */
> -set_image_fast_clear_state(cmd_buffer, iview->image,
> -   VK_IMAGE_ASPECT_COLOR_BIT,
> -   ANV_FAST_CLEAR_DEFAULT_VALUE);
> - } else {
> -set_image_fast_clear_state(cmd_buffer, iview->image,
> -   VK_IMAGE_ASPECT_COLOR_BIT,
> -   ANV_FAST_CLEAR_ANY);
> - }
> -  } else if (rp_att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD &&
> - iview->planes[0].isl.base_level == 0 &&
> - iview->planes[0].isl.base_array_layer == 0) {
> - /* The attachment may have been fast-cleared in a previous render
> -  * pass and the value is needed now. Update the surface state(s).
> -  *
> -  * TODO: Do this only once per render pass instead of every subpass.
> -  */
> - genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
> -  iview->image,
> -  VK_IMAGE_ASPECT_COLOR_BIT,
> -  false /* copy to ss */);
> -
> - if (need_input_attachment_state(rp_att) &&
> - att_state->input_aux_usage != ISL_AUX_USAGE_NONE) {
> -genX(copy_fast_clear_dwords)(cmd_buffer, att_state->input.state,
> - iview->image,
> - VK_IMAGE_ASPECT_COLOR_BIT,
> - false /* copy to ss */);
> - }
> -  }
> -
> -  /* We assume that if we're starting a subpass, we're going to do some
> -   * rendering so we may end up with compressed data.
> -   */
> -  

Re: [Mesa-dev] [PATCH v3 11/18] anv/cmd_buffer: Decide whether or not to HiZ clear up-front

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:26PM -0800, Jason Ekstrand wrote:
> This moves the decision out of begin_subpass and into BeginRenderPass
> like the decision for color clears.  We use a similar name for the
> function for depth/stencil as for color even though no aux usage is
> really getting computed.
> 
> v2 (Jason Ekstrand):
>  - Don't always disable HiZ clears by accident
>  - Use the initial layout to decide whether to do fast clears
> 
> Reviewed-by: Nanley Chery 
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 107 
> +
>  1 file changed, 72 insertions(+), 35 deletions(-)

This still looks good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 10/18] anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:25PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_blorp.c   | 242 
> -
>  src/intel/vulkan/anv_private.h |  17 ++-
>  src/intel/vulkan/genX_cmd_buffer.c |  68 ++-
>  3 files changed, 186 insertions(+), 141 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index fd32227..6c0c858 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1136,143 +1136,6 @@ enum subpass_stage {
> SUBPASS_STAGE_RESOLVE,
>  };
>  
> -static bool
> -subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
> -{
> -   const struct anv_cmd_state *cmd_state = _buffer->state;
> -   uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
> -
> -   if (ds != VK_ATTACHMENT_UNUSED) {
> -  assert(ds < cmd_state->pass->attachment_count);
> -  if (cmd_state->attachments[ds].pending_clear_aspects)
> - return true;
> -   }
> -
> -   return false;
> -}
> -
> -void
> -anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
> -{
> -   const struct anv_cmd_state *cmd_state = _buffer->state;
> -   const VkRect2D render_area = cmd_buffer->state.render_area;
> -
> -
> -   if (!subpass_needs_clear(cmd_buffer))
> -  return;
> -
> -   /* Because this gets called within a render pass, we tell blorp not to
> -* trash our depth and stencil buffers.
> -*/
> -   struct blorp_batch batch;
> -   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
> -BLORP_BATCH_NO_EMIT_DEPTH_STENCIL);
> -
> -   VkClearRect clear_rect = {
> -  .rect = cmd_buffer->state.render_area,
> -  .baseArrayLayer = 0,
> -  .layerCount = cmd_buffer->state.framebuffer->layers,
> -   };
> -
> -   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> -
> -   const uint32_t ds = 
> cmd_state->subpass->depth_stencil_attachment.attachment;
> -   assert(ds == VK_ATTACHMENT_UNUSED || ds < 
> cmd_state->pass->attachment_count);
> -
> -   if (ds != VK_ATTACHMENT_UNUSED &&
> -   cmd_state->attachments[ds].pending_clear_aspects) {
> -
> -  VkClearAttachment clear_att = {
> - .aspectMask = cmd_state->attachments[ds].pending_clear_aspects,
> - .clearValue = cmd_state->attachments[ds].clear_value,
> -  };
> -
> -
> -  const uint8_t gen = cmd_buffer->device->info.gen;
> -  bool clear_with_hiz = gen >= 8 && cmd_state->attachments[ds].aux_usage 
> ==
> -ISL_AUX_USAGE_HIZ;
> -  const struct anv_image_view *iview = fb->attachments[ds];
> -
> -  if (clear_with_hiz) {
> - const bool clear_depth = clear_att.aspectMask &
> -  VK_IMAGE_ASPECT_DEPTH_BIT;
> - const bool clear_stencil = clear_att.aspectMask &
> -VK_IMAGE_ASPECT_STENCIL_BIT;
> -
> - /* Check against restrictions for depth buffer clearing. A great GPU
> -  * performance benefit isn't expected when using the HZ sequence for
> -  * stencil-only clears. Therefore, we don't emit a HZ op sequence 
> for
> -  * a stencil clear in addition to using the BLORP-fallback for 
> depth.
> -  */
> - if (clear_depth) {
> -if (!blorp_can_hiz_clear_depth(gen, iview->planes[0].isl.format,
> -   iview->image->samples,
> -   render_area.offset.x,
> -   render_area.offset.y,
> -   render_area.offset.x +
> -   render_area.extent.width,
> -   render_area.offset.y +
> -   render_area.extent.height)) {
> -   clear_with_hiz = false;
> -} else if (clear_att.clearValue.depthStencil.depth !=
> -   ANV_HZ_FC_VAL) {
> -   /* Don't enable fast depth clears for any color not equal to
> -* ANV_HZ_FC_VAL.
> -*/
> -   clear_with_hiz = false;
> -} else if (gen == 8 &&
> -   anv_can_sample_with_hiz(_buffer->device->info,
> -   iview->image)) {
> -   /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
> -* fast-cleared portion of a HiZ buffer. Testing has revealed
> -* that Gen8 only supports returning 0.0f. Gens prior to gen8 
> do
> -* not support this feature at all.
> -*/
> -   clear_with_hiz = false;
> -}
> - }
> -
> - if (clear_with_hiz) {
> -blorp_gen8_hiz_clear_attachments(, iview->image->samples,
> - render_area.offset.x,
> - 

Re: [Mesa-dev] [PATCH 3/3] svga: move duplicated code for setting fillmode/flatshade state

2018-02-14 Thread Charmaine Lee

For patch 2 and 3, Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Wednesday, February 14, 2018 1:15:14 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH 3/3] svga: move duplicated code for setting fillmode/flatshade 
state

Move the calls to svga_hwtnl_set_fillmode() and svga_hwtnl_set_flatshade()
out of the two retry_draw_*() functions to the svga_draw_vbo() function.
---
 src/gallium/drivers/svga/svga_pipe_draw.c | 30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c 
b/src/gallium/drivers/svga/svga_pipe_draw.c
index af53881..c73c406 100644
--- a/src/gallium/drivers/svga/svga_pipe_draw.c
+++ b/src/gallium/drivers/svga/svga_pipe_draw.c
@@ -64,16 +64,6 @@ retry_draw_range_elements(struct svga_context *svga,

SVGA_STATS_TIME_PUSH(svga_sws(svga), SVGA_STATS_TIME_DRAWELEMENTS);

-   svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
-
-   /** determine if flatshade is to be used after svga_update_state()
-*  in case the fragment shader is changed.
-*/
-   svga_hwtnl_set_flatshade(svga->hwtnl,
-svga->curr.rast->templ.flatshade ||
-is_using_flat_shading(svga),
-svga->curr.rast->templ.flatshade_first);
-
for (unsigned try = 0; try < 2; try++) {
   ret = svga_hwtnl_draw_range_elements(svga->hwtnl,
index_buffer, index_size,
@@ -100,16 +90,6 @@ retry_draw_arrays(struct svga_context *svga,

SVGA_STATS_TIME_PUSH(svga_sws(svga), SVGA_STATS_TIME_DRAWARRAYS);

-   svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
-
-   /** determine if flatshade is to be used after svga_update_state()
-*  in case the fragment shader is changed.
-*/
-   svga_hwtnl_set_flatshade(svga->hwtnl,
-svga->curr.rast->templ.flatshade ||
-is_using_flat_shading(svga),
-svga->curr.rast->templ.flatshade_first);
-
for (unsigned try = 0; try < 2; try++) {
   ret = svga_hwtnl_draw_arrays(svga->hwtnl, prim, start, count,
start_instance, instance_count);
@@ -230,6 +210,16 @@ svga_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
  assert(ret == PIPE_OK);
   }

+  svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
+
+  /** determine if flatshade is to be used after svga_update_state()
+   *  in case the fragment shader is changed.
+   */
+  svga_hwtnl_set_flatshade(svga->hwtnl,
+   svga->curr.rast->templ.flatshade ||
+   is_using_flat_shading(svga),
+   svga->curr.rast->templ.flatshade_first);
+
   if (info->index_size && indexbuf) {
  unsigned offset;

--
2.7.4

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


Re: [Mesa-dev] [PATCH 1/3] svga: call tgsi_scan_shader() for dummy shaders

2018-02-14 Thread Charmaine Lee

>From: Brian Paul 
>Sent: Wednesday, February 14, 2018 1:15 PM
>To: mesa-dev@lists.freedesktop.org
>Cc: Charmaine Lee; Neha Bhende
>Subject: [PATCH 1/3] svga: call tgsi_scan_shader() for dummy shaders

>If we fail to compile the normal VS or FS we fall back to a simple/
>dummy shader.  We need to rescan the the shader to update the shader
>info.  Otherwise, this can lead to further translations failures
>because the shader info doesn't match the actual shader.
>
>Found by adding some extra debug assertions in the state-update code
>while debugging something else.
>---
> src/gallium/drivers/svga/svga_state_fs.c | 2 ++
> src/gallium/drivers/svga/svga_state_vs.c | 2 ++
> 2 files changed, 4 insertions(+)

>diff --git a/src/gallium/drivers/svga/svga_state_fs.c 
>b/src/gallium/drivers/svga/svga_state_fs.c
>index 5e56899..f185a68 100644
>--- a/src/gallium/drivers/svga/svga_state_fs.c
>+++ b/src/gallium/drivers/svga/svga_state_fs.c
>@@ -115,6 +115,8 @@ get_compiled_dummy_shader(struct svga_context *svga,
>FREE((void *) fs->base.tokens);
>fs->base.tokens = dummy;

>+   tgsi_scan_shader(fs->base.tokens, >base.info);
>+

To be complete, we need to get the generic_inputs mask and call 
svga_remap_generics again.


>variant = translate_fragment_program(svga, fs, key);
>return variant;
> }
>diff --git a/src/gallium/drivers/svga/svga_state_vs.c 
>b/src/gallium/drivers/svga/svga_state_vs.c
>index a0ab868..1dcc161 100644
>--- a/src/gallium/drivers/svga/svga_state_vs.c
>+++ b/src/gallium/drivers/svga/svga_state_vs.c
>@@ -105,6 +105,8 @@ get_compiled_dummy_vertex_shader(struct svga_context *svga,
>FREE((void *) vs->base.tokens);
>vs->base.tokens = dummy;

>+   tgsi_scan_shader(vs->base.tokens, >base.info);
>+
Need to set the generic_outputs mask again.


>variant = translate_vertex_program(svga, vs, key);
>return variant;
>

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


Re: [Mesa-dev] [PATCH 16/16] i965/icl: Add render target flush after uploading binding table

2018-02-14 Thread Anuj Phogat
On Tue, Feb 13, 2018 at 4:17 PM, Kenneth Graunke  wrote:
> On Tuesday, February 13, 2018 11:15:16 AM PST Anuj Phogat wrote:
>> From PIPE_CONTROL command description in gfxspecs:
>>
>> "Whenever a Binding Table Index (BTI) used by a Render Taget Message
>>  points to a different RENDER_SURFACE_STATE, SW must issue a Render
>>  Target Cache Flush by enabling this bit. When render target flush
>>  is set due to new association of BTI, PS Scoreboard Stall bit must
>>  be set in this packet."
>>
>> Fixes a fulsim error and a GPU hang described in below JIRA.
>>
>> JIRA: MD5-322
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/mesa/drivers/dri/i965/brw_binding_tables.c | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c 
>> b/src/mesa/drivers/dri/i965/brw_binding_tables.c
>> index 73f5e56010..170daebc24 100644
>> --- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
>> +++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
>> @@ -93,6 +93,20 @@ brw_upload_binding_table(struct brw_context *brw,
>>OUT_BATCH(stage_state->bind_bo_offset);
>>ADVANCE_BATCH();
>> }
>> +
>> +   /* From PIPE_CONTROL command description in gfxspecs:
>> +
>> +  "Whenever a Binding Table Index (BTI) used by a Render Taget Message
>> +   points to a different RENDER_SURFACE_STATE, SW must issue a Render
>> +   Target Cache Flush by enabling this bit. When render target flush
>> +   is set due to new association of BTI, PS Scoreboard Stall bit must
>> +   be set in this packet."
>> +   */
>> +   if (devinfo->gen >= 11) {
>> +  brw_emit_pipe_control_flush(brw,
>> +  PIPE_CONTROL_RENDER_TARGET_FLUSH |
>> +  PIPE_CONTROL_STALL_AT_SCOREBOARD);
>> +   }
>>  }
>>
>>  /**
>>
>
> This is overkill.  It'll do a RT flush when we change the binding
> tables in any stage, for any reason.  Only the pixel shader's binding
> tables have render target surfaces.  And, we might change other surfaces
> (textures, UBOs, etc) without changing the render targets.
>
> I would move this to update_renderbuffer_surfaces() in
> brw_wm_surface_state.c.

I agree. I wasn't very sure either if this is the right place to do
it. Thanks for the suggestion. I'll verify if it still fixes the fulsim
error and gpu hang.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 04/18] anv: Use framebuffer layers for implicit subpass transitions

2018-02-14 Thread Nanley Chery
On Wed, Feb 14, 2018 at 12:16:19PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

We should probabably add:

Fixes: de3be618016 "anv/cmd_buffer: Rework aux tracking"

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 8b1816a..a16b742 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3324,7 +3324,7 @@ cmd_buffer_subpass_transition_layouts(struct 
> anv_cmd_buffer * const cmd_buffer,
>   iview->planes[0].isl.base_level);
>   } else {
>  base_layer = iview->planes[0].isl.base_array_layer;
> -layer_count = iview->planes[0].isl.array_len;
> +layer_count = cmd_state->framebuffer->layers;
>   }
>  
>   transition_color_buffer(cmd_buffer, image, 
> VK_IMAGE_ASPECT_COLOR_BIT,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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] i965: Drop EXEC_OBJECT_CAPTURE defines.

2018-02-14 Thread Kenneth Graunke
These only existed to avoid making people update libdrm for new uABI
headers.  A while ago we imported those headers into the Mesa repo,
so the dependency is gone and these are no longer useful.
---
 src/mesa/drivers/dri/i965/brw_bufmgr.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index a3745d6667a..005ff19798e 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -120,9 +120,6 @@ struct brw_bo {
int refcount;
const char *name;
 
-#ifndef EXEC_OBJECT_CAPTURE
-#define EXEC_OBJECT_CAPTURE(1<<7)
-#endif
uint64_t kflags;
 
/**
-- 
2.16.1

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


Re: [Mesa-dev] [PATCH] radv: compact varyings after removing unused ones

2018-02-14 Thread Timothy Arceri

On 15/02/18 01:10, Samuel Pitoiset wrote:

It makes no sense to compact before, and the description of
nir_compact_varyings() confirms that.


Reviewed-by: Timothy Arceri 

Your right this seems to be in the wrong place. There was a lot of 
restructuring around the time this landed so it seems to have been moved 
to the wrong location at some point. The original commit message (below) 
records a performance improvement it might be good to check if this 
improves things further.


SaschaWillems Vulkan demo tessellation:

~4000fps -> ~4600fps





Polaris10:
Totals from affected shaders:
SGPRS: 106000 -> 105600 (-0.38 %)
VGPRS: 70704 -> 70640 (-0.09 %)
Spilled SGPRs: 892 -> 878 (-1.57 %)
Code Size: 2826240 -> 2812476 (-0.49 %) bytes
Max Waves: 15909 -> 15899 (-0.06 %)

Vega10:
Totals from affected shaders:
SGPRS: 103520 -> 103664 (0.14 %)
VGPRS: 70776 -> 70808 (0.05 %)
Spilled SGPRs: 740 -> 722 (-2.43 %)
Code Size: 2786076 -> 2772004 (-0.51 %) bytes
Max Waves: 18026 -> 18010 (-0.09 %)

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_pipeline.c | 9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 8f872e7c14..06e1ec5ae3 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1525,6 +1525,9 @@ radv_link_shaders(struct radv_pipeline *pipeline, 
nir_shader **shaders)
   ordered_shaders[i - 
1]);
  
  		if (progress) {

+   nir_compact_varyings(ordered_shaders[i],
+ordered_shaders[i - 1], true);
+
nir_lower_global_vars_to_local(ordered_shaders[i]);
radv_optimize_nir(ordered_shaders[i]);
nir_lower_global_vars_to_local(ordered_shaders[i - 1]);
@@ -1715,7 +1718,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
last = i;
}
  
-	int prev = -1;

for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
const VkPipelineShaderStageCreateInfo *stage = pStages[i];
  
@@ -1746,11 +1748,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,

nir_lower_io_to_scalar_early(nir[i], mask);
radv_optimize_nir(nir[i]);
}
-
-   if (prev != -1) {
-   nir_compact_varyings(nir[prev], nir[i], true);
-   }
-   prev = i;
}
  
  	if (nir[MESA_SHADER_TESS_CTRL]) {



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


Re: [Mesa-dev] [PATCH 14/16] i965/icl: Disable HiZ surface sampling

2018-02-14 Thread Anuj Phogat
On Tue, Feb 13, 2018 at 4:25 PM, Kenneth Graunke  wrote:
> On Tuesday, February 13, 2018 11:15:14 AM PST Anuj Phogat wrote:
>> On gen11+ AUX_HIZ is not a supported value for surfaces being
>> sampled by the 3D sampler.
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> index f27d559149..9c6f166677 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -1912,9 +1912,10 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
>> const struct gen_device_info *devinfo = >screen->devinfo;
>>
>> /* It's unclear how well supported sampling from the hiz buffer is on 
>> GEN8,
>> -* so keep things conservative for now and never enable it unless we're 
>> SKL+.
>> +* so keep things conservative for now and never enable it unless we're 
>> GEN9+.
>> +* Also, disable the sampling from the hiz buffer for GEN11+.
>>  */
>> -   if (devinfo->gen < 9) {
>> +   if (devinfo->gen < 9 || devinfo->gen > 10) {
>>return false;
>> }
>
> Sad to see this go :(
>
> I think we should add a devinfo->has_aux_hiz boolean, set it on Gen9-10,
> leave it false on Gen8 with this "it's unclear how well supported..."
> comment, then change this code to use the flag.
>
> That will disable it for Gen11 but gives us a bit more flexibility.

Sounds good. I think 'has_sample_with_hiz' a better name for the flag?
has_aux_hiz can be easily misinterpreted as a flag to check if
mt->hiz_buf is valid or not.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] svga: s/unsigned/enum pipe_shader_type/

2018-02-14 Thread Neha Bhende
Looks good.


Reviewed-by: Neha Bhende


Regards,

Neha


From: Brian Paul 
Sent: Wednesday, February 14, 2018 1:53:52 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: s/unsigned/enum pipe_shader_type/

---
 src/gallium/drivers/svga/svga_tgsi.c| 3 ++-
 src/gallium/drivers/svga/svga_tgsi.h| 5 +++--
 src/gallium/drivers/svga/svga_tgsi_vgpu10.c | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi.c 
b/src/gallium/drivers/svga/svga_tgsi.c
index 0b2d8af..8819313 100644
--- a/src/gallium/drivers/svga/svga_tgsi.c
+++ b/src/gallium/drivers/svga/svga_tgsi.c
@@ -168,7 +168,8 @@ svga_shader_emit_header(struct svga_shader_emitter *emit)
 struct svga_shader_variant *
 svga_tgsi_vgpu9_translate(struct svga_context *svga,
   const struct svga_shader *shader,
-  const struct svga_compile_key *key, unsigned unit)
+  const struct svga_compile_key *key,
+  enum pipe_shader_type unit)
 {
struct svga_shader_variant *variant = NULL;
struct svga_shader_emitter emit;
diff --git a/src/gallium/drivers/svga/svga_tgsi.h 
b/src/gallium/drivers/svga/svga_tgsi.h
index 2581135..e986011 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -65,13 +65,14 @@ static inline void svga_generate_vdecl_semantics( unsigned 
idx,
 struct svga_shader_variant *
 svga_tgsi_vgpu9_translate(struct svga_context *svga,
   const struct svga_shader *shader,
-  const struct svga_compile_key *key, unsigned unit);
+  const struct svga_compile_key *key,
+  enum pipe_shader_type unit);

 struct svga_shader_variant *
 svga_tgsi_vgpu10_translate(struct svga_context *svga,
const struct svga_shader *shader,
const struct svga_compile_key *key,
-   unsigned unit);
+   enum pipe_shader_type unit);

 boolean svga_shader_verify(const uint32_t *tokens, unsigned nr_tokens);

diff --git a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c 
b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
index 73aa78b..4d0834b 100644
--- a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
@@ -6484,7 +6484,7 @@ struct svga_shader_variant *
 svga_tgsi_vgpu10_translate(struct svga_context *svga,
const struct svga_shader *shader,
const struct svga_compile_key *key,
-   unsigned unit)
+   enum pipe_shader_type unit)
 {
struct svga_shader_variant *variant = NULL;
struct svga_shader_emitter_v10 *emit;
--
2.7.4

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


[Mesa-dev] [PATCH] svga: s/unsigned/enum pipe_shader_type/

2018-02-14 Thread Brian Paul
---
 src/gallium/drivers/svga/svga_tgsi.c| 3 ++-
 src/gallium/drivers/svga/svga_tgsi.h| 5 +++--
 src/gallium/drivers/svga/svga_tgsi_vgpu10.c | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi.c 
b/src/gallium/drivers/svga/svga_tgsi.c
index 0b2d8af..8819313 100644
--- a/src/gallium/drivers/svga/svga_tgsi.c
+++ b/src/gallium/drivers/svga/svga_tgsi.c
@@ -168,7 +168,8 @@ svga_shader_emit_header(struct svga_shader_emitter *emit)
 struct svga_shader_variant *
 svga_tgsi_vgpu9_translate(struct svga_context *svga,
   const struct svga_shader *shader,
-  const struct svga_compile_key *key, unsigned unit)
+  const struct svga_compile_key *key,
+  enum pipe_shader_type unit)
 {
struct svga_shader_variant *variant = NULL;
struct svga_shader_emitter emit;
diff --git a/src/gallium/drivers/svga/svga_tgsi.h 
b/src/gallium/drivers/svga/svga_tgsi.h
index 2581135..e986011 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -65,13 +65,14 @@ static inline void svga_generate_vdecl_semantics( unsigned 
idx,
 struct svga_shader_variant *
 svga_tgsi_vgpu9_translate(struct svga_context *svga,
   const struct svga_shader *shader,
-  const struct svga_compile_key *key, unsigned unit);
+  const struct svga_compile_key *key,
+  enum pipe_shader_type unit);
 
 struct svga_shader_variant *
 svga_tgsi_vgpu10_translate(struct svga_context *svga,
const struct svga_shader *shader,
const struct svga_compile_key *key,
-   unsigned unit);
+   enum pipe_shader_type unit);
 
 boolean svga_shader_verify(const uint32_t *tokens, unsigned nr_tokens);
 
diff --git a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c 
b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
index 73aa78b..4d0834b 100644
--- a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
@@ -6484,7 +6484,7 @@ struct svga_shader_variant *
 svga_tgsi_vgpu10_translate(struct svga_context *svga,
const struct svga_shader *shader,
const struct svga_compile_key *key,
-   unsigned unit)
+   enum pipe_shader_type unit)
 {
struct svga_shader_variant *variant = NULL;
struct svga_shader_emitter_v10 *emit;
-- 
2.7.4

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


[Mesa-dev] [PATCH 08/15] glsl: Switch ast_type_qualifier to a 128-bit bitset.

2018-02-14 Thread Francisco Jerez
This should end the drought of bits in the ast_type_qualifier object.
The bitset_t type works pretty much as a drop-in replacement for the
current uint64_t bitset.

The only catch is that the bitset_t type as defined in the previous
commit doesn't have a trivial constructor (because it has a
user-defined constructor), so it cannot be used as union member
without providing a user-defined constructor for the union (which
causes it in turn to be non-trivially constructible).  This annoyance
could be easily addressed in C++11 by declaring the default
constructor of bitset_t to be the implicitly defined one -- IMO one
more reason to drop support for GCC 4.2-4.3.

The other minor change was required because glsl_parser_extras.cpp was
hard-coding the type of bitset temporaries as uint64_t, which (unlike
would have been the case if the uint64_t had been replaced with
e.g. an __int128) would otherwise have caused a build failure, because
the boolean conversion operator of bitset_t is marked explicit (if
C++11 is available), so the bitset won't be silently truncated down to
1 bit in order to use it to initialize the uint64_t temporaries
(yikes).
---
 src/compiler/glsl/ast.h  | 8 ++--
 src/compiler/glsl/glsl_parser.yy | 1 +
 src/compiler/glsl/glsl_parser_extras.cpp | 4 ++--
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index eee22482812..b0db14e20b6 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -28,6 +28,7 @@
 #include "list.h"
 #include "glsl_parser_extras.h"
 #include "compiler/glsl_types.h"
+#include "util/bitset.h"
 
 struct _mesa_glsl_parse_state;
 
@@ -473,8 +474,11 @@ enum {
 
 struct ast_type_qualifier {
DECLARE_RALLOC_CXX_OPERATORS(ast_type_qualifier);
+   DECLARE_BITSET_T(bitset_t, 128);
+
+   union flags {
+  flags() {}
 
-   union {
   struct {
 unsigned invariant:1;
  unsigned precise:1;
@@ -636,7 +640,7 @@ struct ast_type_qualifier {
   q;
 
   /** \brief Set of flags, accessed as a bitmask. */
-  uint64_t i;
+  bitset_t i;
} flags;
 
/** Precision of the type (highp/medium/lowp). */
diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index 19147c7a3ec..4faf9602a08 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -96,6 +96,7 @@ static bool match_layout_qualifier(const char *s1, const char 
*s2,
 %parse-param {struct _mesa_glsl_parse_state *state}
 
 %union {
+   YYSTYPE() {}
int n;
int64_t n64;
float real;
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index d99916d8ada..57589843776 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -1010,7 +1010,7 @@ _mesa_ast_process_interface_block(YYLTYPE *locp,
"an instance name are not allowed");
}
 
-   uint64_t interface_type_mask;
+   ast_type_qualifier::bitset_t interface_type_mask;
struct ast_type_qualifier temp_type_qualifier;
 
/* Get a bitmask containing only the in/out/uniform/buffer
@@ -1029,7 +1029,7 @@ _mesa_ast_process_interface_block(YYLTYPE *locp,
 * production rule guarantees that only one bit will be set (and
 * it will be in/out/uniform).
 */
-   uint64_t block_interface_qualifier = q.flags.i;
+   ast_type_qualifier::bitset_t block_interface_qualifier = q.flags.i;
 
block->default_layout.flags.i |= block_interface_qualifier;
 
-- 
2.16.1

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


[Mesa-dev] [PATCH 15/15] mesa: Expose EXT_shader_framebuffer_fetch(_non_coherent) on desktop and embedded GL.

2018-02-14 Thread Francisco Jerez
---
 docs/relnotes/18.1.0.html| 2 ++
 src/mesa/main/extensions_table.h | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/relnotes/18.1.0.html b/docs/relnotes/18.1.0.html
index b8a0cd0d02c..f5564e9b8fe 100644
--- a/docs/relnotes/18.1.0.html
+++ b/docs/relnotes/18.1.0.html
@@ -46,6 +46,8 @@ Note: some of the new features are only available with 
certain drivers.
 
 GL_EXT_semaphore on radeonsi
 GL_EXT_semaphore_fd on radeonsi
+GL_EXT_shader_framebuffer_fetch on i965 on desktop GL (GLES was already 
supported)
+GL_EXT_shader_framebuffer_fetch_non_coherent on i965
 
 
 Bug fixes
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 7de1a6cd5dc..5d51bc1e4ec 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -251,7 +251,8 @@ EXT(EXT_semaphore   , EXT_semaphore
 EXT(EXT_semaphore_fd, EXT_semaphore_fd 
  , GLL, GLC,  x , ES2, 2017)
 EXT(EXT_separate_shader_objects , dummy_true   
  ,  x ,  x ,  x , ES2, 2013)
 EXT(EXT_separate_specular_color , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
-EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch 
  ,  x ,  x ,  x , ES2, 2013)
+EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch 
  , GLL, GLC,  x , ES2, 2013)
+EXT(EXT_shader_framebuffer_fetch_non_coherent, 
EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC,  x, ES2, 2018)
 EXT(EXT_shader_integer_mix  , EXT_shader_integer_mix   
  , GLL, GLC,  x ,  30, 2013)
 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)
-- 
2.16.1

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


[Mesa-dev] [PATCH 07/15] util/bitset: Add C++ wrapper for static-size bitsets.

2018-02-14 Thread Francisco Jerez
---
 src/util/bitset.h | 114 ++
 1 file changed, 114 insertions(+)

diff --git a/src/util/bitset.h b/src/util/bitset.h
index 2404ce7f630..7bb5f3c83cf 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -132,4 +132,118 @@ __bitset_next_set(unsigned i, BITSET_WORD *tmp,
for (__tmp = *(__set), __i = 0; \
 (__i = __bitset_next_set(__i, &__tmp, __set, __size)) < __size;)
 
+#ifdef __cplusplus
+
+/**
+ * Simple C++ wrapper of a bitset type of static size, with value semantics
+ * and basic bitwise arithmetic operators.  The operators defined below are
+ * expected to have the same semantics as the same operator applied to other
+ * fundamental integer types.  T is the name of the struct to instantiate
+ * it as, and N is the number of bits in the bitset.
+ */
+#define DECLARE_BITSET_T(T, N) struct T {   \
+  /* XXX - Replace this with an implicitly-defined  \
+   * constructor when support for C++11 defaulted   \
+   * constructors can be assumed (available on GCC 4.4 and  \
+   * later) in order to make the object trivially   \
+   * constructible like a fundamental integer type for  \
+   * convenience.   \
+   */   \
+  T()   \
+  { \
+  } \
+\
+  T(BITSET_WORD x)  \
+  { \
+ for (unsigned i = 0; i < BITSET_WORDS(N); i++, x = 0)  \
+words[i] = x;   \
+  } \
+\
+  EXPLICIT_CONVERSION   \
+  operator bool() const \
+  { \
+ for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
+if (words[i])   \
+   return true; \
+ return false;  \
+  } \
+\
+  friend bool   \
+  operator==(const T , const T )\
+  { \
+ return BITSET_EQUAL(b.words, c.words); \
+  } \
+\
+  friend bool   \
+  operator!=(const T , const T )\
+  { \
+ return !(b == c);  \
+  } \
+\
+  friend T  \
+  operator~(const T ) \
+  { \
+ T c;   \
+ for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
+c.words[i] = ~b.words[i];   \
+ return c;  \
+  } \
+\
+  T &   \
+  operator|=(const T )\
+  { \
+ for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
+words[i] |= b.words[i]; \
+ return *this;  \
+  } \
+\
+  friend T  \
+  operator|(const T , const T ) \
+  { \
+ T d = b;   \
+ d |= c;\
+ return d;  \
+  }   

[Mesa-dev] [PATCH 09/15] glsl: Replace MESA_shader_framebuffer_fetch extension flags with EXT ones.

2018-02-14 Thread Francisco Jerez
---
 src/compiler/glsl/glsl_parser_extras.cpp | 1 +
 src/compiler/glsl/glsl_parser_extras.h   | 9 +++--
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 57589843776..68ad54db8ab 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -706,6 +706,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT_AEP(EXT_primitive_bounding_box),
EXT(EXT_separate_shader_objects),
EXT(EXT_shader_framebuffer_fetch),
+   EXT(EXT_shader_framebuffer_fetch_non_coherent),
EXT(EXT_shader_integer_mix),
EXT_AEP(EXT_shader_io_blocks),
EXT(EXT_shader_samples_identical),
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index 508befd4606..23b454b02c9 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -317,8 +317,7 @@ struct _mesa_glsl_parse_state {
bool has_framebuffer_fetch() const
{
   return EXT_shader_framebuffer_fetch_enable ||
- MESA_shader_framebuffer_fetch_enable ||
- MESA_shader_framebuffer_fetch_non_coherent_enable;
+ EXT_shader_framebuffer_fetch_non_coherent_enable;
}
 
bool has_texture_cube_map_array() const
@@ -780,6 +779,8 @@ struct _mesa_glsl_parse_state {
bool EXT_separate_shader_objects_warn;
bool EXT_shader_framebuffer_fetch_enable;
bool EXT_shader_framebuffer_fetch_warn;
+   bool EXT_shader_framebuffer_fetch_non_coherent_enable;
+   bool EXT_shader_framebuffer_fetch_non_coherent_warn;
bool EXT_shader_integer_mix_enable;
bool EXT_shader_integer_mix_warn;
bool EXT_shader_io_blocks_enable;
@@ -798,10 +799,6 @@ struct _mesa_glsl_parse_state {
bool EXT_texture_cube_map_array_warn;
bool INTEL_conservative_rasterization_enable;
bool INTEL_conservative_rasterization_warn;
-   bool MESA_shader_framebuffer_fetch_enable;
-   bool MESA_shader_framebuffer_fetch_warn;
-   bool MESA_shader_framebuffer_fetch_non_coherent_enable;
-   bool MESA_shader_framebuffer_fetch_non_coherent_warn;
bool MESA_shader_integer_functions_enable;
bool MESA_shader_integer_functions_warn;
bool NV_image_formats_enable;
-- 
2.16.1

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


[Mesa-dev] [PATCH 10/15] glsl: Initialize ir_variable_data::fb_fetch_output earlier for GL(ES) 2.

2018-02-14 Thread Francisco Jerez
At the same point where it is initialized on GL(ES) 3.0+ so we can
implement some common layout qualifier handling in a future commit.
Until now the fb_fetch_output flag would be inherited from the
original implicit gl_LastFragData declaration at a later point in the
AST to GLSL IR translation.
---
 src/compiler/glsl/ast_to_hir.cpp | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 41e74815f31..966450ca78b 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3994,8 +3994,13 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
else if (qual->flags.q.shared_storage)
   var->data.mode = ir_var_shader_shared;
 
-   var->data.fb_fetch_output = state->stage == MESA_SHADER_FRAGMENT &&
-   qual->flags.q.in && qual->flags.q.out;
+   if (!is_parameter && state->has_framebuffer_fetch() &&
+   state->stage == MESA_SHADER_FRAGMENT) {
+  if (state->is_version(130, 300))
+ var->data.fb_fetch_output = qual->flags.q.in && qual->flags.q.out;
+  else
+ var->data.fb_fetch_output = (strcmp(var->name, "gl_LastFragData") == 
0);
+   }
 
if (!is_parameter && is_varying_var(var, state->stage)) {
   /* User-defined ins/outs are not permitted in compute shaders. */
-- 
2.16.1

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


[Mesa-dev] [PATCH 11/15] glsl: Allow layout token for EXT_shader_framebuffer_fetch_non_coherent.

2018-02-14 Thread Francisco Jerez
EXT_shader_framebuffer_fetch_non_coherent requires layout qualifiers
even on GL(ES) 2.
---
 src/compiler/glsl/glsl_lexer.ll | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 4b36574b73a..2c2098129fd 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -500,7 +500,8 @@ layout  {
  || yyextra->ARB_fragment_coord_conventions_enable
   || yyextra->ARB_shading_language_420pack_enable
   || yyextra->ARB_compute_shader_enable
-  || yyextra->ARB_tessellation_shader_enable) {
+  || yyextra->ARB_tessellation_shader_enable
+  || 
yyextra->EXT_shader_framebuffer_fetch_non_coherent_enable) {
  return LAYOUT_TOK;
   } else {
  return classify_identifier(yyextra, yytext, yyleng, 
yylval);
-- 
2.16.1

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


[Mesa-dev] [PATCH 12/15] glsl: Add support for the framebuffer fetch layout(noncoherent) qualifier.

2018-02-14 Thread Francisco Jerez
This allows the application to request framebuffer fetch coherency
with per-fragment output granularity.  Coherent framebuffer fetch
outputs (which is the default if no qualifier is present for
compatibility with older versions of the EXT_shader_framebuffer_fetch
extension) will have ir_variable_data::memory_coherent set to true.
---
 src/compiler/glsl/ast.h |  5 
 src/compiler/glsl/ast_to_hir.cpp| 45 +
 src/compiler/glsl/ast_type.cpp  |  6 +++--
 src/compiler/glsl/builtin_variables.cpp |  1 +
 src/compiler/glsl/glsl_parser.yy|  6 +
 5 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index b0db14e20b6..ba025266bd7 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -635,6 +635,11 @@ struct ast_type_qualifier {
  unsigned bound_sampler:1;
  unsigned bound_image:1;
  /** \} */
+
+ /** \name Layout qualifiers for 
GL_EXT_shader_framebuffer_fetch_non_coherent */
+ /** \{ */
+ unsigned non_coherent:1;
+ /** \} */
   }
   /** \brief Set of flags, accessed by name. */
   q;
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 966450ca78b..5acbaa321a9 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -2008,6 +2008,20 @@ ast_expression::do_hir(exec_list *instructions,
 _mesa_glsl_warning(, state, "`%s' used uninitialized",
this->primary_expression.identifier);
  }
+
+ /* From the EXT_shader_framebuffer_fetch spec:
+  *
+  *   "Unless the GL_EXT_shader_framebuffer_fetch extension has been
+  *enabled in addition, it's an error to use gl_LastFragData if it
+  *hasn't been explicitly redeclared with layout(noncoherent)."
+  */
+ if (var->data.fb_fetch_output && var->data.memory_coherent &&
+ !state->EXT_shader_framebuffer_fetch_enable) {
+_mesa_glsl_error(, state,
+ "invalid use of framebuffer fetch output not "
+ "qualified with layout(noncoherent)");
+ }
+
   } else {
  _mesa_glsl_error(& loc, state, "`%s' undeclared",
   this->primary_expression.identifier);
@@ -4002,6 +4016,33 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  var->data.fb_fetch_output = (strcmp(var->name, "gl_LastFragData") == 
0);
}
 
+   if (var->data.fb_fetch_output) {
+  var->data.memory_coherent = !qual->flags.q.non_coherent;
+
+  /* From the EXT_shader_framebuffer_fetch spec:
+   *
+   *   "It is an error to declare an inout fragment output not qualified
+   *with layout(noncoherent) if the GL_EXT_shader_framebuffer_fetch
+   *extension hasn't been enabled."
+   */
+  if (var->data.memory_coherent &&
+  !state->EXT_shader_framebuffer_fetch_enable)
+ _mesa_glsl_error(loc, state,
+  "invalid declaration of framebuffer fetch output not 
"
+  "qualified with layout(noncoherent)");
+
+   } else {
+  /* From the EXT_shader_framebuffer_fetch spec:
+   *
+   *   "Fragment outputs declared inout may specify the following layout
+   *qualifier: [...] noncoherent"
+   */
+  if (qual->flags.q.non_coherent)
+ _mesa_glsl_error(loc, state,
+  "invalid layout(noncoherent) qualifier not part of "
+  "framebuffer fetch output declaration");
+   }
+
if (!is_parameter && is_varying_var(var, state->stage)) {
   /* User-defined ins/outs are not permitted in compute shaders. */
   if (state->stage == MESA_SHADER_COMPUTE) {
@@ -4268,8 +4309,12 @@ get_variable_being_redeclared(ir_variable **var_ptr, 
YYLTYPE loc,
*   "By default, gl_LastFragData is declared with the mediump precision
*qualifier. This can be changed by redeclaring the corresponding
*variables with the desired precision qualifier."
+   *
+   *   "Fragment shaders may specify the following layout qualifier only 
for
+   *redeclaring the built-in gl_LastFragData array [...]: noncoherent"
*/
   earlier->data.precision = var->data.precision;
+  earlier->data.memory_coherent = var->data.memory_coherent;
 
} else if (earlier->data.how_declared == ir_var_declared_implicitly &&
   state->allow_builtin_variable_redeclaration) {
diff --git a/src/compiler/glsl/ast_type.cpp b/src/compiler/glsl/ast_type.cpp
index e9d60de5baf..14ea936f244 100644
--- a/src/compiler/glsl/ast_type.cpp
+++ b/src/compiler/glsl/ast_type.cpp
@@ -270,6 +270,7 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
input_layout_mask.flags.q.precise = 1;
input_layout_mask.flags.q.sample = 1;

[Mesa-dev] [PATCH 14/15] glsl: Silence warnings when reading from a framebuffer fetch output.

2018-02-14 Thread Francisco Jerez
Framebuffer fetch outputs are implicitly initialized upon entry to the
fragment shader.
---
 src/compiler/glsl/ast_to_hir.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 5acbaa321a9..badfbe6816f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -4017,6 +4017,7 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
}
 
if (var->data.fb_fetch_output) {
+  var->data.assigned = true;
   var->data.memory_coherent = !qual->flags.q.non_coherent;
 
   /* From the EXT_shader_framebuffer_fetch spec:
-- 
2.16.1

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


[Mesa-dev] [PATCH 04/15] glapi: Update XML for last revision of EXT_shader_framebuffer_fetch.

2018-02-14 Thread Francisco Jerez
Desktop GL is now supported, and there is an additional entry-point
for EXT_shader_framebuffer_fetch_non_coherent.
---
 src/mapi/glapi/gen/es_EXT.xml | 5 -
 src/mapi/glapi/gen/gl_API.xml | 6 ++
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index e5104259b62..a53fcd1e8ab 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -842,11 +842,6 @@
 
 
 
-
-
-
-
-
 
 
 
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index d13a3bfd83d..38c19210478 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -12886,6 +12886,12 @@
 
 http://www.w3.org/2001/XInclude"/>
 
+
+
+
+
+
+
 
 
 
-- 
2.16.1

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


[Mesa-dev] [PATCH 03/15] mesa: Rename MESA_shader_framebuffer_fetch gl_extensions bits to EXT.

2018-02-14 Thread Francisco Jerez
The changes I had originally planned for the MESA_shader_framebuffer_fetch
extension have been merged into the EXT spec, there's no point in keeping
MESA_shader_framebuffer_fetch extension enables.
---
 src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
 src/mesa/drivers/dri/i965/brw_program.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_wm.c   | 4 ++--
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
 src/mesa/drivers/dri/i965/intel_extensions.c | 4 ++--
 src/mesa/main/barrier.c  | 2 +-
 src/mesa/main/extensions_table.h | 2 +-
 src/mesa/main/get.c  | 2 +-
 src/mesa/main/get_hash_params.py | 7 +++
 src/mesa/main/mtypes.h   | 4 ++--
 10 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 50cf8b12c74..299e7f929e7 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -513,7 +513,7 @@ brw_predraw_resolve_framebuffer(struct brw_context *brw,
}
 
/* Resolve color buffers for non-coherent framebuffer fetch. */
-   if (!ctx->Extensions.MESA_shader_framebuffer_fetch &&
+   if (!ctx->Extensions.EXT_shader_framebuffer_fetch &&
ctx->FragmentProgram._Current &&
ctx->FragmentProgram._Current->info.outputs_read) {
   const struct gl_framebuffer *fb = ctx->DrawBuffer;
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index cd19db9f37c..a85a0c530ef 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -318,7 +318,7 @@ brw_framebuffer_fetch_barrier(struct gl_context *ctx)
struct brw_context *brw = brw_context(ctx);
const struct gen_device_info *devinfo = >screen->devinfo;
 
-   if (!ctx->Extensions.MESA_shader_framebuffer_fetch) {
+   if (!ctx->Extensions.EXT_shader_framebuffer_fetch) {
   if (devinfo->gen >= 6) {
  brw_emit_pipe_control_flush(brw,
  PIPE_CONTROL_RENDER_TARGET_FLUSH |
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index cfc2d47a679..68d4ab88d77 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -573,7 +573,7 @@ brw_wm_populate_key(struct brw_context *brw, struct 
brw_wm_prog_key *key)
key->program_string_id = fp->id;
 
/* Whether reads from the framebuffer should behave coherently. */
-   key->coherent_fb_fetch = ctx->Extensions.MESA_shader_framebuffer_fetch;
+   key->coherent_fb_fetch = ctx->Extensions.EXT_shader_framebuffer_fetch;
 }
 
 void
@@ -645,7 +645,7 @@ brw_fs_precompile(struct gl_context *ctx, struct gl_program 
*prog)
key.program_string_id = bfp->id;
 
/* Whether reads from the framebuffer should behave coherently. */
-   key.coherent_fb_fetch = ctx->Extensions.MESA_shader_framebuffer_fetch;
+   key.coherent_fb_fetch = ctx->Extensions.EXT_shader_framebuffer_fetch;
 
uint32_t old_prog_offset = brw->wm.base.prog_offset;
struct brw_stage_prog_data *old_prog_data = brw->wm.base.prog_data;
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 6b53e744dc9..50086710d83 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -1002,7 +1002,7 @@ update_renderbuffer_read_surfaces(struct brw_context *brw)
   brw_wm_prog_data(brw->wm.base.prog_data);
 
if (wm_prog_data->has_render_target_reads &&
-   !ctx->Extensions.MESA_shader_framebuffer_fetch) {
+   !ctx->Extensions.EXT_shader_framebuffer_fetch) {
   /* _NEW_BUFFERS */
   const struct gl_framebuffer *fb = ctx->DrawBuffer;
 
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index cc961e051fd..c92b5fd2196 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -153,7 +153,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.MESA_shader_integer_functions = ctx->Const.GLSLVersion >= 
130;
 
if (devinfo->is_g4x || devinfo->gen >= 5) {
-  ctx->Extensions.MESA_shader_framebuffer_fetch_non_coherent = true;
+  ctx->Extensions.EXT_shader_framebuffer_fetch_non_coherent = true;
   ctx->Extensions.KHR_blend_equation_advanced = true;
}
 
@@ -291,7 +291,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx->Extensions.KHR_texture_compression_astc_ldr = true;
   ctx->Extensions.KHR_texture_compression_astc_sliced_3d = true;
   ctx->Extensions.INTEL_conservative_rasterization = true;
-  ctx->Extensions.MESA_shader_framebuffer_fetch = true;
+  ctx->Extensions.EXT_shader_framebuffer_fetch = true;
   ctx->Extensions.ARB_post_depth_coverage = true;
}
 
diff --git a/src/mesa/main/barrier.c 

[Mesa-dev] [PATCH 02/15] mesa: Rename dd_function_table::BlendBarrier to match latest EXT spec.

2018-02-14 Thread Francisco Jerez
This GL entry point was renamed to glFramebufferFetchBarrier() in the
EXT extension on request from Khronos members.  Update the Mesa
codebase to match the latest spec.
---
 src/mesa/drivers/dri/i965/brw_program.c   | 4 ++--
 src/mesa/main/barrier.c   | 2 +-
 src/mesa/main/dd.h| 6 +++---
 src/mesa/state_tracker/st_cb_texturebarrier.c | 6 +++---
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 9aaffc37bd1..cd19db9f37c 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -313,7 +313,7 @@ brw_memory_barrier(struct gl_context *ctx, GLbitfield 
barriers)
 }
 
 static void
-brw_blend_barrier(struct gl_context *ctx)
+brw_framebuffer_fetch_barrier(struct gl_context *ctx)
 {
struct brw_context *brw = brw_context(ctx);
const struct gen_device_info *devinfo = >screen->devinfo;
@@ -443,7 +443,7 @@ void brwInitFragProgFuncs( struct dd_function_table 
*functions )
functions->LinkShader = brw_link_shader;
 
functions->MemoryBarrier = brw_memory_barrier;
-   functions->BlendBarrier = brw_blend_barrier;
+   functions->FramebufferFetchBarrier = brw_framebuffer_fetch_barrier;
 }
 
 struct shader_times {
diff --git a/src/mesa/main/barrier.c b/src/mesa/main/barrier.c
index 5284f28dc02..2c8194e6eba 100644
--- a/src/mesa/main/barrier.c
+++ b/src/mesa/main/barrier.c
@@ -134,5 +134,5 @@ _mesa_BlendBarrier(void)
   return;
}
 
-   ctx->Driver.BlendBarrier(ctx);
+   ctx->Driver.FramebufferFetchBarrier(ctx);
 }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 7a39f939c97..3e6a0418a2e 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -963,15 +963,15 @@ struct dd_function_table {
/** @} */
 
/**
-* GL_MESA_shader_framebuffer_fetch_non_coherent rendering barrier.
+* GL_EXT_shader_framebuffer_fetch_non_coherent rendering barrier.
 *
 * On return from this function any framebuffer contents written by
 * previous draw commands are guaranteed to be visible from subsequent
 * fragment shader invocations using the
-* MESA_shader_framebuffer_fetch_non_coherent interface.
+* EXT_shader_framebuffer_fetch_non_coherent interface.
 */
/** @{ */
-   void (*BlendBarrier)(struct gl_context *ctx);
+   void (*FramebufferFetchBarrier)(struct gl_context *ctx);
/** @} */
 
/**
diff --git a/src/mesa/state_tracker/st_cb_texturebarrier.c 
b/src/mesa/state_tracker/st_cb_texturebarrier.c
index 29cd37c16ce..2bff03b484a 100644
--- a/src/mesa/state_tracker/st_cb_texturebarrier.c
+++ b/src/mesa/state_tracker/st_cb_texturebarrier.c
@@ -55,10 +55,10 @@ st_TextureBarrier(struct gl_context *ctx)
 
 
 /**
- * Called via ctx->Driver.BlendBarrier()
+ * Called via ctx->Driver.FramebufferFetchBarrier()
  */
 static void
-st_BlendBarrier(struct gl_context *ctx)
+st_FramebufferFetchBarrier(struct gl_context *ctx)
 {
struct pipe_context *pipe = st_context(ctx)->pipe;
 
@@ -130,6 +130,6 @@ st_MemoryBarrier(struct gl_context *ctx, GLbitfield 
barriers)
 void st_init_texture_barrier_functions(struct dd_function_table *functions)
 {
functions->TextureBarrier = st_TextureBarrier;
-   functions->BlendBarrier = st_BlendBarrier;
+   functions->FramebufferFetchBarrier = st_FramebufferFetchBarrier;
functions->MemoryBarrier = st_MemoryBarrier;
 }
-- 
2.16.1

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


[Mesa-dev] [PATCH 06/15] util: Add EXPLICIT_CONVERSION macro.

2018-02-14 Thread Francisco Jerez
This can be used to specify that a C++ conversion operator is not
meant to be used for implicit conversions, which can lead to
unintended loss of information in some cases.  Implemented as a macro
in order to keep old GCC versions happy.
---
 src/util/macros.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/util/macros.h b/src/util/macros.h
index e3c785af508..6d3df904082 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -285,4 +285,14 @@ do {   \
 #define MIN3( A, B, C ) ((A) < (B) ? MIN2(A, C) : MIN2(B, C))
 #define MAX3( A, B, C ) ((A) > (B) ? MAX2(A, C) : MAX2(B, C))
 
+/**
+ * Macro for declaring an explicit conversion operator.  Defaults to an
+ * implicit conversion if C++11 is not supported.
+ */
+#if __cplusplus >= 201103L
+#define EXPLICIT_CONVERSION explicit
+#elif defined(__cplusplus)
+#define EXPLICIT_CONVERSION
+#endif
+
 #endif /* UTIL_MACROS_H */
-- 
2.16.1

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


[Mesa-dev] [PATCH 01/15] i965: Fix KHR_blend_equation_advanced with some render targets.

2018-02-14 Thread Francisco Jerez
This reverts two bogus and seemingly useless changes from the commits
referenced below, which broke KHR_blend_equation_advanced (and
EXT_shader_framebuffer_fetch_non_coherent which wasn't exposed yet)
for any kind of render target surface that would cause the
get_isl_surf() call in brw_emit_surface_state() to do anything useful
(notice how the result of get_isl_surf() is completely ignored by the
caller right now), as was the case while using those extensions with
1D array or 3D framebuffers in particular.

Fixes: f5859b45b1686e8116380d87 "i965/miptree: Switch remaining surfaces to isl"
Fixes: bf24c3539e4b6989512968ca "i965/miptree: Clean-up unused"
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 92ac1e45a3a..6b53e744dc9 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -87,6 +87,8 @@ get_isl_surf(struct brw_context *brw, struct 
intel_mipmap_tree *mt,
const enum isl_dim_layout dim_layout =
   get_isl_dim_layout(devinfo, mt->surf.tiling, target);
 
+   surf->dim = get_isl_surf_dim(target);
+
if (surf->dim_layout == dim_layout)
   return;
 
@@ -182,7 +184,7 @@ brw_emit_surface_state(struct brw_context *brw,
  brw->isl_dev.ss.align,
  surf_offset);
 
-   isl_surf_fill_state(>isl_dev, state, .surf = >surf, .view = ,
+   isl_surf_fill_state(>isl_dev, state, .surf = , .view = ,
.address = brw_state_reloc(>batch,
   *surf_offset + 
brw->isl_dev.ss.addr_offset,
   mt->bo, offset, reloc_flags),
-- 
2.16.1

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


[Mesa-dev] [PATCH 05/15] mesa: Implement glFramebufferFetchBarrierEXT entry point.

2018-02-14 Thread Francisco Jerez
---
 src/mesa/main/barrier.c | 17 +++--
 src/mesa/main/barrier.h |  3 +++
 src/mesa/main/tests/dispatch_sanity.cpp |  6 ++
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/barrier.c b/src/mesa/main/barrier.c
index 0f0b0a210d1..2be30220e49 100644
--- a/src/mesa/main/barrier.c
+++ b/src/mesa/main/barrier.c
@@ -127,8 +127,7 @@ _mesa_BlendBarrier(void)
 {
GET_CURRENT_CONTEXT(ctx);
 
-   if (!ctx->Extensions.EXT_shader_framebuffer_fetch_non_coherent &&
-   !ctx->Extensions.KHR_blend_equation_advanced) {
+   if (!ctx->Extensions.KHR_blend_equation_advanced) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
   "glBlendBarrier(not supported)");
   return;
@@ -136,3 +135,17 @@ _mesa_BlendBarrier(void)
 
ctx->Driver.FramebufferFetchBarrier(ctx);
 }
+
+void GLAPIENTRY
+_mesa_FramebufferFetchBarrierEXT(void)
+{
+   GET_CURRENT_CONTEXT(ctx);
+
+   if (!ctx->Extensions.EXT_shader_framebuffer_fetch_non_coherent) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "glFramebufferFetchBarrierEXT(not supported)");
+  return;
+   }
+
+   ctx->Driver.FramebufferFetchBarrier(ctx);
+}
diff --git a/src/mesa/main/barrier.h b/src/mesa/main/barrier.h
index 53ecf863f07..acc15c67794 100644
--- a/src/mesa/main/barrier.h
+++ b/src/mesa/main/barrier.h
@@ -53,4 +53,7 @@ _mesa_MemoryBarrierByRegion(GLbitfield barriers);
 void GLAPIENTRY
 _mesa_BlendBarrier(void);
 
+void GLAPIENTRY
+_mesa_FramebufferFetchBarrierEXT(void);
+
 #endif /* BARRIER_H */
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index d697343627e..83a4b046542 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -1023,6 +1023,9 @@ const struct function common_desktop_functions_possible[] 
= {
/* GL_ARB_gl_spirv */
{ "glSpecializeShaderARB", 45, -1 },
 
+   /* GL_EXT_shader_framebuffer_fetch_non_coherent */
+   { "glFramebufferFetchBarrierEXT", 20, -1 },
+
{ NULL, 0, -1 }
 };
 
@@ -2446,6 +2449,9 @@ const struct function gles2_functions_possible[] = {
{ "glGetQueryObjectui64vEXT", 20, -1 },
{ "glQueryCounterEXT", 20, -1 },
 
+   /* GL_EXT_shader_framebuffer_fetch_non_coherent */
+   { "glFramebufferFetchBarrierEXT", 20, -1 },
+
{ NULL, 0, -1 }
 };
 
-- 
2.16.1

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


[Mesa-dev] [PATCH 13/15] glsl: Specify framebuffer fetch coherency mode in lower_blend_equation_advanced().

2018-02-14 Thread Francisco Jerez
This requires passing an extra argument to the lowering pass because
the KHR_blend_equation_advanced specification doesn't seem to define
any mechanism for the implementation to determine at compile-time
whether coherent blending can ever be used (not even an "#extension
KHR_blend_equation_advanced_coherent" directive seems to be required
in the shader source AFAICT).

In the long run we'll probably want to do state-dependent recompiles
based on the value of ctx->Color.BlendCoherent, but right now there
would be no benefit from that because the only driver that supports
coherent framebuffer fetch is i965 on SKL+ hardware, which are unable
to support the non-coherent path for the moment because of texture
layout issues, so framebuffer fetch coherency is always enabled for
them.
---
 src/compiler/glsl/ir_optimization.h | 2 +-
 src/compiler/glsl/lower_blend_equation_advanced.cpp | 3 ++-
 src/mesa/drivers/dri/i965/brw_link.cpp  | 3 ++-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp  | 3 ++-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/ir_optimization.h 
b/src/compiler/glsl/ir_optimization.h
index 2b8c195151a..81049a479e8 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -166,7 +166,7 @@ bool lower_tess_level(gl_linked_shader *shader);
 
 bool lower_vertex_id(gl_linked_shader *shader);
 bool lower_cs_derived(gl_linked_shader *shader);
-bool lower_blend_equation_advanced(gl_linked_shader *shader);
+bool lower_blend_equation_advanced(gl_linked_shader *shader, bool coherent);
 
 bool lower_subroutine(exec_list *instructions, struct _mesa_glsl_parse_state 
*state);
 void propagate_invariance(exec_list *instructions);
diff --git a/src/compiler/glsl/lower_blend_equation_advanced.cpp 
b/src/compiler/glsl/lower_blend_equation_advanced.cpp
index c6db58142cd..b05a2e0f0bb 100644
--- a/src/compiler/glsl/lower_blend_equation_advanced.cpp
+++ b/src/compiler/glsl/lower_blend_equation_advanced.cpp
@@ -462,7 +462,7 @@ get_main(gl_linked_shader *sh)
 }
 
 bool
-lower_blend_equation_advanced(struct gl_linked_shader *sh)
+lower_blend_equation_advanced(struct gl_linked_shader *sh, bool coherent)
 {
if (sh->Program->sh.fs.BlendSupport == 0)
   return false;
@@ -480,6 +480,7 @@ lower_blend_equation_advanced(struct gl_linked_shader *sh)
fb->data.location = FRAG_RESULT_DATA0;
fb->data.read_only = 1;
fb->data.fb_fetch_output = 1;
+   fb->data.memory_coherent = coherent;
fb->data.how_declared = ir_var_hidden;
 
ir_variable *mode = new(mem_ctx) ir_variable(glsl_type::uint_type,
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index f0598f591ab..b08b56a9353 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -99,7 +99,8 @@ process_glsl_ir(struct brw_context *brw,
 
ralloc_adopt(mem_ctx, shader->ir);
 
-   lower_blend_equation_advanced(shader);
+   lower_blend_equation_advanced(
+  shader, ctx->Extensions.KHR_blend_equation_advanced_coherent);
 
/* lower_packing_builtins() inserts arithmetic instructions, so it
 * must precede lower_instructions().
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 7fef93949e8..ccf4dabcc9f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -7056,7 +7056,8 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
   do_mat_op_to_vec(ir);
 
   if (stage == MESA_SHADER_FRAGMENT)
- lower_blend_equation_advanced(shader);
+ lower_blend_equation_advanced(
+shader, ctx->Extensions.KHR_blend_equation_advanced_coherent);
 
   lower_instructions(ir,
  MOD_TO_FLOOR |
-- 
2.16.1

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


[Mesa-dev] [PATCH 00/15] Implement latest version of EXT_shader_framebuffer_fetch.

2018-02-14 Thread Francisco Jerez
This series implements version 7 of the EXT_shader_framebuffer_fetch
specification, which includes a number of changes I had originally
planned for a MESA extension but which ended up queued for inclusion
into an EXT extension after months-long discussion with several
Khronos members.  The most important changes are desktop GL support
(the original EXT extension only targeted GLES) and a non-coherent
extension with more relaxed memory ordering guarantees that allows
wider hardware support and/or better performance than the coherent
extension.  The GLSL front-end has been relying on non-coherent
framebuffer fetch functionality internally for a while in order to
implement KHR_blend_equation_advanced, so most of the back-end code is
already there, but it wasn't exposed directly to the user until now.

The updated EXT_shader_framebuffer_fetch extension hasn't made it into
the public Khronos registry page yet but it's been merged into
Khronos' private repository of the registry already [1].

Patch 1 of the series fixes a regression in the i965 driver that broke
KHR_blend_equation_advanced with some render targets.  This wasn't
caught earlier because of test coverage gaps of the
KHR_blend_equation_advanced extension.  The problem would have led to
failures in some tests I've written for the
EXT_shader_framebuffer_fetch_non_coherent extension I'm about to send
to the Piglit mailing list shortly.  Patches 2-3 and 9 are cleaning up
remnants of the MESA framebuffer fetch extension that was being used
internally in order to implement KHR_blend_equation_advanced.  Patches
6-8 are required to make room for additional qualifier flags in the
ast_type_qualifier object, which has run out of bits in the uint64_t
mask preventing the definition of additional type qualifiers (IIRC
this was the main reason the ARB_fragment_shader_interlock series was
shot down last year?).  The remaining patches are implementing
features of the updated extension that weren't already implemented for
the MESA extension.

[1] 
https://gitlab.khronos.org/opengl/registry/blob/master/extensions/EXT/EXT_shader_framebuffer_fetch.txt

[PATCH 01/15] i965: Fix KHR_blend_equation_advanced with some render targets.
[PATCH 02/15] mesa: Rename dd_function_table::BlendBarrier to match latest EXT 
spec.
[PATCH 03/15] mesa: Rename MESA_shader_framebuffer_fetch gl_extensions bits to 
EXT.
[PATCH 04/15] glapi: Update XML for last revision of 
EXT_shader_framebuffer_fetch.
[PATCH 05/15] mesa: Implement glFramebufferFetchBarrierEXT entry point.
[PATCH 06/15] util: Add EXPLICIT_CONVERSION macro.
[PATCH 07/15] util/bitset: Add C++ wrapper for static-size bitsets.
[PATCH 08/15] glsl: Switch ast_type_qualifier to a 128-bit bitset.
[PATCH 09/15] glsl: Replace MESA_shader_framebuffer_fetch extension flags with 
EXT ones.
[PATCH 10/15] glsl: Initialize ir_variable_data::fb_fetch_output earlier for 
GL(ES) 2.
[PATCH 11/15] glsl: Allow layout token for 
EXT_shader_framebuffer_fetch_non_coherent.
[PATCH 12/15] glsl: Add support for the framebuffer fetch layout(noncoherent) 
qualifier.
[PATCH 13/15] glsl: Specify framebuffer fetch coherency mode in 
lower_blend_equation_advanced().
[PATCH 14/15] glsl: Silence warnings when reading from a framebuffer fetch 
output.
[PATCH 15/15] mesa: Expose EXT_shader_framebuffer_fetch(_non_coherent) on 
desktop and embedded GL.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105098

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Bas Nieuwenhuizen  ---
Hi, I can't really comment on what is going wrong with your application
specifically, due to lack of details.

That the hang does not happen if you don't do the vkQueueSubmit does nto tell
us much, as you're essentially not telling the driver to do anything, and it
can't hang  when not doing anything on the GPU.

What you can try:

1) Don't specify the semaphores during the submit. For simple apps our driver
should give mostly the correct result even without them. That excludes
semaphores from being a problem.
2) See if you can scrap/comment out commands that you record in the command
buffer and whether the hang still occurs.
3) Run validation layers. (I realize that due to the hang you may need to
redirect the output to a file and check the file after reboot)

wrt VulkanTutorials, what exactly did you built and run? I have trouble
matching C++ files and shaders (since there are more c++ files to shaders) and
I'd prefer not to have to read the entire tutorial.

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


[Mesa-dev] [PATCH 3/3] svga: move duplicated code for setting fillmode/flatshade state

2018-02-14 Thread Brian Paul
Move the calls to svga_hwtnl_set_fillmode() and svga_hwtnl_set_flatshade()
out of the two retry_draw_*() functions to the svga_draw_vbo() function.
---
 src/gallium/drivers/svga/svga_pipe_draw.c | 30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c 
b/src/gallium/drivers/svga/svga_pipe_draw.c
index af53881..c73c406 100644
--- a/src/gallium/drivers/svga/svga_pipe_draw.c
+++ b/src/gallium/drivers/svga/svga_pipe_draw.c
@@ -64,16 +64,6 @@ retry_draw_range_elements(struct svga_context *svga,
 
SVGA_STATS_TIME_PUSH(svga_sws(svga), SVGA_STATS_TIME_DRAWELEMENTS);
 
-   svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
-
-   /** determine if flatshade is to be used after svga_update_state()
-*  in case the fragment shader is changed.
-*/
-   svga_hwtnl_set_flatshade(svga->hwtnl,
-svga->curr.rast->templ.flatshade ||
-is_using_flat_shading(svga),
-svga->curr.rast->templ.flatshade_first);
-
for (unsigned try = 0; try < 2; try++) {
   ret = svga_hwtnl_draw_range_elements(svga->hwtnl,
index_buffer, index_size,
@@ -100,16 +90,6 @@ retry_draw_arrays(struct svga_context *svga,
 
SVGA_STATS_TIME_PUSH(svga_sws(svga), SVGA_STATS_TIME_DRAWARRAYS);
 
-   svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
-
-   /** determine if flatshade is to be used after svga_update_state()
-*  in case the fragment shader is changed.
-*/
-   svga_hwtnl_set_flatshade(svga->hwtnl,
-svga->curr.rast->templ.flatshade ||
-is_using_flat_shading(svga),
-svga->curr.rast->templ.flatshade_first);
-
for (unsigned try = 0; try < 2; try++) {
   ret = svga_hwtnl_draw_arrays(svga->hwtnl, prim, start, count,
start_instance, instance_count);
@@ -230,6 +210,16 @@ svga_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
  assert(ret == PIPE_OK);
   }
 
+  svga_hwtnl_set_fillmode(svga->hwtnl, svga->curr.rast->hw_fillmode);
+
+  /** determine if flatshade is to be used after svga_update_state()
+   *  in case the fragment shader is changed.
+   */
+  svga_hwtnl_set_flatshade(svga->hwtnl,
+   svga->curr.rast->templ.flatshade ||
+   is_using_flat_shading(svga),
+   svga->curr.rast->templ.flatshade_first);
+
   if (info->index_size && indexbuf) {
  unsigned offset;
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 1/3] svga: call tgsi_scan_shader() for dummy shaders

2018-02-14 Thread Brian Paul
If we fail to compile the normal VS or FS we fall back to a simple/
dummy shader.  We need to rescan the the shader to update the shader
info.  Otherwise, this can lead to further translations failures
because the shader info doesn't match the actual shader.

Found by adding some extra debug assertions in the state-update code
while debugging something else.
---
 src/gallium/drivers/svga/svga_state_fs.c | 2 ++
 src/gallium/drivers/svga/svga_state_vs.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_state_fs.c 
b/src/gallium/drivers/svga/svga_state_fs.c
index 5e56899..f185a68 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -115,6 +115,8 @@ get_compiled_dummy_shader(struct svga_context *svga,
FREE((void *) fs->base.tokens);
fs->base.tokens = dummy;
 
+   tgsi_scan_shader(fs->base.tokens, >base.info);
+
variant = translate_fragment_program(svga, fs, key);
return variant;
 }
diff --git a/src/gallium/drivers/svga/svga_state_vs.c 
b/src/gallium/drivers/svga/svga_state_vs.c
index a0ab868..1dcc161 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -105,6 +105,8 @@ get_compiled_dummy_vertex_shader(struct svga_context *svga,
FREE((void *) vs->base.tokens);
vs->base.tokens = dummy;
 
+   tgsi_scan_shader(vs->base.tokens, >base.info);
+
variant = translate_vertex_program(svga, vs, key);
return variant;
 }
-- 
2.7.4

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


[Mesa-dev] [PATCH 2/3] svga: move svga_update_state() call in draw code

2018-02-14 Thread Brian Paul
This fixes a few Piglit transform feedback regressions caused by
commit 7a1401938b351.

In that change I moved the moved svga_update_state() into the loops,
after the calls to svga_hwtnl_set_flatshade().  But
svga_hwtnl_set_flatshade() actually depends on some derived shader
state.  This patch moves the svga_update_state() call into
svga_draw_vbo() so it's not duplicated in two places.

Fixes: 7a1401938b351 ("svga: clean up retry_draw_range_elements(),
retry_draw_arrays()")
---
 src/gallium/drivers/svga/svga_pipe_draw.c | 37 ---
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c 
b/src/gallium/drivers/svga/svga_pipe_draw.c
index ee4a105..af53881 100644
--- a/src/gallium/drivers/svga/svga_pipe_draw.c
+++ b/src/gallium/drivers/svga/svga_pipe_draw.c
@@ -75,17 +75,14 @@ retry_draw_range_elements(struct svga_context *svga,
 svga->curr.rast->templ.flatshade_first);
 
for (unsigned try = 0; try < 2; try++) {
-  ret = svga_update_state(svga, SVGA_STATE_HW_DRAW);
-  if (ret == PIPE_OK) {
- ret = svga_hwtnl_draw_range_elements(svga->hwtnl,
-  index_buffer, index_size,
-  index_bias,
-  min_index, max_index,
-  prim, start, count,
-  start_instance, instance_count);
- if (ret == PIPE_OK)
-break;
-  }
+  ret = svga_hwtnl_draw_range_elements(svga->hwtnl,
+   index_buffer, index_size,
+   index_bias,
+   min_index, max_index,
+   prim, start, count,
+   start_instance, instance_count);
+  if (ret == PIPE_OK)
+ break;
   svga_context_flush(svga, NULL);
}
 
@@ -114,13 +111,10 @@ retry_draw_arrays(struct svga_context *svga,
 svga->curr.rast->templ.flatshade_first);
 
for (unsigned try = 0; try < 2; try++) {
-  ret = svga_update_state(svga, SVGA_STATE_HW_DRAW);
-  if (ret == PIPE_OK) {
- ret = svga_hwtnl_draw_arrays(svga->hwtnl, prim, start, count,
-  start_instance, instance_count);
- if (ret == PIPE_OK)
-break;
-  }
+  ret = svga_hwtnl_draw_arrays(svga->hwtnl, prim, start, count,
+   start_instance, instance_count);
+  if (ret == PIPE_OK)
+ break;
   svga_context_flush(svga, NULL);
}
 
@@ -229,6 +223,13 @@ svga_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
   ret = svga_swtnl_draw_vbo(svga, info, indexbuf, index_offset);
}
else {
+  ret = svga_update_state(svga, SVGA_STATE_HW_DRAW);
+  if (ret != PIPE_OK) {
+ svga_context_flush(svga, NULL);
+ ret = svga_update_state(svga, SVGA_STATE_HW_DRAW);
+ assert(ret == PIPE_OK);
+  }
+
   if (info->index_size && indexbuf) {
  unsigned offset;
 
-- 
2.7.4

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


[Mesa-dev] [PATCH v3 14/18] anv/pass: Store usage in each subpass attachment

2018-02-14 Thread Jason Ekstrand
This requires us to ditch the VkAttachmentReference struct in favor of
an anv-specific struct.  However, we can now easily identify from just
the subpass attachment what kind of an attachment it is.  This will make
iteration over anv_subpass::attachments a little easier in some case.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/anv_pass.c| 35 +++
 src/intel/vulkan/anv_private.h | 16 +++-
 src/intel/vulkan/genX_cmd_buffer.c |  2 +-
 3 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index a77e52b..5b8b138 100644
--- a/src/intel/vulkan/anv_pass.c
+++ b/src/intel/vulkan/anv_pass.c
@@ -65,7 +65,7 @@ VkResult anv_CreateRenderPass(
anv_multialloc_add(, , pCreateInfo->attachmentCount);
anv_multialloc_add(, _flushes, pCreateInfo->subpassCount + 1);
 
-   VkAttachmentReference *subpass_attachments;
+   struct anv_subpass_attachment *subpass_attachments;
uint32_t subpass_attachment_count = 0;
for (uint32_t i = 0; i < pCreateInfo->subpassCount; i++) {
   subpass_attachment_count +=
@@ -117,7 +117,11 @@ VkResult anv_CreateRenderPass(
 
  for (uint32_t j = 0; j < desc->inputAttachmentCount; j++) {
 uint32_t a = desc->pInputAttachments[j].attachment;
-subpass->input_attachments[j] = desc->pInputAttachments[j];
+subpass->input_attachments[j] = (struct anv_subpass_attachment) {
+   .usage =   VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT,
+   .attachment =  desc->pInputAttachments[j].attachment,
+   .layout =  desc->pInputAttachments[j].layout,
+};
 if (a != VK_ATTACHMENT_UNUSED) {
has_input = true;
pass->attachments[a].usage |= 
VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT;
@@ -138,7 +142,11 @@ VkResult anv_CreateRenderPass(
 
  for (uint32_t j = 0; j < desc->colorAttachmentCount; j++) {
 uint32_t a = desc->pColorAttachments[j].attachment;
-subpass->color_attachments[j] = desc->pColorAttachments[j];
+subpass->color_attachments[j] = (struct anv_subpass_attachment) {
+   .usage =   VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
+   .attachment =  desc->pColorAttachments[j].attachment,
+   .layout =  desc->pColorAttachments[j].layout,
+};
 if (a != VK_ATTACHMENT_UNUSED) {
has_color = true;
pass->attachments[a].usage |= 
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
@@ -157,7 +165,11 @@ VkResult anv_CreateRenderPass(
 
  for (uint32_t j = 0; j < desc->colorAttachmentCount; j++) {
 uint32_t a = desc->pResolveAttachments[j].attachment;
-subpass->resolve_attachments[j] = desc->pResolveAttachments[j];
+subpass->resolve_attachments[j] = (struct anv_subpass_attachment) {
+   .usage =   VK_IMAGE_USAGE_TRANSFER_DST_BIT,
+   .attachment =  desc->pResolveAttachments[j].attachment,
+   .layout =  desc->pResolveAttachments[j].layout,
+};
 if (a != VK_ATTACHMENT_UNUSED) {
subpass->has_resolve = true;
uint32_t color_att = desc->pColorAttachments[j].attachment;
@@ -174,8 +186,12 @@ VkResult anv_CreateRenderPass(
 
   if (desc->pDepthStencilAttachment) {
  uint32_t a = desc->pDepthStencilAttachment->attachment;
- *subpass_attachments++ = subpass->depth_stencil_attachment =
-*desc->pDepthStencilAttachment;
+ subpass->depth_stencil_attachment = (struct anv_subpass_attachment) {
+.usage =   VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT,
+.attachment =  desc->pDepthStencilAttachment->attachment,
+.layout =  desc->pDepthStencilAttachment->layout,
+ };
+ *subpass_attachments++ = subpass->depth_stencil_attachment;
  if (a != VK_ATTACHMENT_UNUSED) {
 has_depth = true;
 pass->attachments[a].usage |=
@@ -186,8 +202,11 @@ VkResult anv_CreateRenderPass(
   *desc->pDepthStencilAttachment);
  }
   } else {
- subpass->depth_stencil_attachment.attachment = VK_ATTACHMENT_UNUSED;
- subpass->depth_stencil_attachment.layout = VK_IMAGE_LAYOUT_UNDEFINED;
+ subpass->depth_stencil_attachment = (struct anv_subpass_attachment) {
+.usage =   VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT,
+.attachment =  VK_ATTACHMENT_UNUSED,
+.layout =   VK_IMAGE_LAYOUT_UNDEFINED,
+ };
   }
}
 
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index d424498..9a8da2b 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2865,6 +2865,12 @@ struct anv_framebuffer {
struct anv_image_view *  

[Mesa-dev] [PATCH v3 17/18] anv/cmd_buffer: Do subpass image transitions in begin/end_subpass

2018-02-14 Thread Jason Ekstrand
Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 220 +++--
 1 file changed, 88 insertions(+), 132 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 310c01f..7f06441 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3266,130 +3266,6 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer 
*cmd_buffer)
cmd_buffer->state.hiz_enabled = info.hiz_usage == ISL_AUX_USAGE_HIZ;
 }
 
-
-/**
- * @brief Perform any layout transitions required at the beginning and/or end
- *of the current subpass for depth buffers.
- *
- * TODO: Consider preprocessing the attachment reference array at render pass
- *   create time to determine if no layout transition is needed at the
- *   beginning and/or end of each subpass.
- *
- * @param cmd_buffer The command buffer the transition is happening within.
- * @param subpass_end If true, marks that the transition is happening at the
- *end of the subpass.
- */
-static void
-cmd_buffer_subpass_transition_layouts(struct anv_cmd_buffer * const cmd_buffer,
-  const bool subpass_end)
-{
-   /* We need a non-NULL command buffer. */
-   assert(cmd_buffer);
-
-   const struct anv_cmd_state * const cmd_state = _buffer->state;
-   const struct anv_subpass * const subpass = cmd_state->subpass;
-
-   /* This function must be called within a subpass. */
-   assert(subpass);
-
-   /* If there are attachment references, the array shouldn't be NULL.
-*/
-   if (subpass->attachment_count > 0)
-  assert(subpass->attachments);
-
-   /* Iterate over the array of attachment references. */
-   for (const struct anv_subpass_attachment *att_ref = subpass->attachments;
-att_ref < subpass->attachments + subpass->attachment_count; att_ref++) 
{
-
-  /* If the attachment is unused, we can't perform a layout transition. */
-  if (att_ref->attachment == VK_ATTACHMENT_UNUSED)
- continue;
-
-  /* This attachment index shouldn't go out of bounds. */
-  assert(att_ref->attachment < cmd_state->pass->attachment_count);
-
-  const struct anv_render_pass_attachment * const att_desc =
- _state->pass->attachments[att_ref->attachment];
-  struct anv_attachment_state * const att_state =
- _buffer->state.attachments[att_ref->attachment];
-
-  /* The attachment should not be used in a subpass after its last. */
-  assert(att_desc->last_subpass_idx >= anv_get_subpass_id(cmd_state));
-
-  if (subpass_end && anv_get_subpass_id(cmd_state) <
-  att_desc->last_subpass_idx) {
- /* We're calling this function on a buffer twice in one subpass and
-  * this is not the last use of the buffer. The layout should not have
-  * changed from the first call and no transition is necessary.
-  */
- assert(att_state->current_layout == att_ref->layout ||
-att_state->current_layout ==
-VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL);
- continue;
-  }
-
-  /* The attachment index must be less than the number of attachments
-   * within the framebuffer.
-   */
-  assert(att_ref->attachment < cmd_state->framebuffer->attachment_count);
-
-  const struct anv_image_view * const iview =
- cmd_state->framebuffer->attachments[att_ref->attachment];
-  const struct anv_image * const image = iview->image;
-
-  /* Get the appropriate target layout for this attachment. */
-  VkImageLayout target_layout;
-
-  /* A resolve is necessary before use as an input attachment if the clear
-   * color or auxiliary buffer usage isn't supported by the sampler.
-   */
-  const bool input_needs_resolve =
-(att_state->fast_clear && !att_state->clear_color_is_zero_one) ||
-att_state->input_aux_usage != att_state->aux_usage;
-  if (subpass_end) {
- target_layout = att_desc->final_layout;
-  } else if (iview->aspect_mask & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV &&
- !input_needs_resolve) {
- /* Layout transitions before the final only help to enable sampling as
-  * an input attachment. If the input attachment supports sampling
-  * using the auxiliary surface, we can skip such transitions by making
-  * the target layout one that is CCS-aware.
-  */
- target_layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
-  } else {
- target_layout = att_ref->layout;
-  }
-
-  /* Perform the layout transition. */
-  if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
- transition_depth_buffer(cmd_buffer, image,
- att_state->current_layout, target_layout);
- att_state->aux_usage =
-anv_layout_to_aux_usage(_buffer->device->info, image,
- 

[Mesa-dev] [PATCH v3 15/18] anv/cmd_buffer: Sync clear values in begin_subpass

2018-02-14 Thread Jason Ekstrand
This is quite a bit cleaner because we now sync the clear values at the
same time as we do the fast clear.  For loading the clear values into
the surface state, we now do it once when we handle the LOAD_OP_LOAD
instead of every subpass.
---
 src/intel/vulkan/genX_cmd_buffer.c | 148 -
 1 file changed, 48 insertions(+), 100 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 3d120d1..793f590 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3411,97 +3411,6 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
}
 }
 
-/* Update the clear value dword(s) in surface state objects or the fast clear
- * state buffer entry for the color attachments used in this subpass.
- */
-static void
-cmd_buffer_subpass_sync_fast_clear_values(struct anv_cmd_buffer *cmd_buffer)
-{
-   assert(cmd_buffer && cmd_buffer->state.subpass);
-
-   const struct anv_cmd_state *state = _buffer->state;
-
-   /* Iterate through every color attachment used in this subpass. */
-   for (uint32_t i = 0; i < state->subpass->color_count; ++i) {
-
-  /* The attachment should be one of the attachments described in the
-   * render pass and used in the subpass.
-   */
-  const uint32_t a = state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < state->pass->attachment_count);
-
-  /* Store some information regarding this attachment. */
-  const struct anv_attachment_state *att_state = >attachments[a];
-  const struct anv_image_view *iview = state->framebuffer->attachments[a];
-  const struct anv_render_pass_attachment *rp_att =
- >pass->attachments[a];
-
-  if (att_state->aux_usage == ISL_AUX_USAGE_NONE)
- continue;
-
-  /* The fast clear state entry must be updated if a fast clear is going to
-   * happen. The surface state must be updated if the clear value from a
-   * prior fast clear may be needed.
-   */
-  if (att_state->pending_clear_aspects && att_state->fast_clear) {
- /* Update the fast clear state entry. */
- genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
-  iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  true /* copy from ss */);
-
- /* Fast-clears impact whether or not a resolve will be necessary. */
- if (att_state->clear_color_is_zero) {
-/* This image has the auxiliary buffer enabled. We can mark the
- * subresource as not needing a resolve because the clear color
- * will match what's in every RENDER_SURFACE_STATE object when
- * it's being used for sampling.
- */
-set_image_fast_clear_state(cmd_buffer, iview->image,
-   VK_IMAGE_ASPECT_COLOR_BIT,
-   ANV_FAST_CLEAR_DEFAULT_VALUE);
- } else {
-set_image_fast_clear_state(cmd_buffer, iview->image,
-   VK_IMAGE_ASPECT_COLOR_BIT,
-   ANV_FAST_CLEAR_ANY);
- }
-  } else if (rp_att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD &&
- iview->planes[0].isl.base_level == 0 &&
- iview->planes[0].isl.base_array_layer == 0) {
- /* The attachment may have been fast-cleared in a previous render
-  * pass and the value is needed now. Update the surface state(s).
-  *
-  * TODO: Do this only once per render pass instead of every subpass.
-  */
- genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
-  iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  false /* copy to ss */);
-
- if (need_input_attachment_state(rp_att) &&
- att_state->input_aux_usage != ISL_AUX_USAGE_NONE) {
-genX(copy_fast_clear_dwords)(cmd_buffer, att_state->input.state,
- iview->image,
- VK_IMAGE_ASPECT_COLOR_BIT,
- false /* copy to ss */);
- }
-  }
-
-  /* We assume that if we're starting a subpass, we're going to do some
-   * rendering so we may end up with compressed data.
-   */
-  genX(cmd_buffer_mark_image_written)(cmd_buffer, iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  att_state->aux_usage,
-  iview->planes[0].isl.base_level,
-  
iview->planes[0].isl.base_array_layer,
-  

[Mesa-dev] [PATCH v3 13/18] anv/cmd_buffer: Add a concept of pending load aspects

2018-02-14 Thread Jason Ekstrand
These are the same as pending clear aspects only for the "load"
operation.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/anv_private.h |  1 +
 src/intel/vulkan/genX_cmd_buffer.c | 22 --
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 906c6f3..d424498 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1678,6 +1678,7 @@ struct anv_attachment_state {
 
VkImageLayoutcurrent_layout;
VkImageAspectFlags   pending_clear_aspects;
+   VkImageAspectFlags   pending_load_aspects;
bool fast_clear;
VkClearValue clear_value;
bool clear_color_is_zero_one;
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0d50434..b1dbed1 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1132,26 +1132,36 @@ genX(cmd_buffer_setup_attachments)(struct 
anv_cmd_buffer *cmd_buffer,
  struct anv_render_pass_attachment *att = >attachments[i];
  VkImageAspectFlags att_aspects = vk_format_aspects(att->format);
  VkImageAspectFlags clear_aspects = 0;
+ VkImageAspectFlags load_aspects = 0;
 
  if (att_aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
 /* color attachment */
 if (att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
clear_aspects |= VK_IMAGE_ASPECT_COLOR_BIT;
+} else if (att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+   load_aspects |= VK_IMAGE_ASPECT_COLOR_BIT;
 }
  } else {
 /* depthstencil attachment */
-if ((att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
-att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
-   clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+if (att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+   if (att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
+  clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+   } else if (att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+  load_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+   }
 }
-if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) &&
-att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
-   clear_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+if (att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
+   if (att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
+  clear_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+   } else if (att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+  load_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+   }
 }
  }
 
  state->attachments[i].current_layout = att->initial_layout;
  state->attachments[i].pending_clear_aspects = clear_aspects;
+ state->attachments[i].pending_load_aspects = load_aspects;
  if (clear_aspects)
 state->attachments[i].clear_value = begin->pClearValues[i];
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 07/18] anv/cmd_buffer: Pass a subpass id into begin_subpass

2018-02-14 Thread Jason Ekstrand
This is a bit less awkward than passing in the subpass because it means
we don't have to extract the subpass id from the subpass.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 5e689e2..00bf19e 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3428,13 +3428,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
anv_cmd_buffer *cmd_buffer)
}
 }
 
-
 static void
 cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
- struct anv_subpass *subpass)
+ uint32_t subpass_id)
 {
-   cmd_buffer->state.subpass = subpass;
-   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
+   cmd_buffer->state.subpass = _buffer->state.pass->subpasses[subpass_id];
 
cmd_buffer->state.gfx.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
 
@@ -3525,7 +3523,7 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
+   cmd_buffer_begin_subpass(cmd_buffer, 0);
 }
 
 void genX(CmdNextSubpass)(
@@ -3539,9 +3537,9 @@ void genX(CmdNextSubpass)(
 
assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
 
+   uint32_t prev_subpass = anv_get_subpass_id(_buffer->state);
cmd_buffer_end_subpass(cmd_buffer);
-
-   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
+   cmd_buffer_begin_subpass(cmd_buffer, prev_subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 16/18] anv/cmd_buffer: Mark depth/stencil surfaces written in begin_subpass

2018-02-14 Thread Jason Ekstrand
Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 50 ++
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 793f590..310c01f 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3264,27 +3264,6 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer 
*cmd_buffer)
isl_emit_depth_stencil_hiz_s(>isl_dev, dw, );
 
cmd_buffer->state.hiz_enabled = info.hiz_usage == ISL_AUX_USAGE_HIZ;
-
-   /* We may be writing depth or stencil so we need to mark the surface.
-* Unfortunately, there's no way to know at this point whether the depth or
-* stencil tests used will actually write to the surface.
-*/
-   if (image && (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
-  genX(cmd_buffer_mark_image_written)(cmd_buffer, image,
-  VK_IMAGE_ASPECT_DEPTH_BIT,
-  info.hiz_usage,
-  info.view->base_level,
-  info.view->base_array_layer,
-  info.view->array_len);
-   }
-   if (image && (image->aspects & VK_IMAGE_ASPECT_STENCIL_BIT)) {
-  genX(cmd_buffer_mark_image_written)(cmd_buffer, image,
-  VK_IMAGE_ASPECT_STENCIL_BIT,
-  ISL_AUX_USAGE_NONE,
-  info.view->base_level,
-  info.view->base_array_layer,
-  info.view->array_len);
-   }
 }
 
 
@@ -3570,6 +3549,35 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
  iview->planes[0].isl.base_level,
  
iview->planes[0].isl.base_array_layer,
  fb->layers);
+  } else if (subpass->attachments[i].usage ==
+ VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT) {
+ /* We may be writing depth or stencil so we need to mark the surface.
+  * Unfortunately, there's no way to know at this point whether the
+  * depth or stencil tests used will actually write to the surface.
+  *
+  * Even though stencil may be plane 1, it always shares a base_level
+  * with depth.
+  */
+ const struct isl_view *ds_view = >planes[0].isl;
+ if (iview->aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT) {
+genX(cmd_buffer_mark_image_written)(cmd_buffer, image,
+VK_IMAGE_ASPECT_DEPTH_BIT,
+att_state->aux_usage,
+ds_view->base_level,
+ds_view->base_array_layer,
+fb->layers);
+ }
+ if (iview->aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT) {
+/* Even though stencil may be plane 1, it always shares a
+ * base_level with depth.
+ */
+genX(cmd_buffer_mark_image_written)(cmd_buffer, image,
+VK_IMAGE_ASPECT_STENCIL_BIT,
+ISL_AUX_USAGE_NONE,
+ds_view->base_level,
+ds_view->base_array_layer,
+fb->layers);
+ }
   }
 
   att_state->pending_clear_aspects = 0;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 09/18] intel/blorp: Add a blorp_hiz_clear_depth_stencil helper

2018-02-14 Thread Jason Ekstrand
This is similar to blorp_gen8_hiz_clear_attachments except that it takes
actual images instead of trusting in the already set depth state.

Reviewed-by: Nanley Chery 
---
 src/intel/blorp/blorp.h   | 11 +
 src/intel/blorp/blorp_clear.c | 53 +++
 2 files changed, 64 insertions(+)

diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index ce3762c..4626f2f 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/intel/blorp/blorp.h
@@ -170,6 +170,17 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
format,
   uint32_t num_samples,
   uint32_t x0, uint32_t y0,
   uint32_t x1, uint32_t y1);
+void
+blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
+  const struct blorp_surf *depth,
+  const struct blorp_surf *stencil,
+  uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  uint32_t x0, uint32_t y0,
+  uint32_t x1, uint32_t y1,
+  bool clear_depth, float depth_value,
+  bool clear_stencil, uint8_t stencil_value);
+
 
 void
 blorp_gen8_hiz_clear_attachments(struct blorp_batch *batch,
diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
index 4ba65d0..5495d4d 100644
--- a/src/intel/blorp/blorp_clear.c
+++ b/src/intel/blorp/blorp_clear.c
@@ -612,6 +612,59 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
format,
return true;
 }
 
+void
+blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
+  const struct blorp_surf *depth,
+  const struct blorp_surf *stencil,
+  uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  uint32_t x0, uint32_t y0,
+  uint32_t x1, uint32_t y1,
+  bool clear_depth, float depth_value,
+  bool clear_stencil, uint8_t stencil_value)
+{
+   struct blorp_params params;
+   blorp_params_init();
+
+   /* This requires WM_HZ_OP which only exists on gen8+ */
+   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 8);
+
+   params.hiz_op = ISL_AUX_OP_FAST_CLEAR;
+   params.num_layers = 1;
+
+   params.x0 = x0;
+   params.y0 = y0;
+   params.x1 = x1;
+   params.y1 = y1;
+
+   for (uint32_t l = 0; l < num_layers; l++) {
+  const uint32_t layer = start_layer + l;
+  if (clear_stencil) {
+ brw_blorp_surface_info_init(batch->blorp, , stencil,
+ level, layer,
+ ISL_FORMAT_UNSUPPORTED, true);
+ params.stencil_mask = 0xff;
+ params.stencil_ref = stencil_value;
+ params.num_samples = params.stencil.surf.samples;
+  }
+
+  if (clear_depth) {
+ /* If we're clearing depth, we must have HiZ */
+ assert(depth && depth->aux_usage == ISL_AUX_USAGE_HIZ);
+
+ brw_blorp_surface_info_init(batch->blorp, , depth,
+ level, layer,
+ ISL_FORMAT_UNSUPPORTED, true);
+ params.depth.clear_color.f32[0] = depth_value;
+ params.depth_format =
+isl_format_get_depth_format(depth->surf->format, false);
+ params.num_samples = params.depth.surf.samples;
+  }
+
+  batch->blorp->exec(batch, );
+   }
+}
+
 /* Given a depth stencil attachment, this function performs a fast depth clear
  * on a depth portion and a regular clear on the stencil portion. When
  * performing a fast depth clear on the depth portion, the HiZ buffer is simply
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 18/18] anv/cmd_buffer: Avoid unnecessary transitions before fast clears

2018-02-14 Thread Jason Ekstrand
Previously, we would always apply the layout transition at the beginning
of the subpass and then do the clear whether fast or slow.  This meant
that there were some cases, specifically when the initial layout is
VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
ambiguate followed immediately by a fast-clear.  This probably isn't
terribly expensive, but it is a waste that we can avoid easily enough
now that we're doing everything at the same time in begin_subpass.
---
 src/intel/vulkan/genX_cmd_buffer.c | 62 +++---
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 7f06441..453aea8 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3335,6 +3335,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
  target_layout = subpass->attachments[i].layout;
   }
 
+  /* Clears are based on the image view for 3D surfaces but transitions
+   * are done on an entire miplevel at a time.
+   */
+  uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
+  uint32_t clear_layer_count = fb->layers;
+
   if (image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
  assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
@@ -3348,30 +3354,8 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
 layer_count = fb->layers;
  }
 
- transition_color_buffer(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
- iview->planes[0].isl.base_level, 1,
- base_layer, layer_count,
- att_state->current_layout, target_layout);
-  } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
- transition_depth_buffer(cmd_buffer, image,
- att_state->current_layout, target_layout);
- att_state->aux_usage =
-anv_layout_to_aux_usage(_buffer->device->info, image,
-VK_IMAGE_ASPECT_DEPTH_BIT, target_layout);
-  }
-  att_state->current_layout = target_layout;
-
-  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
- assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
- /* Multi-planar images are not supported as attachments */
- assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
- assert(image->n_planes == 1);
-
- uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
- uint32_t clear_layer_count = fb->layers;
-
- if (att_state->fast_clear) {
+ if ((att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) &&
+ att_state->fast_clear) {
 /* We only support fast-clears on the first layer */
 assert(iview->planes[0].isl.base_level == 0);
 assert(iview->planes[0].isl.base_array_layer == 0);
@@ -3381,6 +3365,13 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
 base_clear_layer++;
 clear_layer_count--;
 
+/* Performing a fast clear takes care of all our transition needs
+ * for the first slice.  Increment the base layer and layer count
+ * so that later transitions don't touch layer 0.
+ */
+base_layer++;
+layer_count--;
+
 genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
  image, VK_IMAGE_ASPECT_COLOR_BIT,
  true /* copy from ss */);
@@ -3401,6 +3392,29 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
 }
  }
 
+ if (layer_count > 0) {
+transition_color_buffer(cmd_buffer, image,
+VK_IMAGE_ASPECT_COLOR_BIT,
+iview->planes[0].isl.base_level, 1,
+base_layer, layer_count,
+att_state->current_layout, target_layout);
+ }
+  } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+ transition_depth_buffer(cmd_buffer, image,
+ att_state->current_layout, target_layout);
+ att_state->aux_usage =
+anv_layout_to_aux_usage(_buffer->device->info, image,
+VK_IMAGE_ASPECT_DEPTH_BIT, target_layout);
+  }
+  att_state->current_layout = target_layout;
+
+  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
+ assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+ /* Multi-planar images are not supported as attachments */
+ assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+ assert(image->n_planes == 1);
+
  if 

[Mesa-dev] [PATCH v3 12/18] anv/cmd_buffer: Iterate all subpass attachments when clearing

2018-02-14 Thread Jason Ekstrand
This unifies things a bit because we now handle depth and stencil at the
same time.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 78 --
 1 file changed, 33 insertions(+), 45 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0b6b1c1..0d50434 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3543,66 +3543,52 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
 
VkRect2D render_area = cmd_buffer->state.render_area;
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-   for (uint32_t i = 0; i < subpass->color_count; ++i) {
-  const uint32_t a = subpass->color_attachments[i].attachment;
+
+   for (uint32_t i = 0; i < subpass->attachment_count; ++i) {
+  const uint32_t a = subpass->attachments[i].attachment;
   if (a == VK_ATTACHMENT_UNUSED)
  continue;
 
   assert(a < cmd_state->pass->attachment_count);
   struct anv_attachment_state *att_state = _state->attachments[a];
 
-  if (!att_state->pending_clear_aspects)
- continue;
-
-  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
   struct anv_image_view *iview = fb->attachments[a];
   const struct anv_image *image = iview->image;
 
-  /* Multi-planar images are not supported as attachments */
-  assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-  assert(image->n_planes == 1);
-
-  uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
-  uint32_t clear_layer_count = fb->layers;
+  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
+ assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
-  if (att_state->fast_clear) {
- /* We only support fast-clears on the first layer */
- assert(iview->planes[0].isl.base_level == 0);
- assert(iview->planes[0].isl.base_array_layer == 0);
-
- anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
-  0, 0, 1, ISL_AUX_OP_FAST_CLEAR, false);
- base_clear_layer++;
- clear_layer_count--;
-  }
-
-  if (clear_layer_count > 0) {
+ /* Multi-planar images are not supported as attachments */
+ assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
  assert(image->n_planes == 1);
- anv_image_clear_color(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage,
-   iview->planes[0].isl.format,
-   iview->planes[0].isl.swizzle,
-   iview->planes[0].isl.base_level,
-   base_clear_layer, clear_layer_count, 
render_area,
-   vk_to_isl_color(att_state->clear_value.color));
-  }
-
-  att_state->pending_clear_aspects = 0;
-   }
 
-   if (subpass->depth_stencil_attachment.attachment != VK_ATTACHMENT_UNUSED) {
-  const uint32_t a = subpass->depth_stencil_attachment.attachment;
+ uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
+ uint32_t clear_layer_count = fb->layers;
 
-  assert(a < cmd_state->pass->attachment_count);
-  struct anv_attachment_state *att_state = _state->attachments[a];
-  struct anv_image_view *iview = fb->attachments[a];
-  const struct anv_image *image = iview->image;
+ if (att_state->fast_clear) {
+/* We only support fast-clears on the first layer */
+assert(iview->planes[0].isl.base_level == 0);
+assert(iview->planes[0].isl.base_array_layer == 0);
 
-  assert(image->aspects & (VK_IMAGE_ASPECT_DEPTH_BIT |
-   VK_IMAGE_ASPECT_STENCIL_BIT));
+anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
+ 0, 0, 1, ISL_AUX_OP_FAST_CLEAR, false);
+base_clear_layer++;
+clear_layer_count--;
+ }
 
-  if (att_state->pending_clear_aspects) {
+ if (clear_layer_count > 0) {
+assert(image->n_planes == 1);
+anv_image_clear_color(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
+  att_state->aux_usage,
+  iview->planes[0].isl.format,
+  iview->planes[0].isl.swizzle,
+  iview->planes[0].isl.base_level,
+  base_clear_layer, clear_layer_count,
+  render_area,
+  
vk_to_isl_color(att_state->clear_value.color));
+ }
+  } else if (att_state->pending_clear_aspects & (VK_IMAGE_ASPECT_DEPTH_BIT 
|
+ 
VK_IMAGE_ASPECT_STENCIL_BIT)) {
  if 

[Mesa-dev] [PATCH v3 06/18] anv/cmd_buffer: Add begin/end_subpass helpers

2018-02-14 Thread Jason Ekstrand
Having begin/end_subpass is a bit nicer than the begin/next/end hooks
that Vulkan gives us.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 55 +-
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index cc3832f..5e689e2 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3430,10 +3430,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
anv_cmd_buffer *cmd_buffer)
 
 
 static void
-genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer *cmd_buffer,
- struct anv_subpass *subpass)
+cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
+ struct anv_subpass *subpass)
 {
cmd_buffer->state.subpass = subpass;
+   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
 
cmd_buffer->state.gfx.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
 
@@ -3458,6 +3459,10 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
*cmd_buffer,
 */
cmd_buffer->state.gfx.dirty |= ANV_CMD_DIRTY_PIPELINE;
 
+   /* Accumulate any subpass flushes that need to happen before the subpass */
+   cmd_buffer->state.pending_pipe_bits |=
+  cmd_buffer->state.pass->subpass_flushes[subpass_id];
+
/* Perform transitions to the subpass layout before any writes have
 * occurred.
 */
@@ -3477,6 +3482,26 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
*cmd_buffer,
anv_cmd_buffer_clear_subpass(cmd_buffer);
 }
 
+static void
+cmd_buffer_end_subpass(struct anv_cmd_buffer *cmd_buffer)
+{
+   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
+
+   anv_cmd_buffer_resolve_subpass(cmd_buffer);
+
+   /* Perform transitions to the final layout after all writes have occurred.
+*/
+   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
+
+   /* Accumulate any subpass flushes that need to happen after the subpass.
+* Yes, they do get accumulated twice in the NextSubpass case but since
+* genX_CmdNextSubpass just calls end/begin back-to-back, we just end up
+* ORing the bits in twice so it's harmless.
+*/
+   cmd_buffer->state.pending_pipe_bits |=
+  cmd_buffer->state.pass->subpass_flushes[subpass_id + 1];
+}
+
 void genX(CmdBeginRenderPass)(
 VkCommandBuffer commandBuffer,
 const VkRenderPassBeginInfo*pRenderPassBegin,
@@ -3500,10 +3525,7 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   cmd_buffer->state.pending_pipe_bits |=
-  cmd_buffer->state.pass->subpass_flushes[0];
-
-   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
+   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
 }
 
 void genX(CmdNextSubpass)(
@@ -3517,17 +3539,9 @@ void genX(CmdNextSubpass)(
 
assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
 
-   anv_cmd_buffer_resolve_subpass(cmd_buffer);
-
-   /* Perform transitions to the final layout after all writes have occurred.
-*/
-   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
-
-   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
-   cmd_buffer->state.pending_pipe_bits |=
-  cmd_buffer->state.pass->subpass_flushes[subpass_id];
+   cmd_buffer_end_subpass(cmd_buffer);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
+   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
@@ -3538,14 +3552,7 @@ void genX(CmdEndRenderPass)(
if (anv_batch_has_error(_buffer->batch))
   return;
 
-   anv_cmd_buffer_resolve_subpass(cmd_buffer);
-
-   /* Perform transitions to the final layout after all writes have occurred.
-*/
-   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
-
-   cmd_buffer->state.pending_pipe_bits |=
-  
cmd_buffer->state.pass->subpass_flushes[cmd_buffer->state.pass->subpass_count];
+   cmd_buffer_end_subpass(cmd_buffer);
 
cmd_buffer->state.hiz_enabled = false;
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 08/18] anv/cmd_buffer: Move the color portion of clear_subpass into begin_subpass

2018-02-14 Thread Jason Ekstrand
This doesn't really change much now but it will give us more/better
control over clears in the future.  The one interesting functional
change here is that we are now re-emitting 3DSTATE_DEPTH_BUFFERS and
friends for each clear.  However, this only happens at begin_subpass
time so it shouldn't be substantially more expensive.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/anv_blorp.c   | 124 ++---
 src/intel/vulkan/anv_private.h |   8 +++
 src/intel/vulkan/genX_cmd_buffer.c |  54 +++-
 3 files changed, 94 insertions(+), 92 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index d38b343..fd32227 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1142,17 +1142,6 @@ subpass_needs_clear(const struct anv_cmd_buffer 
*cmd_buffer)
const struct anv_cmd_state *cmd_state = _buffer->state;
uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
 
-   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
-  uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < cmd_state->pass->attachment_count);
-  if (cmd_state->attachments[a].pending_clear_aspects) {
- return true;
-  }
-   }
-
if (ds != VK_ATTACHMENT_UNUSED) {
   assert(ds < cmd_state->pass->attachment_count);
   if (cmd_state->attachments[ds].pending_clear_aspects)
@@ -1186,86 +1175,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
};
 
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
-  const uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < cmd_state->pass->attachment_count);
-  struct anv_attachment_state *att_state = _state->attachments[a];
-
-  if (!att_state->pending_clear_aspects)
- continue;
-
-  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
-  struct anv_image_view *iview = fb->attachments[a];
-  const struct anv_image *image = iview->image;
-  struct blorp_surf surf;
-  get_blorp_surf_for_anv_image(cmd_buffer->device,
-   image, VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage, );
-
-  uint32_t base_layer = iview->planes[0].isl.base_array_layer;
-  uint32_t layer_count = fb->layers;
-
-  if (att_state->fast_clear) {
- surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
-
- /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
-  *
-  *"After Render target fast clear, pipe-control with color cache
-  *write-flush must be issued before sending any DRAW commands on
-  *that render target."
-  *
-  * This comment is a bit cryptic and doesn't really tell you what's
-  * going or what's really needed.  It appears that fast clear ops are
-  * not properly synchronized with other drawing.  This means that we
-  * cannot have a fast clear operation in the pipe at the same time as
-  * other regular drawing operations.  We need to use a PIPE_CONTROL
-  * to ensure that the contents of the previous draw hit the render
-  * target before we resolve and then use a second PIPE_CONTROL after
-  * the resolve to ensure that it is completed before any additional
-  * drawing occurs.
-  */
- cmd_buffer->state.pending_pipe_bits |=
-ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
-
- /* We only support fast-clears on the first layer */
- assert(iview->planes[0].isl.base_level == 0);
- assert(iview->planes[0].isl.base_array_layer == 0);
-
- assert(image->n_planes == 1);
- blorp_fast_clear(, , iview->planes[0].isl.format, 0, 0, 1,
-  render_area.offset.x, render_area.offset.y,
-  render_area.offset.x + render_area.extent.width,
-  render_area.offset.y + render_area.extent.height);
- base_layer++;
- layer_count--;
-
- cmd_buffer->state.pending_pipe_bits |=
-ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
-  }
-
-  if (layer_count > 0) {
- assert(image->n_planes == 1);
- anv_cmd_buffer_mark_image_written(cmd_buffer, image,
-   VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage,
-   iview->planes[0].isl.base_level,
-   base_layer, layer_count);
-
- blorp_clear(, , 

[Mesa-dev] [PATCH v3 10/18] anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass

2018-02-14 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_blorp.c   | 242 -
 src/intel/vulkan/anv_private.h |  17 ++-
 src/intel/vulkan/genX_cmd_buffer.c |  68 ++-
 3 files changed, 186 insertions(+), 141 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index fd32227..6c0c858 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1136,143 +1136,6 @@ enum subpass_stage {
SUBPASS_STAGE_RESOLVE,
 };
 
-static bool
-subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
-{
-   const struct anv_cmd_state *cmd_state = _buffer->state;
-   uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
-
-   if (ds != VK_ATTACHMENT_UNUSED) {
-  assert(ds < cmd_state->pass->attachment_count);
-  if (cmd_state->attachments[ds].pending_clear_aspects)
- return true;
-   }
-
-   return false;
-}
-
-void
-anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
-{
-   const struct anv_cmd_state *cmd_state = _buffer->state;
-   const VkRect2D render_area = cmd_buffer->state.render_area;
-
-
-   if (!subpass_needs_clear(cmd_buffer))
-  return;
-
-   /* Because this gets called within a render pass, we tell blorp not to
-* trash our depth and stencil buffers.
-*/
-   struct blorp_batch batch;
-   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
-BLORP_BATCH_NO_EMIT_DEPTH_STENCIL);
-
-   VkClearRect clear_rect = {
-  .rect = cmd_buffer->state.render_area,
-  .baseArrayLayer = 0,
-  .layerCount = cmd_buffer->state.framebuffer->layers,
-   };
-
-   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-
-   const uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
-   assert(ds == VK_ATTACHMENT_UNUSED || ds < 
cmd_state->pass->attachment_count);
-
-   if (ds != VK_ATTACHMENT_UNUSED &&
-   cmd_state->attachments[ds].pending_clear_aspects) {
-
-  VkClearAttachment clear_att = {
- .aspectMask = cmd_state->attachments[ds].pending_clear_aspects,
- .clearValue = cmd_state->attachments[ds].clear_value,
-  };
-
-
-  const uint8_t gen = cmd_buffer->device->info.gen;
-  bool clear_with_hiz = gen >= 8 && cmd_state->attachments[ds].aux_usage ==
-ISL_AUX_USAGE_HIZ;
-  const struct anv_image_view *iview = fb->attachments[ds];
-
-  if (clear_with_hiz) {
- const bool clear_depth = clear_att.aspectMask &
-  VK_IMAGE_ASPECT_DEPTH_BIT;
- const bool clear_stencil = clear_att.aspectMask &
-VK_IMAGE_ASPECT_STENCIL_BIT;
-
- /* Check against restrictions for depth buffer clearing. A great GPU
-  * performance benefit isn't expected when using the HZ sequence for
-  * stencil-only clears. Therefore, we don't emit a HZ op sequence for
-  * a stencil clear in addition to using the BLORP-fallback for depth.
-  */
- if (clear_depth) {
-if (!blorp_can_hiz_clear_depth(gen, iview->planes[0].isl.format,
-   iview->image->samples,
-   render_area.offset.x,
-   render_area.offset.y,
-   render_area.offset.x +
-   render_area.extent.width,
-   render_area.offset.y +
-   render_area.extent.height)) {
-   clear_with_hiz = false;
-} else if (clear_att.clearValue.depthStencil.depth !=
-   ANV_HZ_FC_VAL) {
-   /* Don't enable fast depth clears for any color not equal to
-* ANV_HZ_FC_VAL.
-*/
-   clear_with_hiz = false;
-} else if (gen == 8 &&
-   anv_can_sample_with_hiz(_buffer->device->info,
-   iview->image)) {
-   /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
-* fast-cleared portion of a HiZ buffer. Testing has revealed
-* that Gen8 only supports returning 0.0f. Gens prior to gen8 do
-* not support this feature at all.
-*/
-   clear_with_hiz = false;
-}
- }
-
- if (clear_with_hiz) {
-blorp_gen8_hiz_clear_attachments(, iview->image->samples,
- render_area.offset.x,
- render_area.offset.y,
- render_area.offset.x +
- render_area.extent.width,
- render_area.offset.y +
- render_area.extent.height,
-  

[Mesa-dev] [PATCH v3 11/18] anv/cmd_buffer: Decide whether or not to HiZ clear up-front

2018-02-14 Thread Jason Ekstrand
This moves the decision out of begin_subpass and into BeginRenderPass
like the decision for color clears.  We use a similar name for the
function for depth/stencil as for color even though no aux usage is
really getting computed.

v2 (Jason Ekstrand):
 - Don't always disable HiZ clears by accident
 - Use the initial layout to decide whether to do fast clears

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 107 +
 1 file changed, 72 insertions(+), 35 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 93894c1..0b6b1c1 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -342,6 +342,73 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
}
 }
 
+static void
+depth_stencil_attachment_compute_aux_usage(struct anv_device *device,
+   struct anv_cmd_state *cmd_state,
+   uint32_t att, VkRect2D render_area)
+{
+   struct anv_render_pass_attachment *pass_att =
+  _state->pass->attachments[att];
+   struct anv_attachment_state *att_state = _state->attachments[att];
+   struct anv_image_view *iview = cmd_state->framebuffer->attachments[att];
+
+   /* These will be initialized after the first subpass transition. */
+   att_state->aux_usage = ISL_AUX_USAGE_NONE;
+   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+
+   if (GEN_GEN == 7) {
+  /* We don't do any HiZ or depth fast-clears on gen7 yet */
+  att_state->fast_clear = false;
+  return;
+   }
+
+   if (!(att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
+  /* If we're just clearing stencil, we can always HiZ clear */
+  att_state->fast_clear = true;
+  return;
+   }
+
+   /* Default to false for now */
+   att_state->fast_clear = false;
+
+   /* We must have depth in order to have HiZ */
+   if (!(iview->image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT))
+  return;
+
+   const enum isl_aux_usage first_subpass_aux_usage =
+  anv_layout_to_aux_usage(>info, iview->image,
+  VK_IMAGE_ASPECT_DEPTH_BIT,
+  pass_att->first_subpass_layout);
+   if (first_subpass_aux_usage != ISL_AUX_USAGE_HIZ)
+  return;
+
+   if (!blorp_can_hiz_clear_depth(GEN_GEN,
+  iview->planes[0].isl.format,
+  iview->image->samples,
+  render_area.offset.x,
+  render_area.offset.y,
+  render_area.offset.x +
+  render_area.extent.width,
+  render_area.offset.y +
+  render_area.extent.height))
+  return;
+
+   if (att_state->clear_value.depthStencil.depth != ANV_HZ_FC_VAL)
+  return;
+
+   if (GEN_GEN == 8 && anv_can_sample_with_hiz(>info, iview->image)) {
+  /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
+   * fast-cleared portion of a HiZ buffer. Testing has revealed that Gen8
+   * only supports returning 0.0f. Gens prior to gen8 do not support this
+   * feature at all.
+   */
+  return;
+   }
+
+   /* If we got here, then we can fast clear */
+   att_state->fast_clear = true;
+}
+
 static bool
 need_input_attachment_state(const struct anv_render_pass_attachment *att)
 {
@@ -1113,12 +1180,9 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
 add_image_view_relocs(cmd_buffer, iview, 0,
   state->attachments[i].color);
  } else {
-/* This field will be initialized after the first subpass
- * transition.
- */
-state->attachments[i].aux_usage = ISL_AUX_USAGE_NONE;
-
-state->attachments[i].input_aux_usage = ISL_AUX_USAGE_NONE;
+depth_stencil_attachment_compute_aux_usage(cmd_buffer->device,
+   state, i,
+   begin->renderArea);
  }
 
  if (need_input_attachment_state(>attachments[i])) {
@@ -3539,35 +3603,8 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
VK_IMAGE_ASPECT_STENCIL_BIT));
 
   if (att_state->pending_clear_aspects) {
- bool clear_with_hiz = att_state->aux_usage == ISL_AUX_USAGE_HIZ;
- if (clear_with_hiz &&
- (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
-if (!blorp_can_hiz_clear_depth(GEN_GEN,
-   iview->planes[0].isl.format,
-   iview->image->samples,
-   render_area.offset.x,
-   

[Mesa-dev] [PATCH v3 05/18] anv/cmd_buffer: Apply subpass flushes before set_subpass

2018-02-14 Thread Jason Ekstrand
This seems slightly more correct because it means that the flushes
happen before any clears or resolves implied by the subpass transition.

Reviewed-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index a16b742..cc3832f 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3500,10 +3500,10 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
-
cmd_buffer->state.pending_pipe_bits |=
   cmd_buffer->state.pass->subpass_flushes[0];
+
+   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
 }
 
 void genX(CmdNextSubpass)(
@@ -3523,11 +3523,11 @@ void genX(CmdNextSubpass)(
 */
cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
-
uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
cmd_buffer->state.pending_pipe_bits |=
   cmd_buffer->state.pass->subpass_flushes[subpass_id];
+
+   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 02/18] anv: Be more careful about fast-clear colors

2018-02-14 Thread Jason Ekstrand
Previously, we just used all the channels regardless of the format.
This is less than ideal because some channels may have undefined values
and this should be ok from the client's perspective.  Even though the
driver should do the correct thing regardless of what is in the
undefined value, it makes things less deterministic.  In particular, the
driver may choose to fast-clear or not based on undefined values.  This
level of nondeterminism is bad.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/vulkan/genX_cmd_buffer.c | 46 --
 1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index ce47b8a..8b1816a 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -202,24 +202,6 @@ add_image_view_relocs(struct anv_cmd_buffer *cmd_buffer,
}
 }
 
-static bool
-color_is_zero_one(VkClearColorValue value, enum isl_format format)
-{
-   if (isl_format_has_int_channel(format)) {
-  for (unsigned i = 0; i < 4; i++) {
- if (value.int32[i] != 0 && value.int32[i] != 1)
-return false;
-  }
-   } else {
-  for (unsigned i = 0; i < 4; i++) {
- if (value.float32[i] != 0.0f && value.float32[i] != 1.0f)
-return false;
-  }
-   }
-
-   return true;
-}
-
 static void
 color_attachment_compute_aux_usage(struct anv_device * device,
struct anv_cmd_state * cmd_state,
@@ -283,13 +265,25 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
 
assert(iview->image->planes[0].aux_surface.isl.usage & 
ISL_SURF_USAGE_CCS_BIT);
 
+   const struct isl_format_layout *view_fmtl =
+  isl_format_get_layout(iview->planes[0].isl.format);
+   union isl_color_value clear_color = {};
+
+#define COPY_CLEAR_COLOR_CHANNEL(c, i) \
+   if (view_fmtl->channels.c.bits) \
+  clear_color.u32[i] = att_state->clear_value.color.uint32[i]
+
+   COPY_CLEAR_COLOR_CHANNEL(r, 0);
+   COPY_CLEAR_COLOR_CHANNEL(g, 1);
+   COPY_CLEAR_COLOR_CHANNEL(b, 2);
+   COPY_CLEAR_COLOR_CHANNEL(a, 3);
+
+#undef COPY_CLEAR_COLOR_CHANNEL
+
att_state->clear_color_is_zero_one =
-  color_is_zero_one(att_state->clear_value.color, 
iview->planes[0].isl.format);
+  isl_color_value_is_zero_one(clear_color, iview->planes[0].isl.format);
att_state->clear_color_is_zero =
-  att_state->clear_value.color.uint32[0] == 0 &&
-  att_state->clear_value.color.uint32[1] == 0 &&
-  att_state->clear_value.color.uint32[2] == 0 &&
-  att_state->clear_value.color.uint32[3] == 0;
+  isl_color_value_is_zero(clear_color, iview->planes[0].isl.format);
 
if (att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT) {
   /* Start off assuming fast clears are possible */
@@ -341,10 +335,8 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
"LOAD_OP_CLEAR.  Only fast-clearing the first slice");
   }
 
-  if (att_state->fast_clear) {
- memcpy(fast_clear_color->u32, att_state->clear_value.color.uint32,
-sizeof(fast_clear_color->u32));
-  }
+  if (att_state->fast_clear)
+ *fast_clear_color = clear_color;
} else {
   att_state->fast_clear = false;
}
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 03/18] intel/blorp: Use the hardware op for CCS ambiguate on gen10+

2018-02-14 Thread Jason Ekstrand
Cannonlake hardware adds a new resolve type in 3DSTATE_PS called
FAST_CLEAR_0 which does an ambiguate.  Now that the hardware can do it
directly, we should use that instead of binding the CCS as a render
target and doing it manually.  This was tested with a full Vulkan CTS
run on Cannonlake.
---
 src/intel/blorp/blorp_clear.c | 12 +++-
 src/intel/blorp/blorp_genX_exec.h |  6 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
index 421a6c5..4ba65d0 100644
--- a/src/intel/blorp/blorp_clear.c
+++ b/src/intel/blorp/blorp_clear.c
@@ -758,7 +758,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
params.x1 = ALIGN(params.x1, x_scaledown) / x_scaledown;
params.y1 = ALIGN(params.y1, y_scaledown) / y_scaledown;
 
-   if (batch->blorp->isl_dev->info->gen >= 9) {
+   if (batch->blorp->isl_dev->info->gen >= 10) {
+  assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
+ resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE ||
+ resolve_op == ISL_AUX_OP_AMBIGUATE);
+   } else if (batch->blorp->isl_dev->info->gen >= 9) {
   assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
  resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE);
} else {
@@ -893,6 +897,12 @@ blorp_ccs_ambiguate(struct blorp_batch *batch,
 struct blorp_surf *surf,
 uint32_t level, uint32_t layer)
 {
+   if (ISL_DEV_GEN(batch->blorp->isl_dev) >= 10) {
+  /* On gen10 and above, we have a hardware resolve op for this */
+  return blorp_ccs_resolve(batch, surf, level, layer, 1,
+   surf->surf->format, ISL_AUX_OP_AMBIGUATE);
+   }
+
struct blorp_params params;
blorp_params_init();
 
diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index 5e1312a..85abf6b 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -752,6 +752,12 @@ blorp_emit_ps_config(struct blorp_batch *batch,
   switch (params->fast_clear_op) {
   case ISL_AUX_OP_NONE:
  break;
+#if GEN_GEN >= 10
+  case ISL_AUX_OP_AMBIGUATE:
+ ps.RenderTargetFastClearEnable = true;
+ ps.RenderTargetResolveType = FAST_CLEAR_0;
+ break;
+#endif
 #if GEN_GEN >= 9
   case ISL_AUX_OP_PARTIAL_RESOLVE:
  ps.RenderTargetResolveType = RESOLVE_PARTIAL;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 00/18] Rework subpass clears and transitions

2018-02-14 Thread Jason Ekstrand
This is another version of my patch series to rework subpass clears and
transitions.  It's fairly similar to the other one I sent out except that
it's been rebased on top of the resolve reworks and has some fixes from
Nanley.  There are also two patches on the front side to remove some
potential non-determanism in the Vulkan driver.

Jason Ekstrand (18):
  intel/isl: Add an isl_color_value_is_zero helper
  anv: Be more careful about fast-clear colors
  intel/blorp: Use the hardware op for CCS ambiguate on gen10+
  anv: Use framebuffer layers for implicit subpass transitions
  anv/cmd_buffer: Apply subpass flushes before set_subpass
  anv/cmd_buffer: Add begin/end_subpass helpers
  anv/cmd_buffer: Pass a subpass id into begin_subpass
  anv/cmd_buffer: Move the color portion of clear_subpass into
begin_subpass
  intel/blorp: Add a blorp_hiz_clear_depth_stencil helper
  anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass
  anv/cmd_buffer: Decide whether or not to HiZ clear up-front
  anv/cmd_buffer: Iterate all subpass attachments when clearing
  anv/cmd_buffer: Add a concept of pending load aspects
  anv/pass: Store usage in each subpass attachment
  anv/cmd_buffer: Sync clear values in begin_subpass
  anv/cmd_buffer: Mark depth/stencil surfaces written in begin_subpass
  anv/cmd_buffer: Do subpass image transitions in begin/end_subpass
  anv/cmd_buffer: Avoid unnecessary transitions before fast clears

 src/intel/blorp/blorp.h|  11 +
 src/intel/blorp/blorp_clear.c  |  65 +++-
 src/intel/blorp/blorp_genX_exec.h  |   6 +
 src/intel/isl/isl.c|  20 ++
 src/intel/isl/isl.h|   3 +
 src/intel/vulkan/anv_blorp.c   | 366 -
 src/intel/vulkan/anv_pass.c|  35 +-
 src/intel/vulkan/anv_private.h |  42 ++-
 src/intel/vulkan/genX_cmd_buffer.c | 644 +
 9 files changed, 663 insertions(+), 529 deletions(-)

-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 04/18] anv: Use framebuffer layers for implicit subpass transitions

2018-02-14 Thread Jason Ekstrand
---
 src/intel/vulkan/genX_cmd_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 8b1816a..a16b742 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3324,7 +3324,7 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
  iview->planes[0].isl.base_level);
  } else {
 base_layer = iview->planes[0].isl.base_array_layer;
-layer_count = iview->planes[0].isl.array_len;
+layer_count = cmd_state->framebuffer->layers;
  }
 
  transition_color_buffer(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v3 01/18] intel/isl: Add an isl_color_value_is_zero helper

2018-02-14 Thread Jason Ekstrand
Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/isl/isl.c | 20 
 src/intel/isl/isl.h |  3 +++
 2 files changed, 23 insertions(+)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 59f512f..f4b0502 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -269,6 +269,26 @@ isl_tiling_get_info(enum isl_tiling tiling,
 }
 
 bool
+isl_color_value_is_zero(union isl_color_value value,
+enum isl_format format)
+{
+   const struct isl_format_layout *fmtl = isl_format_get_layout(format);
+
+#define RETURN_FALSE_IF_NOT_0(c, i) \
+   if (fmtl->channels.c.bits && value.u32[i] != 0) \
+  return false
+
+   RETURN_FALSE_IF_NOT_0(r, 0);
+   RETURN_FALSE_IF_NOT_0(g, 1);
+   RETURN_FALSE_IF_NOT_0(b, 2);
+   RETURN_FALSE_IF_NOT_0(a, 3);
+
+#undef RETURN_FALSE_IF_NOT_0
+
+   return true;
+}
+
+bool
 isl_color_value_is_zero_one(union isl_color_value value,
 enum isl_format format)
 {
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index fda2411..209769a 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1692,6 +1692,9 @@ isl_extent4d(uint32_t width, uint32_t height, uint32_t 
depth,
return e;
 }
 
+bool isl_color_value_is_zero(union isl_color_value value,
+ enum isl_format format);
+
 bool isl_color_value_is_zero_one(union isl_color_value value,
  enum isl_format format);
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

2018-02-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105098

Bug ID: 105098
   Summary: [RADV] GPU freeze with simple Vulkan App
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: openproggerfr...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

I tried to start with developing in Vulkan. I finally got something on screen
but after some seconds the system freezes.
I tried also the source from Vulkan Tutorial
(https://github.com/Overv/VulkanTutorial/tree/master/code) which triggers the
same behaviour.
Some seconds after running an app, which renders fine, the display freezes and
the LEDs on the GPU are full (means 100% GPU load).
It's still possible to ssh but the dmesg shows nothing and hard reset is needed
because shutdown process hangs also. Looks like an infinite loop inside the
GPU.
On my laptop(AMDGPU OLAND) it runs without freeze(output is a but corrupted but
it's another issue).

Tried with vanilla Kernel 4.15 and drm-next-4.17-wip branch
LLVM 5.0 and 6.0
mesa 18.0.0-RC4 and git
always the same problem and doesn't matter if running under X11/XCB or Wayland.
If I comment out vkQueueSubmit(so it does render nothing), the output is
garbage but it doesn't hang. Maybe a issue with queue handling?

-- 
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] i965: Add gl_state_index casts for PATCH_VERTICES_IN

2018-02-14 Thread Kenneth Graunke
On Wednesday, February 14, 2018 10:17:07 AM PST Jason Ekstrand wrote:
> On Wed, Feb 14, 2018 at 10:12 AM, Kenneth Graunke 
> wrote:
> 
> > On Wednesday, February 14, 2018 6:05:22 AM PST Marek Olšák wrote:
> > > On Wed, Feb 14, 2018 at 7:57 AM, Kenneth Graunke 
> > wrote:
> > > > On Tuesday, February 13, 2018 2:57:07 PM PST Jason Ekstrand wrote:
> > > >> This fixes the build in clang
> > > >> ---
> > > >>  src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 3 ++-
> > > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > > >> index 10a4ff4..69da83a 100644
> > > >> --- a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > > >> +++ b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > > >> @@ -254,7 +254,8 @@ 
> > > >> brw_nir_lower_patch_vertices_in_to_uniform(nir_shader
> > *nir)
> > > >>gl_state_index16 tokens[STATE_LENGTH] = {
> > > >>   STATE_INTERNAL,
> > > >>   nir->info.stage == MESA_SHADER_TESS_CTRL ?
> > > >> -STATE_TCS_PATCH_VERTICES_IN :
> > STATE_TES_PATCH_VERTICES_IN,
> > > >> +(gl_state_index16)STATE_TCS_PATCH_VERTICES_IN :
> > > >> +(gl_state_index16)STATE_TES_PATCH_VERTICES_IN,
> > > >>};
> > > >>var->num_state_slots = 1;
> > > >>var->state_slots =
> > > >>
> > > >
> > > > This is fine, but I prefer your plan from IRC:
> > > >
> > > > 1. Add STATE_MAX_VALUE = 0x to the enum.
> > > > 2. Mark the enum PACKED.
> > > > 3. Drop gl_state_index16 again, since gl_state_index should now be the
> > > >desired size, and also an actual enum so it follows the actual C++
> > > >enum rules.
> > > >
> > > > I suppose the downside is that it could cause "case not handled in
> > > > switch" warnings...
> > >
> > > While I don't care too much about how gl_state_index is done,
> > > gl_state_index can also contain arbitrary 16-bit signed integer
> > > values, i.e. it's not strictly enum. And yes, I said "signed".
> > >
> > > Marek
> >
> > Oh. :(  I guess using short or int16_t is pretty reasonable then...
> >
> 
> Does that mean we're happy with this patch?

Yeah, sorry, should have been clearer:

Reviewed-by: Kenneth Graunke 


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


Re: [Mesa-dev] [PATCH] i965: Add gl_state_index casts for PATCH_VERTICES_IN

2018-02-14 Thread Jason Ekstrand
On Wed, Feb 14, 2018 at 10:12 AM, Kenneth Graunke 
wrote:

> On Wednesday, February 14, 2018 6:05:22 AM PST Marek Olšák wrote:
> > On Wed, Feb 14, 2018 at 7:57 AM, Kenneth Graunke 
> wrote:
> > > On Tuesday, February 13, 2018 2:57:07 PM PST Jason Ekstrand wrote:
> > >> This fixes the build in clang
> > >> ---
> > >>  src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 3 ++-
> > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > >> index 10a4ff4..69da83a 100644
> > >> --- a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > >> +++ b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> > >> @@ -254,7 +254,8 @@ brw_nir_lower_patch_vertices_in_to_uniform(nir_shader
> *nir)
> > >>gl_state_index16 tokens[STATE_LENGTH] = {
> > >>   STATE_INTERNAL,
> > >>   nir->info.stage == MESA_SHADER_TESS_CTRL ?
> > >> -STATE_TCS_PATCH_VERTICES_IN :
> STATE_TES_PATCH_VERTICES_IN,
> > >> +(gl_state_index16)STATE_TCS_PATCH_VERTICES_IN :
> > >> +(gl_state_index16)STATE_TES_PATCH_VERTICES_IN,
> > >>};
> > >>var->num_state_slots = 1;
> > >>var->state_slots =
> > >>
> > >
> > > This is fine, but I prefer your plan from IRC:
> > >
> > > 1. Add STATE_MAX_VALUE = 0x to the enum.
> > > 2. Mark the enum PACKED.
> > > 3. Drop gl_state_index16 again, since gl_state_index should now be the
> > >desired size, and also an actual enum so it follows the actual C++
> > >enum rules.
> > >
> > > I suppose the downside is that it could cause "case not handled in
> > > switch" warnings...
> >
> > While I don't care too much about how gl_state_index is done,
> > gl_state_index can also contain arbitrary 16-bit signed integer
> > values, i.e. it's not strictly enum. And yes, I said "signed".
> >
> > Marek
>
> Oh. :(  I guess using short or int16_t is pretty reasonable then...
>

Does that mean we're happy with this patch?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Add gl_state_index casts for PATCH_VERTICES_IN

2018-02-14 Thread Kenneth Graunke
On Wednesday, February 14, 2018 6:05:22 AM PST Marek Olšák wrote:
> On Wed, Feb 14, 2018 at 7:57 AM, Kenneth Graunke  
> wrote:
> > On Tuesday, February 13, 2018 2:57:07 PM PST Jason Ekstrand wrote:
> >> This fixes the build in clang
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp 
> >> b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> >> index 10a4ff4..69da83a 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
> >> @@ -254,7 +254,8 @@ brw_nir_lower_patch_vertices_in_to_uniform(nir_shader 
> >> *nir)
> >>gl_state_index16 tokens[STATE_LENGTH] = {
> >>   STATE_INTERNAL,
> >>   nir->info.stage == MESA_SHADER_TESS_CTRL ?
> >> -STATE_TCS_PATCH_VERTICES_IN : STATE_TES_PATCH_VERTICES_IN,
> >> +(gl_state_index16)STATE_TCS_PATCH_VERTICES_IN :
> >> +(gl_state_index16)STATE_TES_PATCH_VERTICES_IN,
> >>};
> >>var->num_state_slots = 1;
> >>var->state_slots =
> >>
> >
> > This is fine, but I prefer your plan from IRC:
> >
> > 1. Add STATE_MAX_VALUE = 0x to the enum.
> > 2. Mark the enum PACKED.
> > 3. Drop gl_state_index16 again, since gl_state_index should now be the
> >desired size, and also an actual enum so it follows the actual C++
> >enum rules.
> >
> > I suppose the downside is that it could cause "case not handled in
> > switch" warnings...
> 
> While I don't care too much about how gl_state_index is done,
> gl_state_index can also contain arbitrary 16-bit signed integer
> values, i.e. it's not strictly enum. And yes, I said "signed".
> 
> Marek

Oh. :(  I guess using short or int16_t is pretty reasonable then...


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 13/16] anv/image: Add support for modifiers for WSI

2018-02-14 Thread Daniel Stone
On 14 February 2018 at 17:58, Jason Ekstrand  wrote:
> I've added the following to the top of wsi_create_native_image:
>
> +   /* If we don't support modifiers, the winsys code shouldn't be asking
> for
> +* an image with modifiers.
> +*/
> +   assert(wsi->supports_modifiers || num_modifier_lists == 0);
>
>>
>> Yeah, it was mostly based on missing the wsi->has_modifiers check in
>> the Wayland
>
>
> Wayland definitely has the check.  I'll double-check on X11.

It didn't. I've added it in my branch, which I've been holding off on
sending out whilst we try to converge here. I'm currently doing a last
sweep through the X11 modifiers support from Louis-Francis as well.

https://gitlab.collabora.com/daniels/mesa # wip/dri3-v1.1

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


Re: [Mesa-dev] [PATCH 2/2] anv/pipeline: Set the correct binding count for compute shaders

2018-02-14 Thread Kenneth Graunke
On Wednesday, February 14, 2018 8:28:54 AM PST Jason Ekstrand wrote:
> On Tue, Feb 13, 2018 at 11:06 PM, Kenneth Graunke 
> wrote:
> 
> > On Monday, February 12, 2018 7:35:05 PM PST Jason Ekstrand wrote:
> > > ---
> > >  src/intel/vulkan/genX_pipeline.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_
> > pipeline.c
> > > index 45ebe31..4aee9ec 100644
> > > --- a/src/intel/vulkan/genX_pipeline.c
> > > +++ b/src/intel/vulkan/genX_pipeline.c
> > > @@ -1836,7 +1836,7 @@ compute_pipeline_create(
> > >.KernelStartPointer = cs_bin->kernel.offset,
> > >
> > >.SamplerCount   = get_sampler_count(cs_bin),
> > > -  .BindingTableEntryCount = get_binding_table_entry_count(cs_bin),
> > > +  .BindingTableEntryCount = 1 + MIN2(cs_bin->bind_map.surface_count,
> > 30),
> > >.BarrierEnable  = cs_prog_data->uses_barrier,
> > >.SharedLocalMemorySize  =
> > >   encode_slm_size(GEN_GEN, cs_prog_data->base.total_shared),
> > >
> >
> > Shouldn't this be MIN2(cs_bin->bind_map.surface_count, 31)?  It's simply
> > a U5 value, not a U5-1 value...and says there are a maximum of 31 things
> > that can be prefetched.
> >
> 
> I'm adding 1 for the indirect parameters buffer.

Ah.  A comment would be nice.

Reviewed-by: Kenneth Graunke 

> > While we're here, I don't understand why get_binding_table_entry_count
> > is DIV_ROUND_UP(bin->bind_map.surface_count, 32)...the docs for
> > 3DSTATE_VS indicate that it's simply a 0..255 value.
> >
> 
> Uh... I'm not sure.  I know I had a reason but maybe it's now bogus.


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 13/16] anv/image: Add support for modifiers for WSI

2018-02-14 Thread Jason Ekstrand
On Wed, Feb 14, 2018 at 8:35 AM, Daniel Stone  wrote:

> On 14 February 2018 at 16:21, Jason Ekstrand  wrote:
> > On Wed, Feb 14, 2018 at 4:13 AM, Daniel Stone 
> wrote:
> >> Suggested fixup: https://hastebin.com/zaheyoriwa
> >>
> >> This makes sure we only try to allocate with modifiers when _both_
> >> winsys and driver support it.
> >
> > Ok, we clearly have different philosophies here so we should get that
> > sorted.  My philosophy is that the winsys code will look at the
> > wsi_device::supports_modifiers flag and not ask for modifiers if it's
> false.
> > You seem to think that the winsys code should just go ahead and ask for
> > modifiers all the time and we will try to deal with it in
> wsi_create_native.
> > Thoughts?  Arguments?  Strong opinions?
> >
> > If we keep my philosophy, we should add asserts to better document and
> > enforce it.
>

I've added the following to the top of wsi_create_native_image:

+   /* If we don't support modifiers, the winsys code shouldn't be asking
for
+* an image with modifiers.
+*/
+   assert(wsi->supports_modifiers || num_modifier_lists == 0);


> Yeah, it was mostly based on missing the wsi->has_modifiers check in
> the Wayland


Wayland definitely has the check.  I'll double-check on X11.


> code, and it being totally absent in the X11/DRI3 code
> (trivial to add). So my philosophy was mostly about avoiding asserts,
> rather than strong feelings about who should do the filtering.
>
> I'm happy to stick with how you have it, plus asserts. Thanks for the
> explanation!
>
> Cheers,
> Daniel
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 12/16] anv/image: Separate modifiers from legacy scanout

2018-02-14 Thread Jason Ekstrand
On Wed, Feb 14, 2018 at 9:42 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Wed, Feb 14, 2018 at 04:43:15PM +, Daniel Stone wrote:
> > On 14 February 2018 at 16:27, Jason Ekstrand 
> wrote:
> > > On Wed, Feb 14, 2018 at 3:39 AM, Daniel Stone 
> wrote:
> > >> > On Tue, Feb 13, 2018 at 10:48 AM, Daniel Stone <
> dan...@fooishbar.org> wrote:
> > >> >> For actual scanout, the kernel very specifically demands that if
> the
> > >> >> BO is X-tiled, then set_tiling be called with TILING_X. This
> applies
> > >> >> even if we explicitly allocate with MOD_X_TILED and pass that in
> via
> > >> >> drmModeAddFB2WithModifiers: there is an explicit check for
> > >> >> !!(bo_tiling == TILING_X) == !!(modifier == MOD_X_TILED).
> > >>
> > >> You missed this bit. Suggested fixup: https://hastebin.com/xikopobiza
> > >
> > > I was really hoping I'd read wrong.  I'm going with "that's a kernel
> bug".
>
> Old kernels required TILING_X with MOD_X.


How many kernels is that?


> I changed that at some
> point to allow TILING_NONE with any modifier, but otherwise we
> require the BO tiling to match the modifier. Ie. you still can't
> mix TILING_Y + MOD_X for example.
>

Right.  That's perfectly reasonable.  It should be either TILING_NONE or
match.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] st: add NIR GL_ARB_get_program_binary support

2018-02-14 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Tue, Feb 13, 2018 at 4:27 AM, Timothy Arceri  wrote:
> ---
>  src/mesa/state_tracker/st_context.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_context.c 
> b/src/mesa/state_tracker/st_context.c
> index 7e721572e0..e23f9fd70b 100644
> --- a/src/mesa/state_tracker/st_context.c
> +++ b/src/mesa/state_tracker/st_context.c
> @@ -758,6 +758,17 @@ st_init_driver_functions(struct pipe_screen *screen,
>
> /* GL_ARB_get_program_binary */
> functions->GetProgramBinaryDriverSHA1 = st_get_program_binary_driver_sha1;
> -   functions->ProgramBinarySerializeDriverBlob = st_serialise_tgsi_program;
> -   functions->ProgramBinaryDeserializeDriverBlob = 
> st_deserialise_tgsi_program;
> +
> +   enum pipe_shader_ir preferred_ir = (enum pipe_shader_ir)
> +  screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
> +   PIPE_SHADER_CAP_PREFERRED_IR);
> +   if (preferred_ir == PIPE_SHADER_IR_NIR) {
> +  functions->ProgramBinarySerializeDriverBlob = st_serialise_nir_program;
> +  functions->ProgramBinaryDeserializeDriverBlob =
> + st_deserialise_nir_program;
> +   } else {
> +  functions->ProgramBinarySerializeDriverBlob = 
> st_serialise_tgsi_program;
> +  functions->ProgramBinaryDeserializeDriverBlob =
> + st_deserialise_tgsi_program;
> +   }
>  }
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 12/16] anv/image: Separate modifiers from legacy scanout

2018-02-14 Thread Ville Syrjälä
On Wed, Feb 14, 2018 at 04:43:15PM +, Daniel Stone wrote:
> On 14 February 2018 at 16:27, Jason Ekstrand  wrote:
> > On Wed, Feb 14, 2018 at 3:39 AM, Daniel Stone  wrote:
> >> > On Tue, Feb 13, 2018 at 10:48 AM, Daniel Stone  
> >> > wrote:
> >> >> For actual scanout, the kernel very specifically demands that if the
> >> >> BO is X-tiled, then set_tiling be called with TILING_X. This applies
> >> >> even if we explicitly allocate with MOD_X_TILED and pass that in via
> >> >> drmModeAddFB2WithModifiers: there is an explicit check for
> >> >> !!(bo_tiling == TILING_X) == !!(modifier == MOD_X_TILED).
> >>
> >> You missed this bit. Suggested fixup: https://hastebin.com/xikopobiza
> >
> > I was really hoping I'd read wrong.  I'm going with "that's a kernel bug".

Old kernels required TILING_X with MOD_X. I changed that at some
point to allow TILING_NONE with any modifier, but otherwise we
require the BO tiling to match the modifier. Ie. you still can't
mix TILING_Y + MOD_X for example.

-- 
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radeonsi/nir: fix si_nir_load_tcs_varyings() for outputs

2018-02-14 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Wed, Feb 14, 2018 at 2:22 AM, Timothy Arceri  wrote:
> We were incorrectly using the input info for outputs.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 825cb9dd0e..ec03f537d0 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1254,11 +1254,20 @@ static LLVMValueRef si_nir_load_tcs_varyings(struct 
> ac_shader_abi *abi,
> param_index = LLVMConstInt(ctx->i32, const_index, 0);
> }
>
> +   ubyte *names;
> +   ubyte *indices;
> +   if (load_input) {
> +   names = info->input_semantic_name;
> +   indices = info->input_semantic_index;
> +   } else {
> +   names = info->output_semantic_name;
> +   indices = info->output_semantic_index;
> +   }
> +
> dw_addr = get_dw_address_from_generic_indices(ctx, stride, dw_addr,
>   vertex_index, 
> param_index,
>   driver_location,
> - 
> info->input_semantic_name,
> - 
> info->input_semantic_index,
> + names, indices,
>   is_patch);
>
> LLVMValueRef value[4];
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] ac: implement nir_intrinsic_image_samples

2018-02-14 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Tue, Feb 13, 2018 at 7:01 AM, Timothy Arceri  wrote:
> Fixes cts test:
> KHR-GL45.shader_texture_image_samples_tests.image_functional_test
> ---
>  src/amd/common/ac_nir_to_llvm.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 3af3dbace2..8d1eed241f 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3785,6 +3785,26 @@ static LLVMValueRef visit_image_atomic(struct 
> ac_nir_context *ctx,
> return ac_build_intrinsic(>ac, intrinsic_name, ctx->ac.i32, 
> params, param_count, 0);
>  }
>
> +static LLVMValueRef visit_image_samples(struct ac_nir_context *ctx,
> +   const nir_intrinsic_instr *instr)
> +{
> +   const nir_variable *var = instr->variables[0]->var;
> +   const struct glsl_type *type = glsl_without_array(var->type);
> +   bool da = glsl_sampler_type_is_array(type) ||
> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE ||
> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
> +
> +   struct ac_image_args args = { 0 };
> +   args.da = da;
> +   args.dmask = 0xf;
> +   args.resource = get_sampler_desc(ctx, instr->variables[0],
> +AC_DESC_IMAGE, NULL, true, false);
> +   args.opcode = ac_image_get_resinfo;
> +   args.addr = ctx->ac.i32_0;
> +
> +   return ac_build_image_opcode(>ac, );
> +}
> +
>  static LLVMValueRef visit_image_size(struct ac_nir_context *ctx,
>  const nir_intrinsic_instr *instr)
>  {
> @@ -4483,6 +4503,9 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
> case nir_intrinsic_store_shared:
> visit_store_shared(ctx, instr);
> break;
> +   case nir_intrinsic_image_samples:
> +   result = visit_image_samples(ctx, instr);
> +   break;
> case nir_intrinsic_image_load:
> result = visit_image_load(ctx, instr);
> break;
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   >