Re: [Mesa-dev] [PATCH 1/3] etnaviv: Add support for extended texture formats

[Wladimir J. van der Laan]

> Thx - will send out updated patches the next days. I quite busy with
> lot of stuff atm but
> a long weekend is coming :)

Yeah np I could update my patches to that too and re-send them if that
is more convenient,

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

Re: [Mesa-dev] [PATCH 0/6] Prehash all the things

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on radeonsi/RX580

Unigine_Heaven-4.0, Unigine_Valley-1.0, Unigine_Superposition-1.0,
LS2015 (Wine-staging), Mesa-demos (objviewer)

Dieter

Am 22.05.2017 20:55, schrieb Thomas Helland:

While this doesn't prehash all the things, it does switch quite a lot
of places from doing a search and then a subsequent insert to first
hash the key, and then use this hash when searching / inserting.
While our new pointer hashing function remedied much of our overhead
hashing pointers, there is still more to gain here. This cuts executed
instructions / task-clock by about 0.5% on a shader-db run on my i965
running machine. While that's not a lot, it is still a nice little
improvement on the way to less overhead. The changes should also be
fairly trivial, so it's not much of a burden.

Thomas Helland (6):
  glsl: Prehash in refcount hash table to reduce hashing
  nir: Prehash in instr_set to avoid hashing twice
  glsl: Prehash in constant propagation
  glsl: Prehash in constant variable pass to avoid hashing twice
  glsl: Prehash to avoid computing the hash twice
  util: Avoid computing hash twice in string_to_uint_map

 src/compiler/glsl/ir_variable_refcount.cpp  | 7 +--
 src/compiler/glsl/opt_constant_propagation.cpp  | 8 +---
 src/compiler/glsl/opt_constant_variable.cpp | 6 --
 src/compiler/glsl/opt_copy_propagation_elements.cpp | 7 +--
 src/compiler/nir/nir_instr_set.c| 7 +--
 src/util/string_to_uint_map.h   | 9 ++---
 6 files changed, 30 insertions(+), 14 deletions(-)

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

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Timothy Arceri]

On 23/05/17 11:45, Rob Clark wrote:

On Mon, May 22, 2017 at 9:33 PM, Rob Clark  wrote:

On Mon, May 22, 2017 at 9:15 PM, Timothy Arceri  wrote:

On 23/05/17 10:44, Marek Olšák wrote:


On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri 
wrote:


On 23/05/17 05:02, Marek Olšák wrote:



On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle 
wrote:



Hi all,

I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
re-inventing
the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
re-using
that.

It's not entirely straightforward because radeonsi and radv use
different
"ABIs" for their shaders, i.e. prolog/epilog shader parts, different
user
SGPR allocations, descriptor loads work differently (obviously), and so
on.

Still, it's possible to separate the ABI from the meat of the NIR ->
LLVM
translation. So here goes...


The Step-by-Step Plan
=

1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
very
simple VS-PS pipelines.

2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
pipelines.

3. Fill in all the rest:
3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
3b. Geometry and tessellation shaders
3c. Compute shaders
3d. Tests

I've started with step 1 and got basic GLSL 1.30-level vertex shaders
working via NIR. The code is here:
https://cgit.freedesktop.org/~nh/mesa/log/?h=nir

The basic approach is to introduce `struct ac_shader_abi' to capture
the
differences between radeonsi and radv. In the end, the entry point for
NIR
-> LLVM translation will simply be:

  void ac_nir_translate(struct ac_llvm_context *ac,
struct ac_shader_abi *abi,
struct nir_shader *nir);

Setting up the LLVM function with its parameters is still considered
part
of
the driver.




This sounds good.




Questions
=

1. How do we get good test coverage?

A natural candidate would be to add a SPIR-V execution mode for the
piglit
shader_runner. That is, use build scripts to extract shaders from
shader_test files and feed them through glslang to get spv files, and
then
load those from shader_runner if a `-spirv' flag is passed on the
command
line.

This immediately runs into the difficulty that GL_ARB_gl_spirv wants
SSO
linking semantics, and I'm pretty sure the majority of shader_test
files
don't support that -- if only because they don't set a location on the
fragment shader color output.

Some ideas:
1. Add a GL_MESA_spirv_link_by_name extension
2. Have glslang add the locations for us (probably difficult because
glslang
seems to be focused on one shader stage at a time.)
3. Hack something together in the shader_test-to-spv build scripts via
regular expressions (and now we have two problems? :-) )
4. Other ideas?




We have plenty of GLSL SSO shader tests in shader-db, but we can only
compile-test them.

Initially I think we can convert a few shader tests to SSO manually
and use those.




2. What's the Gallium interface?

Specifically, does it pass SPIR-V or NIR?

I'm leaning towards NIR, because then specialization, mapping of
uniform
locations, atomics, etc. can be done entirely in st/mesa.

On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
third
hand, it wouldn't be the first time that clover does things
differently.




If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
LLVM, you wouldn't need the serialization capability in NIR. You can
just use SPIR-V as the shader binary and the major NIR disadvantage is
gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
shader cache will continue working as-is.

However, I don't know how much GL awareness is required for doing
SPIR-V -> NIR in radeonsi. Additional GL-specific information might
have to be added to SPIR-V by st/mesa for the conversion to be doable.
You probably know better.

st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
know how feasible that is, but it seems to be the only thing needed in
shared code.

That also answers the NIR vs TGSI debate for the shader cache. The
answer is: Neither.



Just to list some downsides to this approach, not switching the the GLSL
path to also use NIR has the following negatives:

1. We don't get to leverage the large GL test suits and app ecosystem for
testing the NIR -> LLVM pass both during development and afterwards.

2. Jason has already said it best so to quote his reply:
"There have been a variety of different discussions over the last few
years
about compiler design choices but we've lacked the ability to get any
good
apples-to-apples comparisons.  This may provide some opportunities to do
so."

3. The GLSL IR opts are both 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Jason Ekstrand]

On Mon, May 22, 2017 at 6:48 PM, Jason Ekstrand 
wrote:

> On Mon, May 22, 2017 at 6:45 PM, Rob Clark  wrote:
>
>> On Mon, May 22, 2017 at 9:33 PM, Rob Clark  wrote:
>> > On Mon, May 22, 2017 at 9:15 PM, Timothy Arceri 
>> wrote:
>> >> On 23/05/17 10:44, Marek Olšák wrote:
>> >>>
>> >>> On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri <
>> tarc...@itsqueeze.com>
>> >>> wrote:
>> 
>>  On 23/05/17 05:02, Marek Olšák wrote:
>> >
>> >
>> > On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle <
>> nhaeh...@gmail.com>
>> > wrote:
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
>> >> re-inventing
>> >> the ~8k LOC of src/compiler/spirv, and there's already a perfectly
>> fine
>> >> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
>> >> re-using
>> >> that.
>> >>
>> >> It's not entirely straightforward because radeonsi and radv use
>> >> different
>> >> "ABIs" for their shaders, i.e. prolog/epilog shader parts,
>> different
>> >> user
>> >> SGPR allocations, descriptor loads work differently (obviously),
>> and so
>> >> on.
>> >>
>> >> Still, it's possible to separate the ABI from the meat of the NIR
>> ->
>> >> LLVM
>> >> translation. So here goes...
>> >>
>> >>
>> >> The Step-by-Step Plan
>> >> =
>> >>
>> >> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir)
>> for
>> >> very
>> >> simple VS-PS pipelines.
>> >>
>> >> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
>> >> pipelines.
>> >>
>> >> 3. Fill in all the rest:
>> >> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
>> >> 3b. Geometry and tessellation shaders
>> >> 3c. Compute shaders
>> >> 3d. Tests
>> >>
>> >> I've started with step 1 and got basic GLSL 1.30-level vertex
>> shaders
>> >> working via NIR. The code is here:
>> >> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>> >>
>> >> The basic approach is to introduce `struct ac_shader_abi' to
>> capture
>> >> the
>> >> differences between radeonsi and radv. In the end, the entry point
>> for
>> >> NIR
>> >> -> LLVM translation will simply be:
>> >>
>> >>  void ac_nir_translate(struct ac_llvm_context *ac,
>> >>struct ac_shader_abi *abi,
>> >>struct nir_shader *nir);
>> >>
>> >> Setting up the LLVM function with its parameters is still
>> considered
>> >> part
>> >> of
>> >> the driver.
>> >
>> >
>> >
>> > This sounds good.
>> >
>> >>
>> >>
>> >> Questions
>> >> =
>> >>
>> >> 1. How do we get good test coverage?
>> >> 
>> >> A natural candidate would be to add a SPIR-V execution mode for the
>> >> piglit
>> >> shader_runner. That is, use build scripts to extract shaders from
>> >> shader_test files and feed them through glslang to get spv files,
>> and
>> >> then
>> >> load those from shader_runner if a `-spirv' flag is passed on the
>> >> command
>> >> line.
>> >>
>> >> This immediately runs into the difficulty that GL_ARB_gl_spirv
>> wants
>> >> SSO
>> >> linking semantics, and I'm pretty sure the majority of shader_test
>> >> files
>> >> don't support that -- if only because they don't set a location on
>> the
>> >> fragment shader color output.
>> >>
>> >> Some ideas:
>> >> 1. Add a GL_MESA_spirv_link_by_name extension
>> >> 2. Have glslang add the locations for us (probably difficult
>> because
>> >> glslang
>> >> seems to be focused on one shader stage at a time.)
>> >> 3. Hack something together in the shader_test-to-spv build scripts
>> via
>> >> regular expressions (and now we have two problems? :-) )
>> >> 4. Other ideas?
>> >
>> >
>> >
>> > We have plenty of GLSL SSO shader tests in shader-db, but we can
>> only
>> > compile-test them.
>> >
>> > Initially I think we can convert a few shader tests to SSO manually
>> > and use those.
>> >
>> >>
>> >>
>> >> 2. What's the Gallium interface?
>> >> 
>> >> Specifically, does it pass SPIR-V or NIR?
>> >>
>> >> I'm leaning towards NIR, because then specialization, mapping of
>> >> uniform
>> >> locations, atomics, etc. can be done entirely in st/mesa.
>> >>
>> >> On the other hand, Pierre Moreau's work passes SPIR-V directly. On
>> the
>> >> third
>> >> hand, it wouldn't be the first time that clover does things
>> >> differently.
>> >
>> >
>> >
>> > If you passed SPIR-V to radeonsi and let radeonsi do 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Jason Ekstrand]

On Mon, May 22, 2017 at 6:45 PM, Rob Clark  wrote:

> On Mon, May 22, 2017 at 9:33 PM, Rob Clark  wrote:
> > On Mon, May 22, 2017 at 9:15 PM, Timothy Arceri 
> wrote:
> >> On 23/05/17 10:44, Marek Olšák wrote:
> >>>
> >>> On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri <
> tarc...@itsqueeze.com>
> >>> wrote:
> 
>  On 23/05/17 05:02, Marek Olšák wrote:
> >
> >
> > On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle  >
> > wrote:
> >>
> >>
> >> Hi all,
> >>
> >> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
> >> re-inventing
> >> the ~8k LOC of src/compiler/spirv, and there's already a perfectly
> fine
> >> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
> >> re-using
> >> that.
> >>
> >> It's not entirely straightforward because radeonsi and radv use
> >> different
> >> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different
> >> user
> >> SGPR allocations, descriptor loads work differently (obviously),
> and so
> >> on.
> >>
> >> Still, it's possible to separate the ABI from the meat of the NIR ->
> >> LLVM
> >> translation. So here goes...
> >>
> >>
> >> The Step-by-Step Plan
> >> =
> >>
> >> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir)
> for
> >> very
> >> simple VS-PS pipelines.
> >>
> >> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
> >> pipelines.
> >>
> >> 3. Fill in all the rest:
> >> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
> >> 3b. Geometry and tessellation shaders
> >> 3c. Compute shaders
> >> 3d. Tests
> >>
> >> I've started with step 1 and got basic GLSL 1.30-level vertex
> shaders
> >> working via NIR. The code is here:
> >> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
> >>
> >> The basic approach is to introduce `struct ac_shader_abi' to capture
> >> the
> >> differences between radeonsi and radv. In the end, the entry point
> for
> >> NIR
> >> -> LLVM translation will simply be:
> >>
> >>  void ac_nir_translate(struct ac_llvm_context *ac,
> >>struct ac_shader_abi *abi,
> >>struct nir_shader *nir);
> >>
> >> Setting up the LLVM function with its parameters is still considered
> >> part
> >> of
> >> the driver.
> >
> >
> >
> > This sounds good.
> >
> >>
> >>
> >> Questions
> >> =
> >>
> >> 1. How do we get good test coverage?
> >> 
> >> A natural candidate would be to add a SPIR-V execution mode for the
> >> piglit
> >> shader_runner. That is, use build scripts to extract shaders from
> >> shader_test files and feed them through glslang to get spv files,
> and
> >> then
> >> load those from shader_runner if a `-spirv' flag is passed on the
> >> command
> >> line.
> >>
> >> This immediately runs into the difficulty that GL_ARB_gl_spirv wants
> >> SSO
> >> linking semantics, and I'm pretty sure the majority of shader_test
> >> files
> >> don't support that -- if only because they don't set a location on
> the
> >> fragment shader color output.
> >>
> >> Some ideas:
> >> 1. Add a GL_MESA_spirv_link_by_name extension
> >> 2. Have glslang add the locations for us (probably difficult because
> >> glslang
> >> seems to be focused on one shader stage at a time.)
> >> 3. Hack something together in the shader_test-to-spv build scripts
> via
> >> regular expressions (and now we have two problems? :-) )
> >> 4. Other ideas?
> >
> >
> >
> > We have plenty of GLSL SSO shader tests in shader-db, but we can only
> > compile-test them.
> >
> > Initially I think we can convert a few shader tests to SSO manually
> > and use those.
> >
> >>
> >>
> >> 2. What's the Gallium interface?
> >> 
> >> Specifically, does it pass SPIR-V or NIR?
> >>
> >> I'm leaning towards NIR, because then specialization, mapping of
> >> uniform
> >> locations, atomics, etc. can be done entirely in st/mesa.
> >>
> >> On the other hand, Pierre Moreau's work passes SPIR-V directly. On
> the
> >> third
> >> hand, it wouldn't be the first time that clover does things
> >> differently.
> >
> >
> >
> > If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
> > LLVM, you wouldn't need the serialization capability in NIR. You can
> > just use SPIR-V as the shader binary and the major NIR disadvantage
> is
> > gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
> 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Rob Clark]

On Mon, May 22, 2017 at 9:33 PM, Rob Clark  wrote:
> On Mon, May 22, 2017 at 9:15 PM, Timothy Arceri  wrote:
>> On 23/05/17 10:44, Marek Olšák wrote:
>>>
>>> On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri 
>>> wrote:

 On 23/05/17 05:02, Marek Olšák wrote:
>
>
> On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle 
> wrote:
>>
>>
>> Hi all,
>>
>> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
>> re-inventing
>> the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
>> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
>> re-using
>> that.
>>
>> It's not entirely straightforward because radeonsi and radv use
>> different
>> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different
>> user
>> SGPR allocations, descriptor loads work differently (obviously), and so
>> on.
>>
>> Still, it's possible to separate the ABI from the meat of the NIR ->
>> LLVM
>> translation. So here goes...
>>
>>
>> The Step-by-Step Plan
>> =
>>
>> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
>> very
>> simple VS-PS pipelines.
>>
>> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
>> pipelines.
>>
>> 3. Fill in all the rest:
>> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
>> 3b. Geometry and tessellation shaders
>> 3c. Compute shaders
>> 3d. Tests
>>
>> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
>> working via NIR. The code is here:
>> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>>
>> The basic approach is to introduce `struct ac_shader_abi' to capture
>> the
>> differences between radeonsi and radv. In the end, the entry point for
>> NIR
>> -> LLVM translation will simply be:
>>
>>  void ac_nir_translate(struct ac_llvm_context *ac,
>>struct ac_shader_abi *abi,
>>struct nir_shader *nir);
>>
>> Setting up the LLVM function with its parameters is still considered
>> part
>> of
>> the driver.
>
>
>
> This sounds good.
>
>>
>>
>> Questions
>> =
>>
>> 1. How do we get good test coverage?
>> 
>> A natural candidate would be to add a SPIR-V execution mode for the
>> piglit
>> shader_runner. That is, use build scripts to extract shaders from
>> shader_test files and feed them through glslang to get spv files, and
>> then
>> load those from shader_runner if a `-spirv' flag is passed on the
>> command
>> line.
>>
>> This immediately runs into the difficulty that GL_ARB_gl_spirv wants
>> SSO
>> linking semantics, and I'm pretty sure the majority of shader_test
>> files
>> don't support that -- if only because they don't set a location on the
>> fragment shader color output.
>>
>> Some ideas:
>> 1. Add a GL_MESA_spirv_link_by_name extension
>> 2. Have glslang add the locations for us (probably difficult because
>> glslang
>> seems to be focused on one shader stage at a time.)
>> 3. Hack something together in the shader_test-to-spv build scripts via
>> regular expressions (and now we have two problems? :-) )
>> 4. Other ideas?
>
>
>
> We have plenty of GLSL SSO shader tests in shader-db, but we can only
> compile-test them.
>
> Initially I think we can convert a few shader tests to SSO manually
> and use those.
>
>>
>>
>> 2. What's the Gallium interface?
>> 
>> Specifically, does it pass SPIR-V or NIR?
>>
>> I'm leaning towards NIR, because then specialization, mapping of
>> uniform
>> locations, atomics, etc. can be done entirely in st/mesa.
>>
>> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
>> third
>> hand, it wouldn't be the first time that clover does things
>> differently.
>
>
>
> If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
> LLVM, you wouldn't need the serialization capability in NIR. You can
> just use SPIR-V as the shader binary and the major NIR disadvantage is
> gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
> shader cache will continue working as-is.
>
> However, I don't know how much GL awareness is required for doing
> SPIR-V -> NIR in radeonsi. Additional GL-specific information might
> have to be added to SPIR-V by st/mesa for the conversion to be doable.
> You probably know better.
>
> st/mesa or core Mesa just needs to fill gl_program, 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Rob Clark]

On Mon, May 22, 2017 at 9:15 PM, Timothy Arceri  wrote:
> On 23/05/17 10:44, Marek Olšák wrote:
>>
>> On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri 
>> wrote:
>>>
>>> On 23/05/17 05:02, Marek Olšák wrote:


 On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle 
 wrote:
>
>
> Hi all,
>
> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
> re-inventing
> the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
> re-using
> that.
>
> It's not entirely straightforward because radeonsi and radv use
> different
> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different
> user
> SGPR allocations, descriptor loads work differently (obviously), and so
> on.
>
> Still, it's possible to separate the ABI from the meat of the NIR ->
> LLVM
> translation. So here goes...
>
>
> The Step-by-Step Plan
> =
>
> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
> very
> simple VS-PS pipelines.
>
> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
> pipelines.
>
> 3. Fill in all the rest:
> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
> 3b. Geometry and tessellation shaders
> 3c. Compute shaders
> 3d. Tests
>
> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
> working via NIR. The code is here:
> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>
> The basic approach is to introduce `struct ac_shader_abi' to capture
> the
> differences between radeonsi and radv. In the end, the entry point for
> NIR
> -> LLVM translation will simply be:
>
>  void ac_nir_translate(struct ac_llvm_context *ac,
>struct ac_shader_abi *abi,
>struct nir_shader *nir);
>
> Setting up the LLVM function with its parameters is still considered
> part
> of
> the driver.



 This sounds good.

>
>
> Questions
> =
>
> 1. How do we get good test coverage?
> 
> A natural candidate would be to add a SPIR-V execution mode for the
> piglit
> shader_runner. That is, use build scripts to extract shaders from
> shader_test files and feed them through glslang to get spv files, and
> then
> load those from shader_runner if a `-spirv' flag is passed on the
> command
> line.
>
> This immediately runs into the difficulty that GL_ARB_gl_spirv wants
> SSO
> linking semantics, and I'm pretty sure the majority of shader_test
> files
> don't support that -- if only because they don't set a location on the
> fragment shader color output.
>
> Some ideas:
> 1. Add a GL_MESA_spirv_link_by_name extension
> 2. Have glslang add the locations for us (probably difficult because
> glslang
> seems to be focused on one shader stage at a time.)
> 3. Hack something together in the shader_test-to-spv build scripts via
> regular expressions (and now we have two problems? :-) )
> 4. Other ideas?



 We have plenty of GLSL SSO shader tests in shader-db, but we can only
 compile-test them.

 Initially I think we can convert a few shader tests to SSO manually
 and use those.

>
>
> 2. What's the Gallium interface?
> 
> Specifically, does it pass SPIR-V or NIR?
>
> I'm leaning towards NIR, because then specialization, mapping of
> uniform
> locations, atomics, etc. can be done entirely in st/mesa.
>
> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
> third
> hand, it wouldn't be the first time that clover does things
> differently.



 If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
 LLVM, you wouldn't need the serialization capability in NIR. You can
 just use SPIR-V as the shader binary and the major NIR disadvantage is
 gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
 shader cache will continue working as-is.

 However, I don't know how much GL awareness is required for doing
 SPIR-V -> NIR in radeonsi. Additional GL-specific information might
 have to be added to SPIR-V by st/mesa for the conversion to be doable.
 You probably know better.

 st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
 gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
 know how feasible that is, but it seems to be the only thing needed in
 shared code.

 That also answers the 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Timothy Arceri]

On 23/05/17 10:44, Marek Olšák wrote:

On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri  wrote:

On 23/05/17 05:02, Marek Olšák wrote:


On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle 
wrote:


Hi all,

I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
re-inventing
the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
re-using
that.

It's not entirely straightforward because radeonsi and radv use different
"ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
SGPR allocations, descriptor loads work differently (obviously), and so
on.

Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
translation. So here goes...


The Step-by-Step Plan
=

1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
very
simple VS-PS pipelines.

2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
pipelines.

3. Fill in all the rest:
3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
3b. Geometry and tessellation shaders
3c. Compute shaders
3d. Tests

I've started with step 1 and got basic GLSL 1.30-level vertex shaders
working via NIR. The code is here:
https://cgit.freedesktop.org/~nh/mesa/log/?h=nir

The basic approach is to introduce `struct ac_shader_abi' to capture the
differences between radeonsi and radv. In the end, the entry point for
NIR
-> LLVM translation will simply be:

 void ac_nir_translate(struct ac_llvm_context *ac,
   struct ac_shader_abi *abi,
   struct nir_shader *nir);

Setting up the LLVM function with its parameters is still considered part
of
the driver.



This sounds good.




Questions
=

1. How do we get good test coverage?

A natural candidate would be to add a SPIR-V execution mode for the
piglit
shader_runner. That is, use build scripts to extract shaders from
shader_test files and feed them through glslang to get spv files, and
then
load those from shader_runner if a `-spirv' flag is passed on the command
line.

This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
linking semantics, and I'm pretty sure the majority of shader_test files
don't support that -- if only because they don't set a location on the
fragment shader color output.

Some ideas:
1. Add a GL_MESA_spirv_link_by_name extension
2. Have glslang add the locations for us (probably difficult because
glslang
seems to be focused on one shader stage at a time.)
3. Hack something together in the shader_test-to-spv build scripts via
regular expressions (and now we have two problems? :-) )
4. Other ideas?



We have plenty of GLSL SSO shader tests in shader-db, but we can only
compile-test them.

Initially I think we can convert a few shader tests to SSO manually
and use those.




2. What's the Gallium interface?

Specifically, does it pass SPIR-V or NIR?

I'm leaning towards NIR, because then specialization, mapping of uniform
locations, atomics, etc. can be done entirely in st/mesa.

On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
third
hand, it wouldn't be the first time that clover does things differently.



If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
LLVM, you wouldn't need the serialization capability in NIR. You can
just use SPIR-V as the shader binary and the major NIR disadvantage is
gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
shader cache will continue working as-is.

However, I don't know how much GL awareness is required for doing
SPIR-V -> NIR in radeonsi. Additional GL-specific information might
have to be added to SPIR-V by st/mesa for the conversion to be doable.
You probably know better.

st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
know how feasible that is, but it seems to be the only thing needed in
shared code.

That also answers the NIR vs TGSI debate for the shader cache. The
answer is: Neither.



Just to list some downsides to this approach, not switching the the GLSL
path to also use NIR has the following negatives:

1. We don't get to leverage the large GL test suits and app ecosystem for
testing the NIR -> LLVM pass both during development and afterwards.

2. Jason has already said it best so to quote his reply:
"There have been a variety of different discussions over the last few years
about compiler design choices but we've lacked the ability to get any good
apples-to-apples comparisons.  This may provide some opportunities to do
so."

3. The GLSL IR opts are both slow and not always optimal (possibly
transforming the code to something that's harder to opt later), but due to
uniform/varying optimisation requirements some optimisations are required
*before* we can 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Marek Olšák]

On Tue, May 23, 2017 at 12:07 AM, Timothy Arceri  wrote:
> On 23/05/17 05:02, Marek Olšák wrote:
>>
>> On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle 
>> wrote:
>>>
>>> Hi all,
>>>
>>> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
>>> re-inventing
>>> the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
>>> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into
>>> re-using
>>> that.
>>>
>>> It's not entirely straightforward because radeonsi and radv use different
>>> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
>>> SGPR allocations, descriptor loads work differently (obviously), and so
>>> on.
>>>
>>> Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
>>> translation. So here goes...
>>>
>>>
>>> The Step-by-Step Plan
>>> =
>>>
>>> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
>>> very
>>> simple VS-PS pipelines.
>>>
>>> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
>>> pipelines.
>>>
>>> 3. Fill in all the rest:
>>> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
>>> 3b. Geometry and tessellation shaders
>>> 3c. Compute shaders
>>> 3d. Tests
>>>
>>> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
>>> working via NIR. The code is here:
>>> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>>>
>>> The basic approach is to introduce `struct ac_shader_abi' to capture the
>>> differences between radeonsi and radv. In the end, the entry point for
>>> NIR
>>> -> LLVM translation will simply be:
>>>
>>> void ac_nir_translate(struct ac_llvm_context *ac,
>>>   struct ac_shader_abi *abi,
>>>   struct nir_shader *nir);
>>>
>>> Setting up the LLVM function with its parameters is still considered part
>>> of
>>> the driver.
>>
>>
>> This sounds good.
>>
>>>
>>>
>>> Questions
>>> =
>>>
>>> 1. How do we get good test coverage?
>>> 
>>> A natural candidate would be to add a SPIR-V execution mode for the
>>> piglit
>>> shader_runner. That is, use build scripts to extract shaders from
>>> shader_test files and feed them through glslang to get spv files, and
>>> then
>>> load those from shader_runner if a `-spirv' flag is passed on the command
>>> line.
>>>
>>> This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
>>> linking semantics, and I'm pretty sure the majority of shader_test files
>>> don't support that -- if only because they don't set a location on the
>>> fragment shader color output.
>>>
>>> Some ideas:
>>> 1. Add a GL_MESA_spirv_link_by_name extension
>>> 2. Have glslang add the locations for us (probably difficult because
>>> glslang
>>> seems to be focused on one shader stage at a time.)
>>> 3. Hack something together in the shader_test-to-spv build scripts via
>>> regular expressions (and now we have two problems? :-) )
>>> 4. Other ideas?
>>
>>
>> We have plenty of GLSL SSO shader tests in shader-db, but we can only
>> compile-test them.
>>
>> Initially I think we can convert a few shader tests to SSO manually
>> and use those.
>>
>>>
>>>
>>> 2. What's the Gallium interface?
>>> 
>>> Specifically, does it pass SPIR-V or NIR?
>>>
>>> I'm leaning towards NIR, because then specialization, mapping of uniform
>>> locations, atomics, etc. can be done entirely in st/mesa.
>>>
>>> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
>>> third
>>> hand, it wouldn't be the first time that clover does things differently.
>>
>>
>> If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
>> LLVM, you wouldn't need the serialization capability in NIR. You can
>> just use SPIR-V as the shader binary and the major NIR disadvantage is
>> gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
>> shader cache will continue working as-is.
>>
>> However, I don't know how much GL awareness is required for doing
>> SPIR-V -> NIR in radeonsi. Additional GL-specific information might
>> have to be added to SPIR-V by st/mesa for the conversion to be doable.
>> You probably know better.
>>
>> st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
>> gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
>> know how feasible that is, but it seems to be the only thing needed in
>> shared code.
>>
>> That also answers the NIR vs TGSI debate for the shader cache. The
>> answer is: Neither.
>>
>
> Just to list some downsides to this approach, not switching the the GLSL
> path to also use NIR has the following negatives:
>
> 1. We don't get to leverage the large GL test suits and app ecosystem for
> testing the NIR -> LLVM pass both during development and afterwards.
>
> 2. Jason has already said it best so to quote his reply:
> "There have been a variety of different discussions over the 

[Mesa-dev] [PATCH 2/2] st/dri: Use fence extension in drisw.c

[Gurchetan Singh]

This is desirable for synchronization in virtual machines.
---
 src/gallium/state_trackers/dri/drisw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/state_trackers/dri/drisw.c 
b/src/gallium/state_trackers/dri/drisw.c
index b85a73c57d..8fbfa9ecea 100644
--- a/src/gallium/state_trackers/dri/drisw.c
+++ b/src/gallium/state_trackers/dri/drisw.c
@@ -46,6 +46,7 @@
 #include "dri_screen.h"
 #include "dri_context.h"
 #include "dri_drawable.h"
+#include "dri_extensions.h"
 #include "dri_query_renderer.h"
 
 DEBUG_GET_ONCE_BOOL_OPTION(swrast_no_present, "SWRAST_NO_PRESENT", FALSE);
@@ -369,6 +370,7 @@ static const __DRIextension *drisw_screen_extensions[] = {
,
,
,
+   ,
NULL
 };
 
-- 
2.12.2

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

[Mesa-dev] [PATCH 1/2] st/dri: move fence implemention into separate file

[Gurchetan Singh]

Since the fence implementation is not dri2.c specific, put
it in a separate file. This way SW implementations can use this
extension too.

v2: Don't depend on dri2.c for extensions (Emil)
v3: Make this patch only move extension into a separate file (Chad).
---
 src/gallium/state_trackers/dri/Makefile.sources |   2 +
 src/gallium/state_trackers/dri/dri2.c   | 204 +
 src/gallium/state_trackers/dri/dri_extensions.c | 230 
 src/gallium/state_trackers/dri/dri_extensions.h |  30 
 4 files changed, 263 insertions(+), 203 deletions(-)
 create mode 100644 src/gallium/state_trackers/dri/dri_extensions.c
 create mode 100644 src/gallium/state_trackers/dri/dri_extensions.h

diff --git a/src/gallium/state_trackers/dri/Makefile.sources 
b/src/gallium/state_trackers/dri/Makefile.sources
index 52d60ac928..46da886c00 100644
--- a/src/gallium/state_trackers/dri/Makefile.sources
+++ b/src/gallium/state_trackers/dri/Makefile.sources
@@ -3,6 +3,8 @@ common_SOURCES := \
dri_context.h \
dri_drawable.c \
dri_drawable.h \
+   dri_extensions.c \
+   dri_extensions.h \
dri_query_renderer.c \
dri_query_renderer.h \
dri_screen.c \
diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index ed6004f836..20dee03b8b 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -29,7 +29,6 @@
  */
 
 #include 
-#include 
 #include 
 #include "GL/mesa_glinterop.h"
 #include "util/u_memory.h"
@@ -49,6 +48,7 @@
 #include "dri_screen.h"
 #include "dri_context.h"
 #include "dri_drawable.h"
+#include "dri_extensions.h"
 #include "dri_query_renderer.h"
 #include "dri2_buffer.h"
 
@@ -1415,208 +1415,6 @@ static __DRIimageExtension dri2ImageExtension = {
 .unmapImage   = dri2_unmap_image,
 };
 
-
-static bool
-dri2_is_opencl_interop_loaded_locked(struct dri_screen *screen)
-{
-   return screen->opencl_dri_event_add_ref &&
-  screen->opencl_dri_event_release &&
-  screen->opencl_dri_event_wait &&
-  screen->opencl_dri_event_get_fence;
-}
-
-static bool
-dri2_load_opencl_interop(struct dri_screen *screen)
-{
-#if defined(RTLD_DEFAULT)
-   bool success;
-
-   mtx_lock(>opencl_func_mutex);
-
-   if (dri2_is_opencl_interop_loaded_locked(screen)) {
-  mtx_unlock(>opencl_func_mutex);
-  return true;
-   }
-
-   screen->opencl_dri_event_add_ref =
-  dlsym(RTLD_DEFAULT, "opencl_dri_event_add_ref");
-   screen->opencl_dri_event_release =
-  dlsym(RTLD_DEFAULT, "opencl_dri_event_release");
-   screen->opencl_dri_event_wait =
-  dlsym(RTLD_DEFAULT, "opencl_dri_event_wait");
-   screen->opencl_dri_event_get_fence =
-  dlsym(RTLD_DEFAULT, "opencl_dri_event_get_fence");
-
-   success = dri2_is_opencl_interop_loaded_locked(screen);
-   mtx_unlock(>opencl_func_mutex);
-   return success;
-#else
-   return false;
-#endif
-}
-
-struct dri2_fence {
-   struct dri_screen *driscreen;
-   struct pipe_fence_handle *pipe_fence;
-   void *cl_event;
-};
-
-static unsigned dri2_fence_get_caps(__DRIscreen *_screen)
-{
-   struct dri_screen *driscreen = dri_screen(_screen);
-   struct pipe_screen *screen = driscreen->base.screen;
-   unsigned caps = 0;
-
-   if (screen->get_param(screen, PIPE_CAP_NATIVE_FENCE_FD))
-  caps |= __DRI_FENCE_CAP_NATIVE_FD;
-
-   return caps;
-}
-
-static void *
-dri2_create_fence(__DRIcontext *_ctx)
-{
-   struct pipe_context *ctx = dri_context(_ctx)->st->pipe;
-   struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
-
-   if (!fence)
-  return NULL;
-
-   ctx->flush(ctx, >pipe_fence, 0);
-
-   if (!fence->pipe_fence) {
-  FREE(fence);
-  return NULL;
-   }
-
-   fence->driscreen = dri_screen(_ctx->driScreenPriv);
-   return fence;
-}
-
-static void *
-dri2_create_fence_fd(__DRIcontext *_ctx, int fd)
-{
-   struct pipe_context *ctx = dri_context(_ctx)->st->pipe;
-   struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
-
-   if (fd == -1) {
-  /* exporting driver created fence, flush: */
-  ctx->flush(ctx, >pipe_fence,
- PIPE_FLUSH_DEFERRED | PIPE_FLUSH_FENCE_FD);
-   } else {
-  /* importing a foreign fence fd: */
-  ctx->create_fence_fd(ctx, >pipe_fence, fd);
-   }
-   if (!fence->pipe_fence) {
-  FREE(fence);
-  return NULL;
-   }
-
-   fence->driscreen = dri_screen(_ctx->driScreenPriv);
-   return fence;
-}
-
-static int
-dri2_get_fence_fd(__DRIscreen *_screen, void *_fence)
-{
-   struct dri_screen *driscreen = dri_screen(_screen);
-   struct pipe_screen *screen = driscreen->base.screen;
-   struct dri2_fence *fence = (struct dri2_fence*)_fence;
-
-   return screen->fence_get_fd(screen, fence->pipe_fence);
-}
-
-static void *
-dri2_get_fence_from_cl_event(__DRIscreen *_screen, intptr_t cl_event)
-{
-   struct dri_screen *driscreen = dri_screen(_screen);
-   struct dri2_fence *fence;
-
-   if (!dri2_load_opencl_interop(driscreen))
-  

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Rob Herring]

On Mon, May 22, 2017 at 5:47 PM, Mike Lothian  wrote:
> I'm quite sure on Gentoo lib points to lib64 and we have a lib32

I'm talking about Android.

>
> On Mon, 22 May 2017 at 22:46 Rob Herring  wrote:
>>
>> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
>> wrote:
>> > On 20 May 2017 at 01:16, Rob Herring  wrote:
>> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov
>> >>  wrote:
>> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov
>>   wrote:
>> > On 18 May 2017 at 05:10, Chih-Wei Huang 
>> > wrote:
>> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>> >>>
>>  -Original Message-
>>  From: Palli, Tapani
>>  >
>>  > It's just applied. Isn't it?
>>  > Yesterday without this patch
>>  > the color format is mismatch apparently.
>> 
>>  Yeah we do need this. TBH I don't quite understand why but will
>>  try to figure
>>  it out. I remember we used to have a patch in Surfaceflinger at
>>  one point
>>  because visual was hardcoded there and this might be related.
>> 
>>  // Tapani
>> >>>
>> >>> Sorry, that's for different issue, I mix it with RGB565 blending
>> >>> one.
>> >>> This patch is required because some Android GLES test apps, like
>> >>> gl2_basic, need to create RGBA surface.
>> >>
>> >> Indeed it is.
>> >>
>> >> As Emil pointed out, the patch was merged before
>> >> but reverted later since it broke desktop.
>> >>
>> >> So what's the current upstreaming plan?
>> >>
>> > No idea about a plan, but how you can fix it once and for all:
>> >
>> > Extend the loader extension(s) to have a get_caps() callback,
>> > analogous to __DRIimageExtension::getCapabilities.
>> > Then the DRI module will query [the loader] and advertise the
>> > RGBX/RGBA visuals when possible.
>> 
>>  Could we do something compile time instead to enable just for
>>  Android?
>>  Seems like a lot of complexity when the platform needing these pixel
>>  formats doesn't need the backwards compatibility. Or maybe there are
>>  other things needing this interface?
>> 
>> >>> Having a short/mid term ifdef ANDROID is perfectly fine.
>> >>>
>> >>> Can we address some of the existing ones before/alongside the newly
>> >>> added ones?
>> >>> Afacit the nouveau bits are no longer applicable.
>> >>
>> >> Yeah. I don't explicitly warn for KK or less, but will add that and fix
>> >> these.
>> >>
>> >>> While for the
>> >>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
>> >>> rework or MESA_LOADER_DRIVER_OVERRIDE.
>> >>
>> >> How does the build rework help? My only reservation with using an env
>> >> var is generally Android things don't rely on them and it would break
>> >> working systems. I'm not even completely certain I can set env vars
>> >> globally. It would be nice if the build system could set defaults for
>> >> env vars we could use.
>> >>
>> > IIRC with the rework you have the dri driver names are known as we
>> > reach targets/dri/Android.mk
>>
>> Not really because we have things like freedreno -> msm and virgl ->
>> virtio_gpu, but having a variable like TARGET_DRIVERS is simple
>> enough.
>>
>> > Thus one can reuse them to create the separate drivers
>> >   - be that one blob + {sym,hard}links as we do in autotools/scons, or
>> >  - completely separate drivers like i965 and other classic drivers.
>>
>> Got it. Symlinks are really easy in master:
>>
>> LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS),
>> $(d)_dri.so)
>>
>> However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
>> but it doesn't support multilib, so we need something like this:
>>
>> LOCAL_POST_INSTALL_CMD := \
>> $(foreach l, lib lib64, \
>>  mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH);
>> \
>>  $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
>> $(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
>> )
>>
>> This will install broken links when we're not on a multilib build. A
>> bit ugly, but should be harmless.
>>
>> Rob
>> ___
>> 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] Revert "gallium: remove unused PIPE_CC_GCC_VERSION"

[Timothy Arceri]

Hi Brain,

It's been 7 months since this landed. Why not just send this out with 
those patches when you are ready to upsteam?


On 23/05/17 02:31, Brian Paul wrote:

This reverts commit e60928f4c4bd4484821d83f2b16a910ea9f5f9d9.

PIPE_CC_GCC_VERSION is used by some of our in-house code which hasn't
been upstreamed yet.
---
  src/gallium/include/pipe/p_config.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/include/pipe/p_config.h 
b/src/gallium/include/pipe/p_config.h
index 98c433f..3fa43ed 100644
--- a/src/gallium/include/pipe/p_config.h
+++ b/src/gallium/include/pipe/p_config.h
@@ -53,6 +53,7 @@
  
  #if defined(__GNUC__)

  #define PIPE_CC_GCC
+#define PIPE_CC_GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)
  #endif
  
  /*



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

Re: [Mesa-dev] [PATCH 01/10] mesa: split vertex_array_vertex_buffer() in two

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on radeonsi/RX580

Dieter

Am 22.05.2017 07:46, schrieb Timothy Arceri:

This will allow us to skip the error checkes when adding
KHR_no_error support.

Reviewed-by: Nicolai Hähnle 
---
 src/mesa/main/varray.c | 95 
--

 1 file changed, 53 insertions(+), 42 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 0eb8e62..f33f302 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1942,31 +1942,73 @@ _mesa_VertexAttribDivisor(GLuint index, GLuint 
divisor)

 * is equivalent to (assuming no errors are generated):
 *
 *   VertexAttribBinding(index, index);
 *   VertexBindingDivisor(index, divisor);"
 */
vertex_attrib_binding(ctx, vao, genericIndex, genericIndex);
vertex_binding_divisor(ctx, vao, genericIndex, divisor);
 }


-/**
- * GL_ARB_vertex_attrib_binding
- */
-static void
+static ALWAYS_INLINE void
 vertex_array_vertex_buffer(struct gl_context *ctx,
struct gl_vertex_array_object *vao,
GLuint bindingIndex, GLuint buffer, 
GLintptr offset,

GLsizei stride, const char *func)
 {
struct gl_buffer_object *vbo;
+   if (buffer ==
+   
vao->BufferBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj->Name) 
{
+  vbo = 
vao->BufferBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj;

+   } else if (buffer != 0) {
+  vbo = _mesa_lookup_bufferobj(ctx, buffer);
+
+  if (!vbo && _mesa_is_gles31(ctx)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, "%s(non-gen name)", 
func);

+ return;
+  }
+  /* From the GL_ARB_vertex_attrib_array spec:
+   *
+   *   "[Core profile only:]
+   *An INVALID_OPERATION error is generated if buffer is not 
zero or a
+   *name returned from a previous call to GenBuffers, or if 
such a name

+   *has since been deleted with DeleteBuffers.
+   *
+   * Otherwise, we fall back to the same compat profile behavior 
as other

+   * object references (automatically gen it).
+   */
+  if (!_mesa_handle_bind_buffer_gen(ctx, buffer, , func))
+ return;
+   } else {
+  /* The ARB_vertex_attrib_binding spec says:
+   *
+   *"If  is zero, any buffer object attached to this
+   * bindpoint is detached."
+   */
+  vbo = ctx->Shared->NullBufferObj;
+   }
+
+   _mesa_bind_vertex_buffer(ctx, vao, 
VERT_ATTRIB_GENERIC(bindingIndex),

+vbo, offset, stride);
+}
+

+/**
+ * GL_ARB_vertex_attrib_binding
+ */
+static void
+vertex_array_vertex_buffer_err(struct gl_context *ctx,
+   struct gl_vertex_array_object *vao,
+   GLuint bindingIndex, GLuint buffer,
+   GLintptr offset, GLsizei stride,
+   const char *func)
+{
ASSERT_OUTSIDE_BEGIN_END(ctx);

/* The ARB_vertex_attrib_binding spec says:
 *
 *"An INVALID_VALUE error is generated if  is 
greater than

 * the value of MAX_VERTEX_ATTRIB_BINDINGS."
 */
if (bindingIndex >= ctx->Const.MaxVertexAttribBindings) {
   _mesa_error(ctx, GL_INVALID_VALUE,
   "%s(bindingindex=%u > "
@@ -1993,53 +2035,22 @@ vertex_array_vertex_buffer(struct gl_context 
*ctx,

   return;
}

if (((ctx->API == API_OPENGL_CORE && 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;
}

-   if (buffer ==
-   
vao->BufferBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj->Name) 
{
-  vbo = 
vao->BufferBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj;

-   } else if (buffer != 0) {
-  vbo = _mesa_lookup_bufferobj(ctx, buffer);
-
-  if (!vbo && _mesa_is_gles31(ctx)) {
- _mesa_error(ctx, GL_INVALID_OPERATION, "%s(non-gen name)", 
func);

- return;
-  }
-  /* From the GL_ARB_vertex_attrib_array spec:
-   *
-   *   "[Core profile only:]
-   *An INVALID_OPERATION error is generated if buffer is not 
zero or a
-   *name returned from a previous call to GenBuffers, or if 
such a name

-   *has since been deleted with DeleteBuffers.
-   *
-   * Otherwise, we fall back to the same compat profile behavior 
as other

-   * object references (automatically gen it).
-   */
-  if (!_mesa_handle_bind_buffer_gen(ctx, buffer, , func))
- return;
-   } else {
-  /* The ARB_vertex_attrib_binding spec says:
-   *
-   *"If  is zero, any buffer object attached to this
-   * bindpoint is detached."
-   */
-  vbo = ctx->Shared->NullBufferObj;
-   }
-
-   

Re: [Mesa-dev] [PATCH] mesa: add APPLE_vertex_array_object stubs

[Timothy Arceri]

On 23/05/17 03:26, Ian Romanick wrote:

WTF?  I gave review feedback on IRC, and you said you were going to send
a different patch... yet this patch landed.  If you're not going to take
review feedback, why do you ask for it
idr> tarceri: You should be able to just put the functions back in the 
XML and 'exec="skip"' to the functions.
 tarceri: That will let libGL have entry points, but the drivers 
don't need to know anything about them.
idr> The real test is to see if a *_dri.so built before your original 
patch loads on a libGL built with later patches.


As I mentioned in the other thread I took your advice and tested an old 
branch but could not get it to fail. Given that I couldn't reproduce the 
failure, and you seem to be very busy (which sometimes results in Mesa 
inquiries to you going missing) I decided to push this version before I 
forgot about the problem.


Maybe I should have just sent the other patch and waited on feedback but 
it honestly didn't seem like a big deal.




On 05/18/2017 07:50 PM, Timothy Arceri wrote:

APPLE_vertex_array_object support was removed in 7927d0378fc7.
However it turns out we can't remove the functions because this
can cause issues when libglapi is used together with DRI1 drivers
which were branched off from master a few years ago.
---
  src/mapi/glapi/gen/APPLE_vertex_array_object.xml | 27 
  src/mapi/glapi/gen/Makefile.am   |  1 +
  src/mapi/glapi/gen/gl_API.xml|  2 +-
  src/mapi/glapi/tests/check_table.cpp |  2 ++
  src/mesa/main/arrayobj.c | 16 ++
  src/mesa/main/arrayobj.h |  4 
  src/mesa/main/tests/dispatch_sanity.cpp  |  2 ++
  7 files changed, 53 insertions(+), 1 deletion(-)
  create mode 100644 src/mapi/glapi/gen/APPLE_vertex_array_object.xml

diff --git a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml 
b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
new file mode 100644
index 000..7312f9b
--- /dev/null
+++ b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
@@ -0,0 +1,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+   
+
+
+
+
+   
+
+
+
+
+   
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index ecd1c71..33139bd 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -182,20 +182,21 @@ API_XML = \
ARB_texture_view.xml \
ARB_uniform_buffer_object.xml \
ARB_vertex_array_object.xml \
ARB_vertex_attrib_64bit.xml \
ARB_vertex_attrib_binding.xml \
ARB_viewport_array.xml \
AMD_draw_buffers_blend.xml \
AMD_performance_monitor.xml \
ARB_vertex_type_2_10_10_10_rev.xml \
APPLE_object_purgeable.xml \
+   APPLE_vertex_array_object.xml \
EXT_draw_buffers2.xml \
EXT_framebuffer_object.xml \
EXT_gpu_shader4.xml \
EXT_packed_depth_stencil.xml \
EXT_provoking_vertex.xml \
EXT_separate_shader_objects.xml \
EXT_texture_array.xml \
EXT_texture_integer.xml \
EXT_transform_feedback.xml \
EXT_window_rectangles.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 762fb5a..630d6b8 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -12524,21 +12524,21 @@
  
  
  
  

  
  
  
  
  
  http://www.w3.org/2001/XInclude"/>

-
+http://www.w3.org/2001/XInclude"/>
  
  

  
  
  
  
  
  

  
  
diff --git a/src/mapi/glapi/tests/check_table.cpp 
b/src/mapi/glapi/tests/check_table.cpp
index a1041bce..09bf4f3 100644
--- a/src/mapi/glapi/tests/check_table.cpp
+++ b/src/mapi/glapi/tests/check_table.cpp
@@ -1397,21 +1397,23 @@ const struct name_offset known_dispatch[] = {
 { "glColorFragmentOp3ATI", _O(ColorFragmentOp3ATI) },
 { "glDeleteFragmentShaderATI", _O(DeleteFragmentShaderATI) },
 { "glEndFragmentShaderATI", _O(EndFragmentShaderATI) },
 { "glGenFragmentShadersATI", _O(GenFragmentShadersATI) },
 { "glPassTexCoordATI", _O(PassTexCoordATI) },
 { "glSampleMapATI", _O(SampleMapATI) },
 { "glSetFragmentShaderConstantATI", _O(SetFragmentShaderConstantATI) },
 { "glPointParameteri", _O(PointParameteri) },
 { "glPointParameteriv", _O(PointParameteriv) },
 { "glActiveStencilFaceEXT", _O(ActiveStencilFaceEXT) },
+   { "glBindVertexArrayAPPLE", _O(BindVertexArrayAPPLE) },
 { "glDeleteVertexArrays", _O(DeleteVertexArrays) },
+   { "glGenVertexArraysAPPLE", _O(GenVertexArraysAPPLE) },
 { "glIsVertexArray", _O(IsVertexArray) },
 { "glGetProgramNamedParameterdvNV", _O(GetProgramNamedParameterdvNV) },
 { "glGetProgramNamedParameterfvNV", _O(GetProgramNamedParameterfvNV) },
 { "glProgramNamedParameter4dNV", _O(ProgramNamedParameter4dNV) },
 { "glProgramNamedParameter4dvNV", 

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Mike Lothian]

I'm quite sure on Gentoo lib points to lib64 and we have a lib32

On Mon, 22 May 2017 at 22:46 Rob Herring  wrote:

> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
> wrote:
> > On 20 May 2017 at 01:16, Rob Herring  wrote:
> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> > On 18 May 2017 at 05:10, Chih-Wei Huang 
> wrote:
> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>>
>  -Original Message-
>  From: Palli, Tapani
>  >
>  > It's just applied. Isn't it?
>  > Yesterday without this patch
>  > the color format is mismatch apparently.
> 
>  Yeah we do need this. TBH I don't quite understand why but will
> try to figure
>  it out. I remember we used to have a patch in Surfaceflinger at
> one point
>  because visual was hardcoded there and this might be related.
> 
>  // Tapani
> >>>
> >>> Sorry, that's for different issue, I mix it with RGB565 blending
> one.
> >>> This patch is required because some Android GLES test apps, like
> gl2_basic, need to create RGBA surface.
> >>
> >> Indeed it is.
> >>
> >> As Emil pointed out, the patch was merged before
> >> but reverted later since it broke desktop.
> >>
> >> So what's the current upstreaming plan?
> >>
> > No idea about a plan, but how you can fix it once and for all:
> >
> > Extend the loader extension(s) to have a get_caps() callback,
> > analogous to __DRIimageExtension::getCapabilities.
> > Then the DRI module will query [the loader] and advertise the
> > RGBX/RGBA visuals when possible.
> 
>  Could we do something compile time instead to enable just for Android?
>  Seems like a lot of complexity when the platform needing these pixel
>  formats doesn't need the backwards compatibility. Or maybe there are
>  other things needing this interface?
> 
> >>> Having a short/mid term ifdef ANDROID is perfectly fine.
> >>>
> >>> Can we address some of the existing ones before/alongside the newly
> added ones?
> >>> Afacit the nouveau bits are no longer applicable.
> >>
> >> Yeah. I don't explicitly warn for KK or less, but will add that and fix
> these.
> >>
> >>> While for the
> >>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
> >>> rework or MESA_LOADER_DRIVER_OVERRIDE.
> >>
> >> How does the build rework help? My only reservation with using an env
> >> var is generally Android things don't rely on them and it would break
> >> working systems. I'm not even completely certain I can set env vars
> >> globally. It would be nice if the build system could set defaults for
> >> env vars we could use.
> >>
> > IIRC with the rework you have the dri driver names are known as we
> > reach targets/dri/Android.mk
>
> Not really because we have things like freedreno -> msm and virgl ->
> virtio_gpu, but having a variable like TARGET_DRIVERS is simple
> enough.
>
> > Thus one can reuse them to create the separate drivers
> >   - be that one blob + {sym,hard}links as we do in autotools/scons, or
> >  - completely separate drivers like i965 and other classic drivers.
>
> Got it. Symlinks are really easy in master:
>
> LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS),
> $(d)_dri.so)
>
> However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
> but it doesn't support multilib, so we need something like this:
>
> LOCAL_POST_INSTALL_CMD := \
> $(foreach l, lib lib64, \
>  mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH);
> \
>  $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
> $(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
> )
>
> This will install broken links when we're not on a multilib build. A
> bit ugly, but should be harmless.
>
> Rob
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/65] ARB_bindless_texture for RadeonSI

[Dieter Nützel]

Hello Samuel,

running this on radeonsi/RX580.
Didn't saw better numbers for Wine/TS2017 (TrainSimulator 2017) ever 
before.
But didn't feaguered if it (can) use bindless (with Wine/stagging). Do 
we have a knob to toggle bindless on and off?
A key from Feral for DiRT Rally or the like would be very nice (my son 
would go crazy). - He (nine years old) love (car) simulators. ~50 € is 
much for 'testing'...


So got my

Tested-by: Dieter Nützel 

Here come some output from 'ogl-samples'

/opt/ogl-samples> ./build/release/gl-420-primitive-bindless-nv
ATTENTION: default value of option mesa_glthread overridden by 
environment.

OpenGL Version Needed 4.2 ( 4.5 Found )
Failed to find Extension: "GL_NV_shader_buffer_load"
Running Test
Test Ended
/opt/ogl-samples> ./build/release/gl-420-texture-bindless-nv
ATTENTION: default value of option mesa_glthread overridden by 
environment.

OpenGL Version Needed 4.2 ( 4.5 Found )
Failed to find Extension: "GL_NV_bindless_texture"
Running Test
Test Ended

GL_ARB_bindless_texture 'faking' needed?

Dieter

Am 19.05.2017 18:52, schrieb Samuel Pitoiset:

Hi,

This series implements ARB_bindless_texture for RadeonSI.

Reminder: the GLSL compiler part is already upstream.

This series has been mainly tested with Feral games, here's the list of
existing games that use ARB_bindless_texture (though not by default):

- DXMD
- Hitman
- Dirt Rally
- Mad Max

Today, Feral announced "Warhammer 40,000: Dawn of War III" (called 
DOW3) which
is going to be released next month. This game *requires* 
ARB_bindless_texture,
that now explains why I did all this work. :-) So, we have ~3 weeks for 
merging
this whole series. It would be very nice to have DOW3 support at day 
one!

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

Re: [Mesa-dev] driconf: Add allow_glsl_builtin_variable_redeclaration option

[Dieter Nützel]

Am 22.05.2017 23:56, schrieb Samuel Pitoiset:

On 05/22/2017 11:49 PM, Dieter Nützel wrote:

Hello John, hello Samuel,

is 'allow_glsl_builtin_redeclaration=true' needed after this (commit
#bf4d7671f423f5d4e451fba81bb9d9ae57f5fe5b) landed?


Hi,

Yes, because the option is only enabled with
2b878cb8fdb99dd84602553c2e95ef47747f4529.


Ohhh Samuel,...8-)))

_I_ should ask _better_ questions! --- I'm truly meant afer _all_ three 
commmits... --- git master.


No new 'answer' needed for this;-)

Cheers (with German 'Feierabend' beer)!

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

Re: [Mesa-dev] [PATCH] u_format_test: Ignore S3TC errors.

[Eric Anholt]

Jose Fonseca  writes:

> This prevents spurious failures when libtxc-dxtn-s2tc is installed.
>
> Note: lp_test_format does need any change since we were already ignoring
> S3TC failures there.

Tested-by: Eric Anholt 


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

Re: [Mesa-dev] [PATCH] st/dri: Add fence extension to SW path

[Chad Versace]

When you resubmit the patch again, please add (v3) to the subject.

On Mon 08 May 2017, Gurchetan Singh wrote:
> Use the same fence implementation for drisw.c as dri2.c by making
> dri2FenceExtension an external variable. Since the fence implementation
> is not dri2.c specific, put it in a separate file. This is desirable for
> synchronization in virtual machines.
> 
> v2: Don't depend on dri2.c for extensions (Emil)
> ---
>  src/gallium/state_trackers/dri/Makefile.sources |   2 +
>  src/gallium/state_trackers/dri/dri2.c   | 203 +
>  src/gallium/state_trackers/dri/dri_extensions.c | 229 
> 
>  src/gallium/state_trackers/dri/dri_extensions.h |  30 
>  src/gallium/state_trackers/dri/drisw.c  |   2 +
>  5 files changed, 264 insertions(+), 202 deletions(-)
>  create mode 100644 src/gallium/state_trackers/dri/dri_extensions.c
>  create mode 100644 src/gallium/state_trackers/dri/dri_extensions.h


Usually, to make review easier, and to make the git log easier to
understand, it's better to break patches like this into two: patch
1 moves the code, and patch 2 makes the actual changes.

> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index ed6004f836..2d95e668f8 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c


> -static bool
> -dri2_is_opencl_interop_loaded_locked(struct dri_screen *screen)
> -{
> -   return screen->opencl_dri_event_add_ref &&
> -  screen->opencl_dri_event_release &&
> -  screen->opencl_dri_event_wait &&
> -  screen->opencl_dri_event_get_fence;
> -}
> -
> -static bool
> -dri2_load_opencl_interop(struct dri_screen *screen)
> -{
> -#if defined(RTLD_DEFAULT)
> -   bool success;

There's a bug here.  Pre-patch, RTLD_DEFAULT is defined here and this
code gets built.  I verified this with #error. Post-patch, in the
equivalent code in the new file, RTLD_DEFAULT is undefined, and this
code never gets built.

> -
> -   mtx_lock(>opencl_func_mutex);
> -
> -   if (dri2_is_opencl_interop_loaded_locked(screen)) {
> -  mtx_unlock(>opencl_func_mutex);
> -  return true;
> -   }
> -
> -   screen->opencl_dri_event_add_ref =
> -  dlsym(RTLD_DEFAULT, "opencl_dri_event_add_ref");
> -   screen->opencl_dri_event_release =
> -  dlsym(RTLD_DEFAULT, "opencl_dri_event_release");
> -   screen->opencl_dri_event_wait =
> -  dlsym(RTLD_DEFAULT, "opencl_dri_event_wait");
> -   screen->opencl_dri_event_get_fence =
> -  dlsym(RTLD_DEFAULT, "opencl_dri_event_get_fence");
> -
> -   success = dri2_is_opencl_interop_loaded_locked(screen);
> -   mtx_unlock(>opencl_func_mutex);
> -   return success;
> -#else
> -   return false;
> -#endif
> -}


> diff --git a/src/gallium/state_trackers/dri/dri_extensions.c 
> b/src/gallium/state_trackers/dri/dri_extensions.c
> new file mode 100644
> index 00..2fa7233aab
> --- /dev/null
> +++ b/src/gallium/state_trackers/dri/dri_extensions.c


> +static bool
> +dri2_is_opencl_interop_loaded_locked(struct dri_screen *screen)
> +{
> +   return screen->opencl_dri_event_add_ref &&
> +  screen->opencl_dri_event_release &&
> +  screen->opencl_dri_event_wait &&
> +  screen->opencl_dri_event_get_fence;
> +}
> +
> +static bool
> +dri2_load_opencl_interop(struct dri_screen *screen)
> +{
> +#if defined(RTLD_DEFAULT)
> +   bool success;
> +
> +   pipe_mutex_lock(screen->opencl_func_mutex);

pipe_mutex_lock/unlock need to be replaced with mtx_lock/unlock, because
the pipe_mutex wrappers no longer exist. See this commit.

commit e000b17f87bd960c4ce1c0892017023d4dc59609
Author: Brian Paul 
Date:   Wed Apr 5 15:15:27 2017 -0600

winsys/svga: use c11 thread types/functions

Gallium no longer has wrappers for mutexes and conditi

> +
> +   if (dri2_is_opencl_interop_loaded_locked(screen)) {
> +  pipe_mutex_unlock(screen->opencl_func_mutex);
> +  return true;
> +   }
> +
> +   screen->opencl_dri_event_add_ref =
> +  dlsym(RTLD_DEFAULT, "opencl_dri_event_add_ref");
> +   screen->opencl_dri_event_release =
> +  dlsym(RTLD_DEFAULT, "opencl_dri_event_release");
> +   screen->opencl_dri_event_wait =
> +  dlsym(RTLD_DEFAULT, "opencl_dri_event_wait");
> +   screen->opencl_dri_event_get_fence =
> +  dlsym(RTLD_DEFAULT, "opencl_dri_event_get_fence");
> +
> +   success = dri2_is_opencl_interop_loaded_locked(screen);
> +   pipe_mutex_unlock(screen->opencl_func_mutex);
> +   return success;
> +#else
> +   return false;
> +#endif
> +}

Those are the only issues I found. But, I don't know this code well, so
you should probably seek the review of someone who touched it recently,
like Rob Herring, Rob Clark, or Tim Arceri.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Timothy Arceri]

On 23/05/17 05:02, Marek Olšák wrote:

On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle  wrote:

Hi all,

I've been looking into ARB_gl_spirv for radeonsi. I don't fancy re-inventing
the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into re-using
that.

It's not entirely straightforward because radeonsi and radv use different
"ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
SGPR allocations, descriptor loads work differently (obviously), and so on.

Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
translation. So here goes...


The Step-by-Step Plan
=

1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for very
simple VS-PS pipelines.

2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
pipelines.

3. Fill in all the rest:
3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
3b. Geometry and tessellation shaders
3c. Compute shaders
3d. Tests

I've started with step 1 and got basic GLSL 1.30-level vertex shaders
working via NIR. The code is here:
https://cgit.freedesktop.org/~nh/mesa/log/?h=nir

The basic approach is to introduce `struct ac_shader_abi' to capture the
differences between radeonsi and radv. In the end, the entry point for NIR
-> LLVM translation will simply be:

void ac_nir_translate(struct ac_llvm_context *ac,
  struct ac_shader_abi *abi,
  struct nir_shader *nir);

Setting up the LLVM function with its parameters is still considered part of
the driver.


This sounds good.




Questions
=

1. How do we get good test coverage?

A natural candidate would be to add a SPIR-V execution mode for the piglit
shader_runner. That is, use build scripts to extract shaders from
shader_test files and feed them through glslang to get spv files, and then
load those from shader_runner if a `-spirv' flag is passed on the command
line.

This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
linking semantics, and I'm pretty sure the majority of shader_test files
don't support that -- if only because they don't set a location on the
fragment shader color output.

Some ideas:
1. Add a GL_MESA_spirv_link_by_name extension
2. Have glslang add the locations for us (probably difficult because glslang
seems to be focused on one shader stage at a time.)
3. Hack something together in the shader_test-to-spv build scripts via
regular expressions (and now we have two problems? :-) )
4. Other ideas?


We have plenty of GLSL SSO shader tests in shader-db, but we can only
compile-test them.

Initially I think we can convert a few shader tests to SSO manually
and use those.




2. What's the Gallium interface?

Specifically, does it pass SPIR-V or NIR?

I'm leaning towards NIR, because then specialization, mapping of uniform
locations, atomics, etc. can be done entirely in st/mesa.

On the other hand, Pierre Moreau's work passes SPIR-V directly. On the third
hand, it wouldn't be the first time that clover does things differently.


If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
LLVM, you wouldn't need the serialization capability in NIR. You can
just use SPIR-V as the shader binary and the major NIR disadvantage is
gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
shader cache will continue working as-is.

However, I don't know how much GL awareness is required for doing
SPIR-V -> NIR in radeonsi. Additional GL-specific information might
have to be added to SPIR-V by st/mesa for the conversion to be doable.
You probably know better.

st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
know how feasible that is, but it seems to be the only thing needed in
shared code.

That also answers the NIR vs TGSI debate for the shader cache. The
answer is: Neither.



Just to list some downsides to this approach, not switching the the GLSL 
path to also use NIR has the following negatives:


1. We don't get to leverage the large GL test suits and app ecosystem 
for testing the NIR -> LLVM pass both during development and afterwards.


2. Jason has already said it best so to quote his reply:
"There have been a variety of different discussions over the last few 
years about compiler design choices but we've lacked the ability to get 
any good apples-to-apples comparisons.  This may provide some 
opportunities to do so."


3. The GLSL IR opts are both slow and not always optimal (possibly 
transforming the code to something that's harder to opt later), but due 
to uniform/varying optimisation requirements some optimisations are 
required *before* we can do validation. With NIR we have an opportunity 
to do these optimisations in NIR either by building a nir based linker 

Re: [Mesa-dev] driconf: Add allow_glsl_builtin_variable_redeclaration option

[Samuel Pitoiset]

On 05/22/2017 11:49 PM, Dieter Nützel wrote:

Hello John, hello Samuel,

is 'allow_glsl_builtin_redeclaration=true' needed after this (commit
#bf4d7671f423f5d4e451fba81bb9d9ae57f5fe5b) landed?


Hi,

Yes, because the option is only enabled with 
2b878cb8fdb99dd84602553c2e95ef47747f4529.




Thanks,
Dieter

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

Re: [Mesa-dev] driconf: Add allow_glsl_builtin_variable_redeclaration option

[Dieter Nützel]

Hello John, hello Samuel,

is 'allow_glsl_builtin_redeclaration=true' needed after this (commit
#bf4d7671f423f5d4e451fba81bb9d9ae57f5fe5b) landed?

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Rob Herring]

On Mon, May 22, 2017 at 9:16 AM, Emil Velikov  wrote:
> On 20 May 2017 at 01:16, Rob Herring  wrote:
>> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov  
>> wrote:
>>> On 18 May 2017 at 23:01, Rob Herring  wrote:
 On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
 wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
>> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>>
 -Original Message-
 From: Palli, Tapani
 >
 > It's just applied. Isn't it?
 > Yesterday without this patch
 > the color format is mismatch apparently.

 Yeah we do need this. TBH I don't quite understand why but will try to 
 figure
 it out. I remember we used to have a patch in Surfaceflinger at one 
 point
 because visual was hardcoded there and this might be related.

 // Tapani
>>>
>>> Sorry, that's for different issue, I mix it with RGB565 blending one.
>>> This patch is required because some Android GLES test apps, like 
>>> gl2_basic, need to create RGBA surface.
>>
>> Indeed it is.
>>
>> As Emil pointed out, the patch was merged before
>> but reverted later since it broke desktop.
>>
>> So what's the current upstreaming plan?
>>
> No idea about a plan, but how you can fix it once and for all:
>
> Extend the loader extension(s) to have a get_caps() callback,
> analogous to __DRIimageExtension::getCapabilities.
> Then the DRI module will query [the loader] and advertise the
> RGBX/RGBA visuals when possible.

 Could we do something compile time instead to enable just for Android?
 Seems like a lot of complexity when the platform needing these pixel
 formats doesn't need the backwards compatibility. Or maybe there are
 other things needing this interface?

>>> Having a short/mid term ifdef ANDROID is perfectly fine.
>>>
>>> Can we address some of the existing ones before/alongside the newly added 
>>> ones?
>>> Afacit the nouveau bits are no longer applicable.
>>
>> Yeah. I don't explicitly warn for KK or less, but will add that and fix 
>> these.
>>
>>> While for the
>>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
>>> rework or MESA_LOADER_DRIVER_OVERRIDE.
>>
>> How does the build rework help? My only reservation with using an env
>> var is generally Android things don't rely on them and it would break
>> working systems. I'm not even completely certain I can set env vars
>> globally. It would be nice if the build system could set defaults for
>> env vars we could use.
>>
> IIRC with the rework you have the dri driver names are known as we
> reach targets/dri/Android.mk

Not really because we have things like freedreno -> msm and virgl ->
virtio_gpu, but having a variable like TARGET_DRIVERS is simple
enough.

> Thus one can reuse them to create the separate drivers
>   - be that one blob + {sym,hard}links as we do in autotools/scons, or
>  - completely separate drivers like i965 and other classic drivers.

Got it. Symlinks are really easy in master:

LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS), $(d)_dri.so)

However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
but it doesn't support multilib, so we need something like this:

LOCAL_POST_INSTALL_CMD := \
$(foreach l, lib lib64, \
 mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH); \
 $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
$(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
)

This will install broken links when we're not on a multilib build. A
bit ugly, but should be harmless.

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

Re: [Mesa-dev] [PATCH] st/nine: Fix a regression and syntax cleanup

[Dieter Nützel]

FW: Got it a shot with radeonsi/RX580 under Wine-2.8-staging.
Tried it with LS2015, LS2017, TS2017 and PES2015.

Tested-by: Dieter Nützel 

Dieter

Am 22.05.2017 00:22, schrieb Axel Davy:

A few cleanups and in particular initializing properly
the new pipe_draw_info fields.
This should fix the regression caused by
330d0607ed60fd3edca192e54b4246310f06652f

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

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/device9.c  |  2 +-
 src/gallium/state_trackers/nine/indexbuffer9.c |  8 ++--
 src/gallium/state_trackers/nine/indexbuffer9.h |  5 ++---
 src/gallium/state_trackers/nine/nine_state.c   | 20 
+++-

 4 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c
b/src/gallium/state_trackers/nine/device9.c
index db33fdd580..37880405e9 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -2927,7 +2927,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct
NineDevice9 *This,
ibuf,
ibuf ?
NULL : (void*)pIndexData,

index_offset,

-  index_size);
+   
index_size);

 NineAfterDraw(This);

 pipe_vertex_buffer_unreference();
diff --git a/src/gallium/state_trackers/nine/indexbuffer9.c
b/src/gallium/state_trackers/nine/indexbuffer9.c
index d5f5492563..e73d29b5bd 100644
--- a/src/gallium/state_trackers/nine/indexbuffer9.c
+++ b/src/gallium/state_trackers/nine/indexbuffer9.c
@@ -49,9 +49,6 @@ NineIndexBuffer9_ctor( struct NineIndexBuffer9 *This,
 if (FAILED(hr))
 return hr;

-This->buffer = NULL;
-This->offset = 0;
-
 switch (pDesc->Format) {
 case D3DFMT_INDEX16: This->index_size = 2; break;
 case D3DFMT_INDEX32: This->index_size = 4; break;
@@ -73,11 +70,10 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 
*This )

 }

 struct pipe_resource *
-NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This )
+NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This, unsigned 
*offset )

 {
 /* The resource may change */
-This->buffer = NineBuffer9_GetResource(>base, 
>offset);

-return This->buffer;
+return NineBuffer9_GetResource(>base, offset);
 }

 HRESULT NINE_WINAPI
diff --git a/src/gallium/state_trackers/nine/indexbuffer9.h
b/src/gallium/state_trackers/nine/indexbuffer9.h
index 0efad7f5f1..e688488da8 100644
--- a/src/gallium/state_trackers/nine/indexbuffer9.h
+++ b/src/gallium/state_trackers/nine/indexbuffer9.h
@@ -37,8 +37,6 @@ struct NineIndexBuffer9
 struct NineBuffer9 base;

 /* g3d stuff */
-struct pipe_resource *buffer;
-unsigned offset;
 unsigned index_size;

 D3DINDEXBUFFER_DESC desc;
@@ -65,7 +63,8 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 *This 
);

 /*** Nine private ***/

 struct pipe_resource *
-NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This );
+NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This,
+unsigned *offset );

 /*** Direct3D public ***/

diff --git a/src/gallium/state_trackers/nine/nine_state.c
b/src/gallium/state_trackers/nine/nine_state.c
index 0fc4c8315a..30935760ae 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -1575,12 +1575,11 @@ nine_context_set_indices(struct NineDevice9 
*device,

 {
 struct pipe_resource *res = NULL;
 UINT IndexSize = 0;
-UINT OffsetInBytes = 0;
+unsigned OffsetInBytes = 0;

 if (idxbuf) {
-res = NineIndexBuffer9_GetBuffer(idxbuf);
+res = NineIndexBuffer9_GetBuffer(idxbuf, );
 IndexSize = idxbuf->index_size;
-OffsetInBytes = idxbuf->offset;
 }

 nine_context_set_indices_apply(device, res, IndexSize, 
OffsetInBytes);

@@ -2540,6 +2539,7 @@ init_draw_info(struct pipe_draw_info *info,
 if (dev->context.stream_instancedata_mask & 
dev->context.stream_usage_mask)
 info->instance_count = MAX2(dev->context.stream_freq[0] & 
0x7F, 1);

 info->primitive_restart = FALSE;
+info->has_user_indices = FALSE;
 info->restart_index = 0;
 info->count_from_stream_output = NULL;
 info->indirect = NULL;
@@ -2561,17 +2561,18 @@ CSMT_ITEM_NO_WAIT(nine_context_draw_primitive,
 info.index_bias = 0;
 info.min_index = info.start;
 info.max_index = info.count - 1;
+info.index.resource = NULL;

 context->pipe->draw_vbo(context->pipe, );
 }

 CSMT_ITEM_NO_WAIT(nine_context_draw_indexed_primitive,
   ARG_VAL(D3DPRIMITIVETYPE, PrimitiveType),
-   ARG_VAL(INT, BaseVertexIndex),
-   ARG_VAL(UINT, MinVertexIndex),
-   

Re: [Mesa-dev] [PATCH] mesa: Remove GL_APPLE_vertex_array_object stubs

[Timothy Arceri]

On 23/05/17 05:26, Ian Romanick wrote:

From: Ian Romanick 

Mark the functions 'exec="skip"' in the XML instead.  libGL will still
have the functions, but the driver won't try to use them.  I verified
that this commit works with piglit's 'object-namespace-pollution glClear
vertex-array' on x64 with a driver built from mesa-12.0.3 tag.

In fairness, this test also works with a libGL built from 7927d03.  I
believe it continues to work because on non-Windows platforms we
generate some extra, dummy dispatch functions that can be used when a
driver requests a function unknown to libGL.  This was done to provide
some "forward" compatibility with drivers that need more functions.
This doesn't work on Windows because the Windows calling convention is
for the callee to clean up the stack.  That's the theory anyway.


Thanks. I also couldn't get the old drivers to fail which is why I just 
pushed the patch with the stubs. If this will work it looks good to me.


Reviewed-by: Timothy Arceri 




Signed-off-by: Ian Romanick 
---
  src/mapi/glapi/gen/APPLE_vertex_array_object.xml |  8 
  src/mesa/main/arrayobj.c | 16 
  src/mesa/main/arrayobj.h |  4 
  src/mesa/main/tests/dispatch_sanity.cpp  |  2 --
  4 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml 
b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
index 7312f9b..daf6990 100644
--- a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
+++ b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
@@ -5,21 +5,21 @@
  
  
  
-

+
  
  
  
-

+
  

  
  
-

+
  

  
  
-

+
  

  
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index b986229..82c00fb 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -473,14 +473,6 @@ _mesa_BindVertexArray( GLuint id )
  }
  
  
-void GLAPIENTRY

-_mesa_BindVertexArrayAPPLE(GLuint id)
-{
-   GET_CURRENT_CONTEXT(ctx);
-   _mesa_problem(ctx, "APPLE_vertex_array_object is not supported!");
-}
-
-
  /**
   * Delete a set of array objects.
   *
@@ -587,14 +579,6 @@ _mesa_GenVertexArrays(GLsizei n, GLuint *arrays)
  }
  
  
-void GLAPIENTRY

-_mesa_GenVertexArraysAPPLE(GLsizei n, GLuint *arrays)
-{
-   GET_CURRENT_CONTEXT(ctx);
-   _mesa_problem(ctx, "APPLE_vertex_array_object is not supported!");
-}
-
-
  /**
   * ARB_direct_state_access
   * Generates ID's and creates the array objects.
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 097027b..1794968 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -96,14 +96,10 @@ _mesa_all_buffers_are_unmapped(const struct 
gl_vertex_array_object *vao);
  
  void GLAPIENTRY _mesa_BindVertexArray( GLuint id );
  
-void GLAPIENTRY _mesa_BindVertexArrayAPPLE(GLuint id);

-
  void GLAPIENTRY _mesa_DeleteVertexArrays(GLsizei n, const GLuint *ids);
  
  void GLAPIENTRY _mesa_GenVertexArrays(GLsizei n, GLuint *arrays);
  
-void GLAPIENTRY _mesa_GenVertexArraysAPPLE(GLsizei n, GLuint *buffer);

-
  void GLAPIENTRY _mesa_CreateVertexArrays(GLsizei n, GLuint *arrays);
  
  GLboolean GLAPIENTRY _mesa_IsVertexArray( GLuint id );

diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index 12a9ee7..b33043e 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -969,8 +969,6 @@ const struct function common_desktop_functions_possible[] = 
{
  };
  
  const struct function gl_compatibility_functions_possible[] = {

-   { "glBindVertexArrayAPPLE", 10, -1 },
-   { "glGenVertexArraysAPPLE", 10, -1 },
 { "glBindRenderbufferEXT", 10, -1 },
 { "glBindFramebufferEXT", 10, -1 },
 { "glNewList", 10, _gloffset_NewList },


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

Re: [Mesa-dev] [PATCH 2/6] nir: Prehash in instr_set to avoid hashing twice

[Thomas Helland]

2017-05-22 20:55 GMT+02:00 Thomas Helland :
> This should prove benefitial in the common case of inserting
> and not rewriting anything.
>
> V2: Use hash_instr directly instead of going through the function
> pointer embedded in the set

Threw some sysprof profiles at this patch. This should theoretically
be the "big winner" in this patch series, plus the string_to_uint_map
patch. The rationale being that the slower the hashing, the more
this will benefit us.

Results from sysprof:

Before:
nir_opt_cse   3.68%
hash_instr (on search)  0.28%
hash_instr (on insert)   0.26%

After:
nir_opt_cse   3.31%
hash_instr 0.28%

So we see the 0.26% spent in hash_instr on insert going away,
as we should expect, but interestingly the cumulative time
spent in nir_opt_cse drops 0.37% of the total, down to 3.31%.

For fun I also fired up the quadratic probing hash set that
I still haven't gotten around to finalizing. That brings us down
even further, bringing us under 3% of total for nir_opt_cse.
Shout out if there's any more tests I should do.

> ---
>  src/compiler/nir/nir_instr_set.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_instr_set.c 
> b/src/compiler/nir/nir_instr_set.c
> index 9cb9ed43e8..bdc3b02173 100644
> --- a/src/compiler/nir/nir_instr_set.c
> +++ b/src/compiler/nir/nir_instr_set.c
> @@ -508,7 +508,10 @@ nir_instr_set_add_or_rewrite(struct set *instr_set, 
> nir_instr *instr)
> if (!instr_can_rewrite(instr))
>return false;
>
> -   struct set_entry *entry = _mesa_set_search(instr_set, instr);
> +   uint32_t hash = hash_instr(instr);
> +   struct set_entry *entry =
> +  _mesa_set_search_pre_hashed(instr_set, hash, instr);
> +
> if (entry) {
>nir_ssa_def *def = nir_instr_get_dest_ssa_def(instr);
>nir_instr *match = (nir_instr *) entry->key;
> @@ -526,7 +529,7 @@ nir_instr_set_add_or_rewrite(struct set *instr_set, 
> nir_instr *instr)
>return true;
> }
>
> -   _mesa_set_add(instr_set, instr);
> +   _mesa_set_add_pre_hashed(instr_set, hash, instr);
> return false;
>  }
>
> --
> 2.13.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Jason Ekstrand]

Taking the "just reply to Nicolai" approach like everyeone else...

Nicolai,

First off, thanks for working on this!  I've given it a bit of thought in
the context of i965, so I've got a few ideas about how you could overcome
some of the issues.

On Sun, May 21, 2017 at 3:48 AM, Nicolai Hähnle  wrote:

> Hi all,
>
> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy
> re-inventing the ~8k LOC of src/compiler/spirv, and there's already a
> perfectly fine SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked
> into re-using that.
>
> It's not entirely straightforward because radeonsi and radv use different
> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
> SGPR allocations, descriptor loads work differently (obviously), and so on.
>

We have this same problem with NIR coming into our back-end compiler from
Vulkan, BLORP, and GLSL where they all speak very slightly different
variants.  The approach we've taken for most of this is to add
front-end-specific lowering passes that turn it into a common "ABI" that is
consumed by our two back-ends.  You could also do some switching in NIR ->
LLVM and that should work fine for small things.  If you want to see what
we've done, look for any anv_nir_*.c or brw_nir_*.c in src/intel/vulkan or
src/mesa/drivers/dri/i965.


> Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
> translation. So here goes...
>
>
> The Step-by-Step Plan
> =
>
> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for
> very simple VS-PS pipelines.
>

This sounds like both a good step and something that I think would be neat
to see.  There have been a variety of different discussions over the last
few years about compiler design choices but we've lacked the ability to get
any good apples-to-apples comparisons.  This may provide some opportunities
to do so.


> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
> pipelines.
>
> 3. Fill in all the rest:
> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
> 3b. Geometry and tessellation shaders
> 3c. Compute shaders
> 3d. Tests
>

spirv_to_nir should handle almost everything here (with the possible
exception of stand-alone atomic counters).


> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
> working via NIR. The code is here: https://cgit.freedesktop.org/~
> nh/mesa/log/?h=nir
>
> The basic approach is to introduce `struct ac_shader_abi' to capture the
> differences between radeonsi and radv. In the end, the entry point for NIR
> -> LLVM translation will simply be:
>
>void ac_nir_translate(struct ac_llvm_context *ac,
>  struct ac_shader_abi *abi,
>  struct nir_shader *nir);
>
> Setting up the LLVM function with its parameters is still considered part
> of the driver.
>
>
> Questions
> =
>
> 1. How do we get good test coverage?
> 
> A natural candidate would be to add a SPIR-V execution mode for the piglit
> shader_runner. That is, use build scripts to extract shaders from
> shader_test files and feed them through glslang to get spv files, and then
> load those from shader_runner if a `-spirv' flag is passed on the command
> line.
>
> This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
> linking semantics, and I'm pretty sure the majority of shader_test files
> don't support that -- if only because they don't set a location on the
> fragment shader color output.
>
> Some ideas:
> 1. Add a GL_MESA_spirv_link_by_name extension
> 2. Have glslang add the locations for us (probably difficult because
> glslang seems to be focused on one shader stage at a time.)
> 3. Hack something together in the shader_test-to-spv build scripts via
> regular expressions (and now we have two problems? :-) )
> 4. Other ideas?
>

Another thing I've considered when thinking about doing this myself would
be to add a SPIR-V back-end to either NIR or GLSL IR.  Then you can hook it
up as GLSL -> SPIR-V -> NIR and run some tests.  If you did this
post-linking, then you could just use the locations assigned by the linker
and all of the tests should basically work.  I'm not sure about whether
doing NIR -> SPIR-V or GLSL -> SPIR-V would be better.  Being able to
serialize NIR has its uses but, if one wanted to make the stand-alone
compiler into a GLSLang competitor, I think going directly from GLSL IR
would be better.


> 2. What's the Gallium interface?
> 
> Specifically, does it pass SPIR-V or NIR?
>
> I'm leaning towards NIR, because then specialization, mapping of uniform
> locations, atomics, etc. can be done entirely in st/mesa.
>
> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the
> third hand, it wouldn't be the first time that clover does things
> differently.
>
>
> 3. NIR vs. TGSI
> ---
> It is *not* a goal for this 

Re: [Mesa-dev] [PATCH 1/3] etnaviv: Add support for extended texture formats

[Christian Gmeiner]

2017-05-22 19:51 GMT+02:00 Lucas Stach :
> Am Dienstag, den 16.05.2017, 21:31 +0200 schrieb Christian Gmeiner:
>> Hi Wladimir.
>>
>> I started working on this topic last week and thought some time on how
>> to add those ext texture formats in a clean and nice way. I come up
>> with this patches:
>>
>> https://github.com/austriancoder/mesa/commit/1fac9dd179976dce3d991bb0715707021c093f1a.patch
>> https://github.com/austriancoder/mesa/commit/f408fc40a028fa00e87900e6fd4cce65ee6640c2.patch
>>
>> IMO it is a simpler implementation as I do not need two variants of
>> macros (base and extended) and there is no need for
>> translate_texture_format_ext(..).
>> What is your opinion about it?
>
> This looks much cleaner. I like it!
>
> Just a heads up if you haven't noticed: the first patch is broken, as
> sv->base isn't initialized yet at the point where the format is
> converted. I had to apply the following diff to make it work:
>
> >8
> -   const uint32_t format = translate_texture_format(sv->base.format);
> +   const uint32_t format = translate_texture_format(so->format);
> 8<
>

Thx - will send out updated patches the next days. I quite busy with
lot of stuff atm but
a long weekend is coming :)

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] glsl: Prehash in refcount hash table to reduce hashing

[Thomas Helland]

2017-05-22 21:44 GMT+02:00 Thomas Helland :
> 2017-05-22 21:19 GMT+02:00 Ian Romanick :
>> On 05/22/2017 11:55 AM, Thomas Helland wrote:
>>> _mesa_hash_table_search is one of our hottest function according to perf.
>>> Callgrind shows the refcounting as one of the major users of the
>>> searching functions. We can reduce the pain by prehashing, so that we
>>> avoid hashing two times when inserting in the table.
>>>
>>> On a short shader-db run (with validation disabled) it makes
>>> 1.2 million of 4.5 million calls to _hash_table_insert come from
>>> the pre-hashed path.
>>
>> Did this have any measurable impact on the run time?
>>
>
> Not as I can tell. I believe it is mostly just accumulating a slight
> gain from each patch. However, coming to think of it, the big one
> here might actually be string_to_uint_map, as that one has to hash
> strings instead of just pointers. I guess the pointer hashing is now
> so fast that it doesn't really matter.
>
> However, this is all a bit hard to measure. I would probably have
> to instrument this, and run it on my desktop, maybe with
> GALLIUM_NOOP set, in order to get conclusive results. My poor
> old ivy-bridge ultrabook has seen better days and is giving me
> quite hard-to-conlude-on results. What I can tell for sure though,
> is that the number of executed instructions drops by about 0.1%
> for this patch only.
>
> I can do some tests on my desktop tomorrow, if you'd like that.
> Then I would probably be able to get more conclusive results.
>

Thinking about this some more, I believe this approach is really
only beneficial in nir's instr_set, and in hash tables with other
longer data as keys, like strings. With the speed of the new
pointer hashing function there is little to no gain. However,
sysprof reports that the hash_instr part of the set_insert
function in nir_opt_cse is a cumulative 0.25% of overall overhead.
So with the patch to the instr_set we should see a 0.25%
drop in nir_opt_cse's part of the total picture. I'll do some tests
and see if I can confirm this.

>>> ---
>>>  src/compiler/glsl/ir_variable_refcount.cpp | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/compiler/glsl/ir_variable_refcount.cpp 
>>> b/src/compiler/glsl/ir_variable_refcount.cpp
>>> index 8306be10b9..bbb4c0ddd7 100644
>>> --- a/src/compiler/glsl/ir_variable_refcount.cpp
>>> +++ b/src/compiler/glsl/ir_variable_refcount.cpp
>>> @@ -79,13 +79,16 @@ 
>>> ir_variable_refcount_visitor::get_variable_entry(ir_variable *var)
>>>  {
>>> assert(var);
>>>
>>> -   struct hash_entry *e = _mesa_hash_table_search(this->ht, var);
>>> +   uint32_t hash = this->ht->key_hash_function(var);
>>> +
>>> +   struct hash_entry *e =
>>> +  _mesa_hash_table_search_pre_hashed(this->ht, hash, var);
>>> if (e)
>>>return (ir_variable_refcount_entry *)e->data;
>>>
>>> ir_variable_refcount_entry *entry = new ir_variable_refcount_entry(var);
>>> assert(entry->referenced_count == 0);
>>> -   _mesa_hash_table_insert(this->ht, var, entry);
>>> +   _mesa_hash_table_insert_pre_hashed(this->ht, hash, var, entry);
>>>
>>> return entry;
>>>  }
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 02/65] mesa: implement ARB_bindless_texture

[Nicolai Hähnle]

On 19.05.2017 18:52, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
 src/mesa/main/context.c |   3 +
 src/mesa/main/dd.h  |  17 +
 src/mesa/main/mtypes.h  |  34 ++
 src/mesa/main/samplerobj.c  |   6 +
 src/mesa/main/shared.c  |  12 +
 src/mesa/main/texobj.c  |  12 +
 src/mesa/main/texturebindless.c | 827 +++-
 src/mesa/main/texturebindless.h |  28 ++
 8 files changed, 934 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 3570f94f5a..5321886a95 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -133,6 +133,7 @@
 #include "varray.h"
 #include "version.h"
 #include "viewport.h"
+#include "texturebindless.h"
 #include "program/program.h"
 #include "math/m_matrix.h"
 #include "main/dispatch.h" /* for _gloffset_COUNT */
@@ -855,6 +856,7 @@ init_attrib_groups(struct gl_context *ctx)
_mesa_init_transform_feedback( ctx );
_mesa_init_varray( ctx );
_mesa_init_viewport( ctx );
+   _mesa_init_resident_handles( ctx );

if (!_mesa_init_texture( ctx ))
   return GL_FALSE;
@@ -1339,6 +1341,7 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_free_transform_feedback(ctx);
_mesa_free_performance_monitors(ctx);
_mesa_free_performance_queries(ctx);
+   _mesa_free_resident_handles(ctx);

_mesa_reference_buffer_object(ctx, >Pack.BufferObj, NULL);
_mesa_reference_buffer_object(ctx, >Unpack.BufferObj, NULL);
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index a9ca43d69e..d830f5184d 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1050,6 +1050,23 @@ struct dd_function_table {
 GLintptr offset, GLsizeiptr size,
 GLboolean commit);
/*@}*/
+
+   /**
+* \name GL_ARB_bindless_texture interface
+*/
+   /*@{*/
+   GLuint64 (*NewTextureHandle)(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+struct gl_sampler_object *sampObj);
+   void (*DeleteTextureHandle)(struct gl_context *ctx, GLuint64 handle);
+   void (*MakeTextureHandleResident)(struct gl_context *ctx, GLuint64 handle,
+ bool resident);
+   GLuint64 (*NewImageHandle)(struct gl_context *ctx,
+  struct gl_image_unit *imgObj);
+   void (*DeleteImageHandle)(struct gl_context *ctx, GLuint64 handle);
+   void (*MakeImageHandleResident)(struct gl_context *ctx, GLuint64 handle,
+   GLenum access, bool resident);
+   /*@}*/
 };


diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index efc6920254..70865b373d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -987,6 +987,9 @@ struct gl_sampler_object
GLenum CompareFunc; /**< GL_ARB_shadow */
GLenum sRGBDecode;   /**< GL_DECODE_EXT or GL_SKIP_DECODE_EXT */
GLboolean CubeMapSeamless;   /**< GL_AMD_seamless_cubemap_per_texture */
+   bool HandleAllocated;/**< GL_ARB_bindless_texture */
+
+   struct hash_table *Handles;
 };


@@ -1034,6 +1037,8 @@ struct gl_texture_object
GLuint NumLevels;   /**< GL_ARB_texture_view */
GLuint NumLayers;   /**< GL_ARB_texture_view */

+   GLboolean HandleAllocated;  /**< GL_ARB_bindless_texture */
+
/** Actual texture images, indexed by [cube face] and [mipmap level] */
struct gl_texture_image *Image[MAX_FACES][MAX_TEXTURE_LEVELS];

@@ -1051,6 +1056,10 @@ struct gl_texture_object

/** GL_ARB_shader_image_load_store */
GLenum ImageFormatCompatibilityType;
+
+   /** GL_ARB_bindless_texture */
+   struct hash_table *SamplerHandles;
+   struct hash_table *ImageHandles;
 };


@@ -1390,6 +1399,7 @@ struct gl_buffer_object
GLboolean Written;   /**< Ever written to? (for debugging) */
GLboolean Purgeable; /**< Is the buffer purgeable under memory pressure? */
GLboolean Immutable; /**< GL_ARB_buffer_storage */
+   GLboolean HandleAllocated; /**< GL_ARB_bindless_texture */


Should be consistent with gl_sampler_object in terms of type (and 
gl_texture_object as well). Which type? Since the state is not 
API-visible, bool is justifiable.




gl_buffer_usage UsageHistory; /**< How has this buffer been used so far? */

/** Counters used for buffer usage warnings */
@@ -3203,6 +3213,11 @@ struct gl_shared_state
/** GL_ARB_sampler_objects */
struct _mesa_HashTable *SamplerObjects;

+   /* GL_ARB_bindless_texture */
+   struct hash_table *TextureHandles;
+   struct hash_table *ImageHandles;
+   mtx_t HandlesMutex; /**< For texture/image handles safety */
+
/**
 * Some context in this share group was affected by a GPU reset
 *
@@ -4488,6 +4503,17 @@ struct gl_subroutine_index_binding
GLuint *IndexPtr;
 };

+struct gl_texture_handle_object
+{
+   struct gl_texture_object *texObj;
+   

Re: [Mesa-dev] [PATCH 0/9] glsl: cleanup and fix handling of unnamed struct types

[Nicolai Hähnle]

Hey Ian,

Do you want more time to look into this? I double-checked that glslang 
accepts this code pattern.


Cheers,
Nicolai

On 16.05.2017 14:29, Nicolai Hähnle wrote:

On 16.05.2017 02:56, Ian Romanick wrote:

On 05/15/2017 02:27 AM, Nicolai Hähnle wrote:

Hi all,

This series aims to simplify how we handle unnamed struct types and
fix some
bugs on the way. Some of the patches should be uncontroversial, and
all of
them align with my understanding of the GLSL spec, but the spec isn't
exactly explicit, so...

At a high level, the series changes two things:

1) Unnamed structs can never match named structs during linking.

2) Unnamed structs are considered the same type if they have the same
content. They will literally use the same glsl_type instance.

The second point causes a deviation from the behavior of C/C++, in
that the
following code snippet now compiles (and does the reasonable thing):

  struct { float a; } s1;
  struct { float a; } s2;

  s2 = s1;


I'll have to do some archaeology, but I believe this is what we used to
do.  I believe that we changed it because we were required to do so.

Does this fix some app, or is it just to simplify the code?


It's just to simplify the code (or rather: to fix what I'd consider a
bug without making things *much* more complicated). Erik wrote in a
separate reply that he tested that code snippet on other
implementations, and they accept it. I didn't notice regressions in my
own testing yet.

Cheers,
Nicolai





The justification is basically that the GLSL spec says (when it comes to
linking, in Section 4.2) that

   "Structures must have the same name, sequence of type names, and
type definitions, and member names to be considered the same type."

And since people generally seem to read that as mandating that
globals of
unnamed struct types should match if they're structurally the same,
and the
GLSL spec otherwise says nothing (as far as I can tell) about when
struct
types are equal, the cleanest thing is to just say that _in general_
(not
just for linking) struct types are the same if and only if they have the
same name and the same fields; where "same name" can mean that they both
have no name.

Please contemplate and review! :)
Thanks,
Nicolai
--
 src/compiler/glsl/ast.h   |  1 +
 src/compiler/glsl/ast_to_hir.cpp  | 17 ++---
 src/compiler/glsl/glsl_parser_extras.cpp  | 17 +++--
 src/compiler/glsl/link_varyings.cpp   | 41 +++-
 src/compiler/glsl/linker.cpp  | 47 +-
 src/compiler/glsl/lower_ubo_reference.cpp |  2 +-
 src/compiler/glsl_types.cpp   | 69 +
 src/compiler/glsl_types.h | 11 ++--
 8 files changed, 80 insertions(+), 125 deletions(-)

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









--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 01/65] mapi: add GL_ARB_bindless_texture entry points

[Nicolai Hähnle]

On 19.05.2017 18:52, Samuel Pitoiset wrote:

Signed-off-by: Samuel Pitoiset 
---
 src/mapi/glapi/gen/ARB_bindless_texture.xml | 100 
 src/mapi/glapi/gen/Makefile.am  |   1 +
 src/mapi/glapi/gen/gl_API.xml   |   4 +-
 src/mapi/glapi/gen/gl_genexec.py|   1 +
 src/mesa/Makefile.sources   |   2 +
 src/mesa/main/api_loopback.c|  14 
 src/mesa/main/api_loopback.h|   6 ++
 src/mesa/main/dd.h  |   2 +
 src/mesa/main/tests/dispatch_sanity.cpp |  18 +
 src/mesa/main/texturebindless.c |  85 +++
 src/mesa/main/texturebindless.h |  68 +++
 src/mesa/main/uniforms.c|  24 +++
 src/mesa/main/uniforms.h|  12 
 src/mesa/main/varray.c  |   5 ++
 src/mesa/main/varray.h  |   3 +
 src/mesa/main/vtxfmt.c  |   4 ++
 src/mesa/vbo/vbo_attrib_tmp.h   |   9 +++
 src/mesa/vbo/vbo_exec_api.c |   3 +
 src/mesa/vbo/vbo_save_api.c |   3 +
 19 files changed, 363 insertions(+), 1 deletion(-)
 create mode 100644 src/mapi/glapi/gen/ARB_bindless_texture.xml
 create mode 100644 src/mesa/main/texturebindless.c
 create mode 100644 src/mesa/main/texturebindless.h

diff --git a/src/mapi/glapi/gen/ARB_bindless_texture.xml 
b/src/mapi/glapi/gen/ARB_bindless_texture.xml
new file mode 100644
index 00..bfad45651c
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_bindless_texture.xml
@@ -0,0 +1,100 @@
+
+
+
+
+
+
+
+   
+   
+
+   


What's the offset="assign"?

Cheers,
Nicolai



+  
+  
+   
+
+   
+  
+  
+  
+   
+
+   
+  
+   
+
+   
+  
+   
+
+   
+  
+  
+  
+  
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+  
+   
+
+   
+  
+  
+  
+   
+
+   
+  
+  
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+  
+   
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index ecd1c71175..80f9139e5d 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -119,6 +119,7 @@ API_XML = \
gl_and_glX_API.xml \
ARB_base_instance.xml \
ARB_blend_func_extended.xml \
+   ARB_bindless_texture.xml \
ARB_clear_buffer_object.xml \
ARB_clear_texture.xml \
ARB_clip_control.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 762fb5a676..278fe14bb6 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -8284,7 +8284,9 @@
 
 

-
+
+
+http://www.w3.org/2001/XInclude"/>

 http://www.w3.org/2001/XInclude"/>

diff --git a/src/mapi/glapi/gen/gl_genexec.py b/src/mapi/glapi/gen/gl_genexec.py
index 37b1cc6be0..57e155bd1f 100644
--- a/src/mapi/glapi/gen/gl_genexec.py
+++ b/src/mapi/glapi/gen/gl_genexec.py
@@ -113,6 +113,7 @@ header = """/**
 #include "main/texstate.h"
 #include "main/texstorage.h"
 #include "main/barrier.h"
+#include "main/texturebindless.h"
 #include "main/textureview.h"
 #include "main/transformfeedback.h"
 #include "main/mtypes.h"
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 8a65fbe663..b80882fb8d 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -240,6 +240,8 @@ MAIN_FILES = \
main/texstorage.h \
main/texstore.c \
main/texstore.h \
+   main/texturebindless.c \
+   main/texturebindless.h \
main/textureview.c \
main/textureview.h \
main/transformfeedback.c \
diff --git a/src/mesa/main/api_loopback.c b/src/mesa/main/api_loopback.c
index 59b59d3a9e..36e5194b93 100644
--- a/src/mesa/main/api_loopback.c
+++ b/src/mesa/main/api_loopback.c
@@ -1529,6 +1529,16 @@ _mesa_VertexAttribL1dv(GLuint index, const GLdouble *v)
 }

 void GLAPIENTRY
+_mesa_VertexAttribL1ui64ARB(GLuint index, GLuint64EXT x)
+{
+}
+
+void GLAPIENTRY
+_mesa_VertexAttribL1ui64vARB(GLuint index, const GLuint64EXT *v)
+{
+}
+
+void GLAPIENTRY
 _mesa_VertexAttribL2dv(GLuint index, const GLdouble *v)
 {
ATTRIB2_D(index, v[0], v[1]);
@@ -1789,5 +1799,9 @@ _mesa_loopback_init_api_table(const struct gl_context 
*ctx,
   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/api_loopback.h b/src/mesa/main/api_loopback.h
index 026bfd68e1..c1e7b24f09 100644
--- 

Re: [Mesa-dev] [PATCH 1/9] mesa: Handle common extension checks with more compact code

[Nanley Chery]

On Fri, May 19, 2017 at 04:29:16PM -0700, Ian Romanick wrote:
> On 05/19/2017 10:28 AM, Nanley Chery wrote:
> > On Fri, May 19, 2017 at 06:38:03AM -0700, Ian Romanick wrote:
> >> From: Ian Romanick 
> >>
> >> The previous code handled everything with the general case.  I noticed
> >> that every time I converted an open-coded check to use a
> >> _mesa_has_EXT_foo() function, the text size of the driver increased.
> >>
> >> Almost all extensions only care what the current context API is, and
> >> the version does not matter.  Handle those using more compact checks.
> >>
> >>text   data bss dec hex filename
> >> 7037675 235248   37280 7310203  6f8b7b 32-bit i965_dri.so before
> >> 7034307 235248   37280 7306835  6f7e53 32-bit i965_dri.so after
> >> 6679695 303400   50608 7033703  6b5367 64-bit i965_dri.so before
> >> 6676143 303400   50608 7030151  6b4587 64-bit i965_dri.so after
> > 
> > Hi Ian,
> > 
> > I wrote a patch some time ago that reduces the cost of the extension
> > checks by a lot more with less code. The only thing I think may need
> > addressing is endianness. Would you consider using it instead if I
> > reworked it and sent it out to the list? You can find it here:
> > https://cgit.freedesktop.org/~nchery/mesa/commit/?h=1/ext/optimize=a02d88eba1d3129b27d3b5e6aaa976c3ca20cf79
> 
> I was not able to reproduce that result on current Mesa.  I had a lot
> of trouble believing that more than 18% of our driver binary was
> extension check code.  I also had a sick feeling that may have just
> been the first stage of grief talking... :)  Are you able to reproduce
> your original result?
> 

I'm actually not able to reproduce my results anymore. Also, after
fixing endianness with more bit shifting, I was only able to save ~400B
of .text (using your build flags). I retract my earlier statement.

> I also tried a similar patch to yours that wouldn't have endianness
> problems:
> 
> #define EXT(name_str, driver_cap, gll, glc, es1, es2, ...)
>  \
> static inline bool
>  \
> _mesa_has_##name_str(const struct gl_context *ctx)
>  \
> { 
>  \
>static const uint8_t ver[4] = { (uint8_t)gll, (uint8_t)es1, (uint8_t)es2, 
> (uint8_t)glc }; \
>return ctx->Extensions.driver_cap &&   
>  \
>   (ctx->Extensions.Version >= ver[ctx->API]); 
>  \
> }
> 
> Here's what I got for all four methods:
> 
> 7037675235248   37280 7310203  6f8b7b 32-bit i965_dri.so before
> 7034307235248   37280 7306835  6f7e53 32-bit i965_dri.so after idr
> 7038343235248   37280 7310871  6f8e17 32-bit i965_dri.so after Nanley
> 7036271235248   37280 7308799  6f85ff 32-bit i965_dri.so w/arrays
> 
> 6679695303400   50608 7033703  6b5367 64-bit i965_dri.so before
> 6676143303400   50608 7030151  6b4587 64-bit i965_dri.so after idr
> 6684767303400   50608 7038775  6b6737 64-bit i965_dri.so after Nanley
> 6678567303400   50608 7032575  6b4eff 64-bit i965_dri.so w/arrays
> 
> For reference, I build with the same flags that Fedora 23 (I think?)
> used for release builds:
> 
> -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
> --param=ssp-buffer-size=4 -grecord-gcc-switches
> 
> And either "-m64 -mtune=generic" or "-m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables" depending on the platform.
> --enable-debug is not passed to configure.
> 
> Even if I were able to reproduce your original result, there are still
> two cases where your approach may generate more code than is necessary:
> 
> 1. All of the APIs that support the extension use dummy_true.  There
> are many examples of this, but I don't think there are many matching
> users of _mesa_has_XXX_foo().
> 
> 2. All of the APIs support the extension in any version.
> GL_EXT_polygon_offset_clamp is an example.
> 
> I think we can blend the strengths to get something even better.
> 

Agreed.

-Nanley

> I missed that glsl_parser_extras.cpp has its own implementation of the
> has_XXX_foo() functions that take the API and version as explicit
> parameters.  Your patch predates that change.  There's room for some
> modest savings there too.
> 
> I'll send a couple follow-up patches soon.
> 
> > Thanks,
> > Nanley
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/16] anv: Handle transitioning depth from UNDEFINED to other layouts

[Nanley Chery]

On Fri, May 19, 2017 at 06:09:49PM -0700, Nanley Chery wrote:
> On Fri, May 19, 2017 at 05:18:12PM -0700, Jason Ekstrand wrote:
> > On Fri, May 19, 2017 at 4:51 PM, Nanley Chery  wrote:
> > 
> > > On Thu, May 18, 2017 at 02:00:51PM -0700, Jason Ekstrand wrote:
> > > > ---
> > > >  src/intel/vulkan/anv_image.c   | 12 ++--
> > > >  src/intel/vulkan/genX_cmd_buffer.c |  9 +
> > > >  2 files changed, 11 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > > > index d21e055..d65ef47 100644
> > > > --- a/src/intel/vulkan/anv_image.c
> > > > +++ b/src/intel/vulkan/anv_image.c
> > > > @@ -488,12 +488,20 @@ anv_layout_to_aux_usage(const struct
> > > gen_device_info * const devinfo,
> > > > /* According to the Vulkan Spec, the following layouts are valid
> > > only as
> > > >  * initial layouts in a layout transition and don't support device
> > > access.
> > > >  */
> > > > -   case VK_IMAGE_LAYOUT_UNDEFINED:
> > > > -   case VK_IMAGE_LAYOUT_PREINITIALIZED:
> > > > case VK_IMAGE_LAYOUT_RANGE_SIZE:
> > > > case VK_IMAGE_LAYOUT_MAX_ENUM:
> > > >unreachable("Invalid image layout for device access.");
> > > >
> > > > +   /* Undefined layouts
> > > > +*
> > > > +* The pre-initialized layout is equivalent to the undefined layout
> > > for
> > > > +* optimally-tiled images.  We can only do color compression (CCS or
> > > HiZ)
> > > > +* on tiled images.
> > > > +*/
> > > > +   case VK_IMAGE_LAYOUT_UNDEFINED:
> > > > +   case VK_IMAGE_LAYOUT_PREINITIALIZED:
> > > > +  return ISL_AUX_USAGE_NONE;
> > > > +
> > > >
> > >
> > > This function is defined to return the isl_aux_usage for "device access"
> > > as described by the Vulkan spec. The user is not allowed to perform
> > > device accesses in either of those layouts (11.4. Image Layouts). My
> > > suggestion for dealing with this can be found below.
> > >
> > 
> > I guess I don't really see why the "device access" distinction is useful.
> > Perhaps you could explain?  Just plugging the two other layouts in seems to
> > work fairly well.
> > 
> > 
> 
> This distinction has helped me to catch the UNDEFINED layout being used
> in an unexpected place (to me at the time). genX_cmd_buffer.c:532.
> 
> At the time we were defining this function, we decided that the caller of
> this function would be responsible for determining the best layout for
> performing a layout transition. 
> 
> I suppose setting the usage to NONE isn't determining the optimal
> layout, but rather a convenient layout. It's getting late, so I'll have
> to give this more thought next week.
> 
> If we do decide to handle those enums here, I think we'll have to update
> some comments in this function.
> 

I've had more time to think about this and I now agree with what you've
done here for the following reasons:
* ISL_AUX_USAGE_NONE is more than an convenient layout/usage. It is
  correct to say that the aux buffer cannot be used in the UNDEFINED
  layout.
* If we still want to maintain the behaviour of not suggesting a
  buffer for a layout that doesn't support device access we can explain
  returning ISL_AUX_USAGE_NONE for UNDEFINED with the fact that NONE
  doesn't suggest using the main buffer, but rather states a restriction
  on the aux buffer.
* As you mentioned, handling UNDEFINED in the mapping function as we do
  with this patch quite nicely gives us the behavior we want in the
  transitioning function.

With this change, I think we should also update some comments in the
layout_to_aux_usage function like:
* Dropping the NOTE at the top (it's not really saying anything useful).
* Moving & updating (or dropping) the comment that used to be above 
  VK_IMAGE_LAYOUT_UNDEFINED.

-Nanley

> > > > /* Transfer Layouts
> > > >  *
> > > > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > > b/src/intel/vulkan/genX_cmd_buffer.c
> > > > index 1f30a12..8d5f61b 100644
> > > > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > > > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > > > @@ -355,15 +355,8 @@ transition_depth_buffer(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > >  * The undefined layout indicates that the user doesn't care about
> > > the data
> > > >  * that's currently in the buffer. Therefore, a data-preserving
> > > resolve
> > > >  * operation is not needed.
> > > > -*
> > > > -* The pre-initialized layout is equivalent to the undefined layout
> > > for
> > > > -* optimally-tiled images. Anv only exposes support for
> > > optimally-tiled
> > > > -* depth buffers.
> > > >  */
> > > > -   if (image->aux_usage != ISL_AUX_USAGE_HIZ ||
> > > > -   initial_layout == final_layout ||
> > > > -   initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
> > > > -   initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED)
> > > > +   if (image->aux_usage != ISL_AUX_USAGE_HIZ || initial_layout ==
> > > final_layout)
> > 

Re: [Mesa-dev] [PATCH 1/6] glsl: Prehash in refcount hash table to reduce hashing

[Thomas Helland]

2017-05-22 21:19 GMT+02:00 Ian Romanick :
> On 05/22/2017 11:55 AM, Thomas Helland wrote:
>> _mesa_hash_table_search is one of our hottest function according to perf.
>> Callgrind shows the refcounting as one of the major users of the
>> searching functions. We can reduce the pain by prehashing, so that we
>> avoid hashing two times when inserting in the table.
>>
>> On a short shader-db run (with validation disabled) it makes
>> 1.2 million of 4.5 million calls to _hash_table_insert come from
>> the pre-hashed path.
>
> Did this have any measurable impact on the run time?
>

Not as I can tell. I believe it is mostly just accumulating a slight
gain from each patch. However, coming to think of it, the big one
here might actually be string_to_uint_map, as that one has to hash
strings instead of just pointers. I guess the pointer hashing is now
so fast that it doesn't really matter.

However, this is all a bit hard to measure. I would probably have
to instrument this, and run it on my desktop, maybe with
GALLIUM_NOOP set, in order to get conclusive results. My poor
old ivy-bridge ultrabook has seen better days and is giving me
quite hard-to-conlude-on results. What I can tell for sure though,
is that the number of executed instructions drops by about 0.1%
for this patch only.

I can do some tests on my desktop tomorrow, if you'd like that.
Then I would probably be able to get more conclusive results.

>> ---
>>  src/compiler/glsl/ir_variable_refcount.cpp | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ir_variable_refcount.cpp 
>> b/src/compiler/glsl/ir_variable_refcount.cpp
>> index 8306be10b9..bbb4c0ddd7 100644
>> --- a/src/compiler/glsl/ir_variable_refcount.cpp
>> +++ b/src/compiler/glsl/ir_variable_refcount.cpp
>> @@ -79,13 +79,16 @@ 
>> ir_variable_refcount_visitor::get_variable_entry(ir_variable *var)
>>  {
>> assert(var);
>>
>> -   struct hash_entry *e = _mesa_hash_table_search(this->ht, var);
>> +   uint32_t hash = this->ht->key_hash_function(var);
>> +
>> +   struct hash_entry *e =
>> +  _mesa_hash_table_search_pre_hashed(this->ht, hash, var);
>> if (e)
>>return (ir_variable_refcount_entry *)e->data;
>>
>> ir_variable_refcount_entry *entry = new ir_variable_refcount_entry(var);
>> assert(entry->referenced_count == 0);
>> -   _mesa_hash_table_insert(this->ht, var, entry);
>> +   _mesa_hash_table_insert_pre_hashed(this->ht, hash, var, entry);
>>
>> return entry;
>>  }
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Remove GL_APPLE_vertex_array_object stubs

[Ian Romanick]

From: Ian Romanick 

Mark the functions 'exec="skip"' in the XML instead.  libGL will still
have the functions, but the driver won't try to use them.  I verified
that this commit works with piglit's 'object-namespace-pollution glClear
vertex-array' on x64 with a driver built from mesa-12.0.3 tag.

In fairness, this test also works with a libGL built from 7927d03.  I
believe it continues to work because on non-Windows platforms we
generate some extra, dummy dispatch functions that can be used when a
driver requests a function unknown to libGL.  This was done to provide
some "forward" compatibility with drivers that need more functions.
This doesn't work on Windows because the Windows calling convention is
for the callee to clean up the stack.  That's the theory anyway.

Signed-off-by: Ian Romanick 
---
 src/mapi/glapi/gen/APPLE_vertex_array_object.xml |  8 
 src/mesa/main/arrayobj.c | 16 
 src/mesa/main/arrayobj.h |  4 
 src/mesa/main/tests/dispatch_sanity.cpp  |  2 --
 4 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml 
b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
index 7312f9b..daf6990 100644
--- a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
+++ b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
@@ -5,21 +5,21 @@
 
 
 
-
+
 
 
 
-
+
 

 
 
-
+
 

 
 
-
+
 

 
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index b986229..82c00fb 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -473,14 +473,6 @@ _mesa_BindVertexArray( GLuint id )
 }
 
 
-void GLAPIENTRY
-_mesa_BindVertexArrayAPPLE(GLuint id)
-{
-   GET_CURRENT_CONTEXT(ctx);
-   _mesa_problem(ctx, "APPLE_vertex_array_object is not supported!");
-}
-
-
 /**
  * Delete a set of array objects.
  *
@@ -587,14 +579,6 @@ _mesa_GenVertexArrays(GLsizei n, GLuint *arrays)
 }
 
 
-void GLAPIENTRY
-_mesa_GenVertexArraysAPPLE(GLsizei n, GLuint *arrays)
-{
-   GET_CURRENT_CONTEXT(ctx);
-   _mesa_problem(ctx, "APPLE_vertex_array_object is not supported!");
-}
-
-
 /**
  * ARB_direct_state_access
  * Generates ID's and creates the array objects.
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 097027b..1794968 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -96,14 +96,10 @@ _mesa_all_buffers_are_unmapped(const struct 
gl_vertex_array_object *vao);
 
 void GLAPIENTRY _mesa_BindVertexArray( GLuint id );
 
-void GLAPIENTRY _mesa_BindVertexArrayAPPLE(GLuint id);
-
 void GLAPIENTRY _mesa_DeleteVertexArrays(GLsizei n, const GLuint *ids);
 
 void GLAPIENTRY _mesa_GenVertexArrays(GLsizei n, GLuint *arrays);
 
-void GLAPIENTRY _mesa_GenVertexArraysAPPLE(GLsizei n, GLuint *buffer);
-
 void GLAPIENTRY _mesa_CreateVertexArrays(GLsizei n, GLuint *arrays);
 
 GLboolean GLAPIENTRY _mesa_IsVertexArray( GLuint id );
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index 12a9ee7..b33043e 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -969,8 +969,6 @@ const struct function common_desktop_functions_possible[] = 
{
 };
 
 const struct function gl_compatibility_functions_possible[] = {
-   { "glBindVertexArrayAPPLE", 10, -1 },
-   { "glGenVertexArraysAPPLE", 10, -1 },
{ "glBindRenderbufferEXT", 10, -1 },
{ "glBindFramebufferEXT", 10, -1 },
{ "glNewList", 10, _gloffset_NewList },
-- 
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/6] glsl: Prehash in refcount hash table to reduce hashing

[Ian Romanick]

On 05/22/2017 11:55 AM, Thomas Helland wrote:
> _mesa_hash_table_search is one of our hottest function according to perf.
> Callgrind shows the refcounting as one of the major users of the
> searching functions. We can reduce the pain by prehashing, so that we
> avoid hashing two times when inserting in the table.
> 
> On a short shader-db run (with validation disabled) it makes
> 1.2 million of 4.5 million calls to _hash_table_insert come from
> the pre-hashed path.

Did this have any measurable impact on the run time?

> ---
>  src/compiler/glsl/ir_variable_refcount.cpp | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compiler/glsl/ir_variable_refcount.cpp 
> b/src/compiler/glsl/ir_variable_refcount.cpp
> index 8306be10b9..bbb4c0ddd7 100644
> --- a/src/compiler/glsl/ir_variable_refcount.cpp
> +++ b/src/compiler/glsl/ir_variable_refcount.cpp
> @@ -79,13 +79,16 @@ 
> ir_variable_refcount_visitor::get_variable_entry(ir_variable *var)
>  {
> assert(var);
>  
> -   struct hash_entry *e = _mesa_hash_table_search(this->ht, var);
> +   uint32_t hash = this->ht->key_hash_function(var);
> +
> +   struct hash_entry *e =
> +  _mesa_hash_table_search_pre_hashed(this->ht, hash, var);
> if (e)
>return (ir_variable_refcount_entry *)e->data;
>  
> ir_variable_refcount_entry *entry = new ir_variable_refcount_entry(var);
> assert(entry->referenced_count == 0);
> -   _mesa_hash_table_insert(this->ht, var, entry);
> +   _mesa_hash_table_insert_pre_hashed(this->ht, hash, var, entry);
>  
> return entry;
>  }
> 

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

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Ian Romanick]

On 05/22/2017 12:02 PM, Marek Olšák wrote:
> On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle  wrote:
>> Hi all,
>>
>> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy re-inventing
>> the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
>> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into re-using
>> that.
>>
>> It's not entirely straightforward because radeonsi and radv use different
>> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
>> SGPR allocations, descriptor loads work differently (obviously), and so on.
>>
>> Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
>> translation. So here goes...
>>
>>
>> The Step-by-Step Plan
>> =
>>
>> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for very
>> simple VS-PS pipelines.
>>
>> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
>> pipelines.
>>
>> 3. Fill in all the rest:
>> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
>> 3b. Geometry and tessellation shaders
>> 3c. Compute shaders
>> 3d. Tests
>>
>> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
>> working via NIR. The code is here:
>> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>>
>> The basic approach is to introduce `struct ac_shader_abi' to capture the
>> differences between radeonsi and radv. In the end, the entry point for NIR
>> -> LLVM translation will simply be:
>>
>>void ac_nir_translate(struct ac_llvm_context *ac,
>>  struct ac_shader_abi *abi,
>>  struct nir_shader *nir);
>>
>> Setting up the LLVM function with its parameters is still considered part of
>> the driver.
> 
> This sounds good.
> 
>>
>>
>> Questions
>> =
>>
>> 1. How do we get good test coverage?
>> 
>> A natural candidate would be to add a SPIR-V execution mode for the piglit
>> shader_runner. That is, use build scripts to extract shaders from
>> shader_test files and feed them through glslang to get spv files, and then
>> load those from shader_runner if a `-spirv' flag is passed on the command
>> line.
>>
>> This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
>> linking semantics, and I'm pretty sure the majority of shader_test files
>> don't support that -- if only because they don't set a location on the
>> fragment shader color output.
>>
>> Some ideas:
>> 1. Add a GL_MESA_spirv_link_by_name extension
>> 2. Have glslang add the locations for us (probably difficult because glslang
>> seems to be focused on one shader stage at a time.)
>> 3. Hack something together in the shader_test-to-spv build scripts via
>> regular expressions (and now we have two problems? :-) )
>> 4. Other ideas?
> 
> We have plenty of GLSL SSO shader tests in shader-db, but we can only
> compile-test them.
> 
> Initially I think we can convert a few shader tests to SSO manually
> and use those.
> 
>>
>>
>> 2. What's the Gallium interface?
>> 
>> Specifically, does it pass SPIR-V or NIR?
>>
>> I'm leaning towards NIR, because then specialization, mapping of uniform
>> locations, atomics, etc. can be done entirely in st/mesa.
>>
>> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the third
>> hand, it wouldn't be the first time that clover does things differently.
> 
> If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
> LLVM, you wouldn't need the serialization capability in NIR. You can
> just use SPIR-V as the shader binary and the major NIR disadvantage is
> gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
> shader cache will continue working as-is.

I was going to suggest something like this.  I've also wondered if
SPIR-V might be a reasonable serialization for NIR.  I haven't given it
a lot of thought, though, so it may be rubbish.

> However, I don't know how much GL awareness is required for doing
> SPIR-V -> NIR in radeonsi. Additional GL-specific information might
> have to be added to SPIR-V by st/mesa for the conversion to be doable.
> You probably know better.
> 
> st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
> gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
> know how feasible that is, but it seems to be the only thing needed in
> shared code.
> 
> That also answers the NIR vs TGSI debate for the shader cache. The
> answer is: Neither.
> 
> 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

[Mesa-dev] [v2 4/7] i965/gen4: Simplify depth/stencil invalidate check

[Topi Pohjolainen]

There is no separate stencil on gen < 6.

Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 9fe3655..8bcc0e6 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -230,21 +230,11 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
   return;
 
/* Check if depth buffer is in depth/stencil format.  If so, then it's only
-* safe to invalidate it if we're also clearing stencil, and both depth_irb
-* and stencil_irb point to the same miptree.
-*
-* Note: it's not sufficient to check for the case where
-* _mesa_get_format_base_format(depth_mt->format) == GL_DEPTH_STENCIL,
-* because this fails to catch depth/stencil buffers on hardware that uses
-* separate stencil.  To catch that case, we check whether
-* depth_mt->stencil_mt is non-NULL.
+* safe to invalidate it if we're also clearing stencil.
 */
if (depth_irb && invalidate_depth &&
-   (_mesa_get_format_base_format(depth_mt->format) == GL_DEPTH_STENCIL ||
-depth_mt->stencil_mt)) {
-  invalidate_depth = invalidate_stencil && depth_irb && stencil_irb
- && depth_irb->mt == stencil_irb->mt;
-   }
+  _mesa_get_format_base_format(depth_mt->format) == GL_DEPTH_STENCIL)
+  invalidate_depth = invalidate_stencil && stencil_irb;
 
uint32_t tile_mask_x, tile_mask_y;
brw_get_depthstencil_tile_masks(depth_mt,
-- 
2.9.3

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

[Mesa-dev] [v2 5/7] i965: Drop depth/stencil miptree pointers in alignment workaround

[Topi Pohjolainen]

In brw_workaround_depthstencil_alignment() corresponding
renderbuffers are always set to refer to the same temp miptrees.
There is no need to carry them in context.

Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_context.h|  3 ---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 15 +++
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 379c18f..dda8f80 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1196,9 +1196,6 @@ struct brw_context
 * brw_workaround_depthstencil_alignment().
 */
struct {
-  struct intel_mipmap_tree *depth_mt;
-  struct intel_mipmap_tree *stencil_mt;
-
   /* Inter-tile (page-aligned) byte offsets. */
   uint32_t depth_offset;
   /* Intra-tile x,y offsets for drawing to combined depth-stencil. Only
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 8bcc0e6..681f54d 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -216,12 +216,6 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
brw->depthstencil.tile_x = 0;
brw->depthstencil.tile_y = 0;
brw->depthstencil.depth_offset = 0;
-   brw->depthstencil.depth_mt = NULL;
-   brw->depthstencil.stencil_mt = NULL;
-   if (depth_irb)
-  brw->depthstencil.depth_mt = depth_mt;
-   if (stencil_irb)
-  brw->depthstencil.stencil_mt = get_stencil_miptree(stencil_irb);
 
/* Gen6+ doesn't require the workarounds, since we always program the
 * surface state at the start of the whole surface.
@@ -355,10 +349,8 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
brw->depthstencil.tile_x = tile_x;
brw->depthstencil.tile_y = tile_y;
if (depth_irb) {
-  depth_mt = depth_irb->mt;
-  brw->depthstencil.depth_mt = depth_mt;
   brw->depthstencil.depth_offset =
- intel_miptree_get_aligned_offset(depth_mt,
+ intel_miptree_get_aligned_offset(depth_irb->mt,
   depth_irb->draw_x & ~tile_mask_x,
   depth_irb->draw_y & ~tile_mask_y);
   assert(!intel_renderbuffer_has_hiz(depth_irb));
@@ -366,7 +358,6 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
if (stencil_irb) {
   stencil_mt = get_stencil_miptree(stencil_irb);
 
-  brw->depthstencil.stencil_mt = stencil_mt;
   assert(stencil_mt->format != MESA_FORMAT_S_UINT8);
 
   if (!depth_irb) {
@@ -387,8 +378,8 @@ brw_emit_depthbuffer(struct brw_context *brw)
/* _NEW_BUFFERS */
struct intel_renderbuffer *depth_irb = intel_get_renderbuffer(fb, 
BUFFER_DEPTH);
struct intel_renderbuffer *stencil_irb = intel_get_renderbuffer(fb, 
BUFFER_STENCIL);
-   struct intel_mipmap_tree *depth_mt = brw->depthstencil.depth_mt;
-   struct intel_mipmap_tree *stencil_mt = brw->depthstencil.stencil_mt;
+   struct intel_mipmap_tree *depth_mt = depth_irb ? depth_irb->mt : NULL;
+   struct intel_mipmap_tree *stencil_mt = get_stencil_miptree(stencil_irb);
uint32_t tile_x = brw->depthstencil.tile_x;
uint32_t tile_y = brw->depthstencil.tile_y;
bool hiz = depth_irb && intel_renderbuffer_has_hiz(depth_irb);
-- 
2.9.3

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

[Mesa-dev] [v2 7/7] i965/gen4: Tell briefly how workaround depth gets reconciled

[Topi Pohjolainen]

CC: Kenneth Graunke 
Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 85050ce..fe021b0 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -165,6 +165,13 @@ rebase_depth_stencil(struct brw_context *brw, struct 
intel_renderbuffer *irb,
   perf_debug("HW workaround: blitting depth level %d to a temporary "
  "to fix alignment (depth tile offset %d,%d)\n",
  irb->mt_level, tile_x, tile_y);
+
+  /* Create new miptree representing single "irb->mt_level" only and
+   * make renderbuffer point this instead of the full miptree. Note that
+   * the underlying texture object still carries reference to the original
+   * full mipmap tree and intel_finalize_mipmap_tree() will eventually
+   * merge these two.
+   */
   intel_renderbuffer_move_to_temp(brw, irb, invalidate);
 
   /* Get the new offset. */
-- 
2.9.3

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

[Mesa-dev] [v2 3/7] i965/gen4: Remove redundant check for depth when rebasing stencil

[Topi Pohjolainen]

In case of gen < 6 stencil (if present) is always combined with
depth. Both stencil and depth attachments point to the same
physical surface.
Alignment workaround starts by considering depth and updates
stencil accordingly. Current logic continues with stencil and
in vain considers the case where depth would refer to different
surface than stencil.

Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 63 ++
 1 file changed, 12 insertions(+), 51 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 6ea1fb0..9fe3655 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -295,28 +295,14 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
   }
 
   if (stencil_irb) {
- stencil_mt = get_stencil_miptree(stencil_irb);
- intel_miptree_get_image_offset(stencil_mt,
-stencil_irb->mt_level,
-stencil_irb->mt_layer,
-_draw_x, _draw_y);
- int stencil_tile_x = stencil_draw_x & tile_mask_x;
- int stencil_tile_y = stencil_draw_y & tile_mask_y;
-
- /* If stencil doesn't match depth, then we'll need to rebase stencil
-  * as well.  (if we hadn't decided to rebase stencil before, the
-  * post-stencil depth test will also rebase depth to try to match it
-  * up).
-  */
- if (tile_x != stencil_tile_x ||
- tile_y != stencil_tile_y) {
-rebase_stencil = true;
- }
+ assert(stencil_irb->mt == depth_irb->mt);
+ assert(stencil_irb->mt_level == depth_irb->mt_level);
+ assert(stencil_irb->mt_layer == depth_irb->mt_layer);
   }
}
 
/* If we have (just) stencil, check it for ignored low bits as well */
-   if (stencil_irb) {
+   if (!depth_irb && stencil_irb) {
   intel_miptree_get_image_offset(stencil_mt,
  stencil_irb->mt_level,
  stencil_irb->mt_layer,
@@ -334,6 +320,14 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
}
 
if (rebase_stencil) {
+  /* If stencil needs rebase, there isn't a depth attachment and the
+   * combined depth-stencil is used for stencil only. Otherwise in case
+   * depth attachment is present both stencil and depth point to the same
+   * miptree. Rebase of depth is considered first updating stencil
+   * attachment accordingly - hence stencil is rebased only if there is no
+   * depth attachment.
+   */
+  assert(!depth_irb);
   perf_debug("HW workaround: blitting stencil level %d to a temporary "
  "to fix alignment (stencil tile offset %d,%d)\n",
  stencil_irb->mt_level, stencil_tile_x, stencil_tile_y);
@@ -347,39 +341,6 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
  _draw_x, _draw_y);
   stencil_tile_x = stencil_draw_x & tile_mask_x;
   stencil_tile_y = stencil_draw_y & tile_mask_y;
-
-  if (depth_irb && depth_irb->mt == stencil_irb->mt) {
- intel_miptree_reference(_irb->mt, stencil_irb->mt);
- intel_renderbuffer_set_draw_offset(depth_irb);
-  } else if (depth_irb && !rebase_depth) {
- if (tile_x != stencil_tile_x ||
- tile_y != stencil_tile_y) {
-perf_debug("HW workaround: blitting depth level %d to a temporary "
-   "to match stencil level %d alignment (depth tile offset 
"
-   "%d,%d, stencil offset %d,%d)\n",
-   depth_irb->mt_level,
-   stencil_irb->mt_level,
-   tile_x, tile_y,
-   stencil_tile_x, stencil_tile_y);
-
-intel_renderbuffer_move_to_temp(brw, depth_irb, invalidate_depth);
-
-tile_x = depth_irb->draw_x & tile_mask_x;
-tile_y = depth_irb->draw_y & tile_mask_y;
-
-if (stencil_irb && stencil_irb->mt == depth_mt) {
-   intel_miptree_reference(_irb->mt, depth_irb->mt);
-   intel_renderbuffer_set_draw_offset(stencil_irb);
-}
-
-WARN_ONCE(stencil_tile_x != tile_x ||
-  stencil_tile_y != tile_y,
-  "Rebased stencil tile offset (%d,%d) doesn't match depth 
"
-  "tile offset (%d,%d).\n",
-  stencil_tile_x, stencil_tile_y,
-  tile_x, tile_y);
- }
-  }
}
 
if (!depth_irb) {
-- 
2.9.3

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

[Mesa-dev] [v2 1/7] i965/gen4: Set depth offset when there is stencil attachment only

[Topi Pohjolainen]

Current version fails to set depthstencil.depth_offset when there
is only stencil attachment (it does set the intra tile offsets
though). Fixes piglits:

g45,g965,ilk:   depthstencil-render-miplevels 1024 s=z24_s8
g45,ilk:depthstencil-render-miplevels 273 s=z24_s8

CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index afa7e08..66f8555 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -431,6 +431,12 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
  brw->depthstencil.stencil_offset =
 (stencil_draw_y & ~tile_mask_y) * stencil_mt->pitch +
 (stencil_draw_x & ~tile_mask_x) * 64;
+  } else if (!depth_irb) {
+ brw->depthstencil.depth_offset =
+intel_miptree_get_aligned_offset(
+   stencil_mt,
+   stencil_irb->draw_x & ~tile_mask_x,
+   stencil_irb->draw_y & ~tile_mask_y);
   }
}
 }
-- 
2.9.3

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

[Mesa-dev] [v2 2/7] i965/gen4: Remove non-existing stencil and hiz buffer setup

[Topi Pohjolainen]

Separate stencil and hiz are only enabled for gen6+.

Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_context.h|   6 +-
 src/mesa/drivers/dri/i965/brw_misc_state.c | 120 +++--
 2 files changed, 14 insertions(+), 112 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 6b37500..379c18f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1200,8 +1200,10 @@ struct brw_context
   struct intel_mipmap_tree *stencil_mt;
 
   /* Inter-tile (page-aligned) byte offsets. */
-  uint32_t depth_offset, hiz_offset, stencil_offset;
-  /* Intra-tile x,y offsets for drawing to depth/stencil/hiz */
+  uint32_t depth_offset;
+  /* Intra-tile x,y offsets for drawing to combined depth-stencil. Only
+   * used for Gen < 6.
+   */
   uint32_t tile_x, tile_y;
} depthstencil;
 
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 66f8555..6ea1fb0 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -216,8 +216,6 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
brw->depthstencil.tile_x = 0;
brw->depthstencil.tile_y = 0;
brw->depthstencil.depth_offset = 0;
-   brw->depthstencil.stencil_offset = 0;
-   brw->depthstencil.hiz_offset = 0;
brw->depthstencil.depth_mt = NULL;
brw->depthstencil.stencil_mt = NULL;
if (depth_irb)
@@ -412,26 +410,15 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
  intel_miptree_get_aligned_offset(depth_mt,
   depth_irb->draw_x & ~tile_mask_x,
   depth_irb->draw_y & ~tile_mask_y);
-  if (intel_renderbuffer_has_hiz(depth_irb)) {
- brw->depthstencil.hiz_offset =
-intel_miptree_get_aligned_offset(depth_mt,
- depth_irb->draw_x & ~tile_mask_x,
- (depth_irb->draw_y & 
~tile_mask_y) / 2);
-  }
+  assert(!intel_renderbuffer_has_hiz(depth_irb));
}
if (stencil_irb) {
   stencil_mt = get_stencil_miptree(stencil_irb);
 
   brw->depthstencil.stencil_mt = stencil_mt;
-  if (stencil_mt->format == MESA_FORMAT_S_UINT8) {
- /* Note: we can't compute the stencil offset using
-  * intel_region_get_aligned_offset(), because stencil_region claims
-  * that the region is untiled even though it's W tiled.
-  */
- brw->depthstencil.stencil_offset =
-(stencil_draw_y & ~tile_mask_y) * stencil_mt->pitch +
-(stencil_draw_x & ~tile_mask_x) * 64;
-  } else if (!depth_irb) {
+  assert(stencil_mt->format != MESA_FORMAT_S_UINT8);
+
+  if (!depth_irb) {
  brw->depthstencil.depth_offset =
 intel_miptree_get_aligned_offset(
stencil_mt,
@@ -539,39 +526,19 @@ brw_emit_depth_stencil_hiz(struct brw_context *brw,
uint32_t width, uint32_t height,
uint32_t tile_x, uint32_t tile_y)
 {
-   /* Enable the hiz bit if we're doing separate stencil, because it and the
-* separate stencil bit must have the same value. From Section 2.11.5.6.1.1
-* 3DSTATE_DEPTH_BUFFER, Bit 1.21 "Separate Stencil Enable":
-* [DevIL]: If this field is enabled, Hierarchical Depth Buffer
-* Enable must also be enabled.
-*
-* [DevGT]: This field must be set to the same value (enabled or
-* disabled) as Hierarchical Depth Buffer Enable
-*/
-   bool enable_hiz_ss = hiz || separate_stencil;
-
+   (void)hiz;
+   (void)separate_stencil;
+   (void)stencil_mt;
 
-   /* 3DSTATE_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER are both
-* non-pipelined state that will need the PIPE_CONTROL workaround.
-*/
-   if (brw->gen == 6) {
-  brw_emit_depth_stall_flushes(brw);
-   }
+   assert(!hiz);
+   assert(!separate_stencil);
 
-   unsigned int len;
-   if (brw->gen >= 6)
-  len = 7;
-   else if (brw->is_g4x || brw->gen == 5)
-  len = 6;
-   else
-  len = 5;
+   const unsigned len = (brw->is_g4x || brw->gen == 5) ? 6 : 5;
 
BEGIN_BATCH(len);
OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (len - 2));
OUT_BATCH((depth_mt ? depth_mt->pitch - 1 : 0) |
  (depthbuffer_format << 18) |
- ((enable_hiz_ss ? 1 : 0) << 21) | /* separate stencil enable */
- ((enable_hiz_ss ? 1 : 0) << 22) | /* hiz enable */
  (BRW_TILEWALK_YMAJOR << 26) |
  ((depth_mt ? depth_mt->tiling != I915_TILING_NONE : 1)
   << 27) |
@@ -598,73 +565,6 @@ brw_emit_depth_stencil_hiz(struct brw_context *brw,
   OUT_BATCH(0);
 
ADVANCE_BATCH();
-
-   if (hiz || separate_stencil) {
-  /*
-   * In the 

[Mesa-dev] [v2 6/7] i965/gen4: Refactor depth/stencil rebase

[Topi Pohjolainen]

Effectively there is the same code twice, once for depth and
again for stencil.

Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 243 -
 1 file changed, 63 insertions(+), 180 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 681f54d..85050ce 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -125,62 +125,6 @@ brw_depthbuffer_format(struct brw_context *brw)
return brw_depth_format(brw, drb->mt->format);
 }
 
-/**
- * Returns the mask of how many bits of x and y must be handled through the
- * depthbuffer's draw offset x and y fields.
- *
- * The draw offset x/y field of the depthbuffer packet is unfortunately shared
- * between the depth, hiz, and stencil buffers.  Because it can be hard to get
- * all 3 to agree on this value, we want to do as much drawing offset
- * adjustment as possible by moving the base offset of the 3 buffers, which is
- * restricted to tile boundaries.
- *
- * For each buffer, the remainder must be applied through the x/y draw offset.
- * This returns the worst-case mask of the low bits that have to go into the
- * packet.  If the 3 buffers don't agree on the drawing offset ANDed with this
- * mask, then we're in trouble.
- */
-static void
-brw_get_depthstencil_tile_masks(struct intel_mipmap_tree *depth_mt,
-uint32_t depth_level,
-uint32_t depth_layer,
-struct intel_mipmap_tree *stencil_mt,
-uint32_t *out_tile_mask_x,
-uint32_t *out_tile_mask_y)
-{
-   uint32_t tile_mask_x = 0, tile_mask_y = 0;
-
-   if (depth_mt) {
-  intel_get_tile_masks(depth_mt->tiling,
-   depth_mt->cpp,
-   _mask_x, _mask_y);
-  assert(!intel_miptree_level_has_hiz(depth_mt, depth_level));
-   }
-
-   if (stencil_mt) {
-  if (stencil_mt->stencil_mt)
-stencil_mt = stencil_mt->stencil_mt;
-
-  if (stencil_mt->format == MESA_FORMAT_S_UINT8) {
- /* Separate stencil buffer uses 64x64 tiles. */
- tile_mask_x |= 63;
- tile_mask_y |= 63;
-  } else {
- uint32_t stencil_tile_mask_x, stencil_tile_mask_y;
- intel_get_tile_masks(stencil_mt->tiling,
-  stencil_mt->cpp,
-  _tile_mask_x,
-  _tile_mask_y);
-
- tile_mask_x |= stencil_tile_mask_x;
- tile_mask_y |= stencil_tile_mask_y;
-  }
-   }
-
-   *out_tile_mask_x = tile_mask_x;
-   *out_tile_mask_y = tile_mask_y;
-}
-
 static struct intel_mipmap_tree *
 get_stencil_miptree(struct intel_renderbuffer *irb)
 {
@@ -191,20 +135,74 @@ get_stencil_miptree(struct intel_renderbuffer *irb)
return irb->mt;
 }
 
+static bool
+rebase_depth_stencil(struct brw_context *brw, struct intel_renderbuffer *irb,
+ bool invalidate)
+{
+   struct gl_context *ctx = >ctx;
+   uint32_t tile_mask_x = 0, tile_mask_y = 0;
+
+   intel_get_tile_masks(irb->mt->tiling, irb->mt->cpp,
+_mask_x, _mask_y);
+   assert(!intel_miptree_level_has_hiz(irb->mt, irb->mt_level));
+
+   uint32_t tile_x = irb->draw_x & tile_mask_x;
+   uint32_t tile_y = irb->draw_y & tile_mask_y;
+
+   /* According to the Sandy Bridge PRM, volume 2 part 1, pp326-327
+* (3DSTATE_DEPTH_BUFFER dw5), in the documentation for "Depth
+* Coordinate Offset X/Y":
+*
+*   "The 3 LSBs of both offsets must be zero to ensure correct
+*   alignment"
+*/
+   bool rebase = tile_x & 7 || tile_y & 7;
+
+   /* We didn't even have intra-tile offsets before g45. */
+   rebase |= (!brw->has_surface_tile_offset && (tile_x || tile_y));
+
+   if (rebase) {
+  perf_debug("HW workaround: blitting depth level %d to a temporary "
+ "to fix alignment (depth tile offset %d,%d)\n",
+ irb->mt_level, tile_x, tile_y);
+  intel_renderbuffer_move_to_temp(brw, irb, invalidate);
+
+  /* Get the new offset. */
+  tile_x = irb->draw_x & tile_mask_x;
+  tile_y = irb->draw_y & tile_mask_y;
+   }
+
+   /* While we just tried to get everything aligned, we may have failed to do
+* so in the case of rendering to array or 3D textures, where nonzero faces
+* will still have an offset post-rebase.  At least give an informative
+* warning.
+*/
+   WARN_ONCE((tile_x & 7) || (tile_y & 7),
+ "Depth/stencil buffer needs alignment to 8-pixel boundaries.\n"
+ "Truncating offset (%u:%u), bad rendering may occur.\n",
+ tile_x, tile_y);
+   tile_x &= ~7;
+   tile_y &= ~7;
+
+   brw->depthstencil.tile_x = tile_x;
+   brw->depthstencil.tile_y = tile_y;
+   brw->depthstencil.depth_offset = intel_miptree_get_aligned_offset(
+ 

Re: [Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

[Marek Olšák]

On Sun, May 21, 2017 at 12:48 PM, Nicolai Hähnle  wrote:
> Hi all,
>
> I've been looking into ARB_gl_spirv for radeonsi. I don't fancy re-inventing
> the ~8k LOC of src/compiler/spirv, and there's already a perfectly fine
> SPIR-V -> NIR -> LLVM compiler pipeline in radv, so I looked into re-using
> that.
>
> It's not entirely straightforward because radeonsi and radv use different
> "ABIs" for their shaders, i.e. prolog/epilog shader parts, different user
> SGPR allocations, descriptor loads work differently (obviously), and so on.
>
> Still, it's possible to separate the ABI from the meat of the NIR -> LLVM
> translation. So here goes...
>
>
> The Step-by-Step Plan
> =
>
> 1. Add an optional GLSL-to-NIR path (controlled by R600_DEBUG=nir) for very
> simple VS-PS pipelines.
>
> 2. Add GL_ARB_gl_spirv support to Mesa and test it on simple VS-PS
> pipelines.
>
> 3. Fill in all the rest:
> 3a. GL 4.x shader extensions (SSBOs, images, atomics, ...)
> 3b. Geometry and tessellation shaders
> 3c. Compute shaders
> 3d. Tests
>
> I've started with step 1 and got basic GLSL 1.30-level vertex shaders
> working via NIR. The code is here:
> https://cgit.freedesktop.org/~nh/mesa/log/?h=nir
>
> The basic approach is to introduce `struct ac_shader_abi' to capture the
> differences between radeonsi and radv. In the end, the entry point for NIR
> -> LLVM translation will simply be:
>
>void ac_nir_translate(struct ac_llvm_context *ac,
>  struct ac_shader_abi *abi,
>  struct nir_shader *nir);
>
> Setting up the LLVM function with its parameters is still considered part of
> the driver.

This sounds good.

>
>
> Questions
> =
>
> 1. How do we get good test coverage?
> 
> A natural candidate would be to add a SPIR-V execution mode for the piglit
> shader_runner. That is, use build scripts to extract shaders from
> shader_test files and feed them through glslang to get spv files, and then
> load those from shader_runner if a `-spirv' flag is passed on the command
> line.
>
> This immediately runs into the difficulty that GL_ARB_gl_spirv wants SSO
> linking semantics, and I'm pretty sure the majority of shader_test files
> don't support that -- if only because they don't set a location on the
> fragment shader color output.
>
> Some ideas:
> 1. Add a GL_MESA_spirv_link_by_name extension
> 2. Have glslang add the locations for us (probably difficult because glslang
> seems to be focused on one shader stage at a time.)
> 3. Hack something together in the shader_test-to-spv build scripts via
> regular expressions (and now we have two problems? :-) )
> 4. Other ideas?

We have plenty of GLSL SSO shader tests in shader-db, but we can only
compile-test them.

Initially I think we can convert a few shader tests to SSO manually
and use those.

>
>
> 2. What's the Gallium interface?
> 
> Specifically, does it pass SPIR-V or NIR?
>
> I'm leaning towards NIR, because then specialization, mapping of uniform
> locations, atomics, etc. can be done entirely in st/mesa.
>
> On the other hand, Pierre Moreau's work passes SPIR-V directly. On the third
> hand, it wouldn't be the first time that clover does things differently.

If you passed SPIR-V to radeonsi and let radeonsi do SPIR-V -> NIR ->
LLVM, you wouldn't need the serialization capability in NIR. You can
just use SPIR-V as the shader binary and the major NIR disadvantage is
gone. Also, you won't have to touch GLSL-to-NIR, and the radeonsi
shader cache will continue working as-is.

However, I don't know how much GL awareness is required for doing
SPIR-V -> NIR in radeonsi. Additional GL-specific information might
have to be added to SPIR-V by st/mesa for the conversion to be doable.
You probably know better.

st/mesa or core Mesa just needs to fill gl_program, gl_shader, and
gl_shader_program by parsing SPIR-V and not relying on NIR. I don't
know how feasible that is, but it seems to be the only thing needed in
shared code.

That also answers the NIR vs TGSI debate for the shader cache. The
answer is: Neither.

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

Re: [Mesa-dev] [PATCH] st/nine: Fix a regression and syntax cleanup

[Edmondo Tommasina]

The crash with STALKER: CoC is fixed with this patch.

Tested-by: Edmondo Tommasina 

Thanks
edmondo


On Mon, May 22, 2017 at 12:22 AM, Axel Davy  wrote:
> A few cleanups and in particular initializing properly
> the new pipe_draw_info fields.
> This should fix the regression caused by
> 330d0607ed60fd3edca192e54b4246310f06652f
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101088
>
> Signed-off-by: Axel Davy 
> ---
>  src/gallium/state_trackers/nine/device9.c  |  2 +-
>  src/gallium/state_trackers/nine/indexbuffer9.c |  8 ++--
>  src/gallium/state_trackers/nine/indexbuffer9.h |  5 ++---
>  src/gallium/state_trackers/nine/nine_state.c   | 20 +++-
>  4 files changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c 
> b/src/gallium/state_trackers/nine/device9.c
> index db33fdd580..37880405e9 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -2927,7 +2927,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
> *This,
> ibuf,
> ibuf ? NULL : 
> (void*)pIndexData,
> index_offset,
> -  index_size);
> +   index_size);
>  NineAfterDraw(This);
>
>  pipe_vertex_buffer_unreference();
> diff --git a/src/gallium/state_trackers/nine/indexbuffer9.c 
> b/src/gallium/state_trackers/nine/indexbuffer9.c
> index d5f5492563..e73d29b5bd 100644
> --- a/src/gallium/state_trackers/nine/indexbuffer9.c
> +++ b/src/gallium/state_trackers/nine/indexbuffer9.c
> @@ -49,9 +49,6 @@ NineIndexBuffer9_ctor( struct NineIndexBuffer9 *This,
>  if (FAILED(hr))
>  return hr;
>
> -This->buffer = NULL;
> -This->offset = 0;
> -
>  switch (pDesc->Format) {
>  case D3DFMT_INDEX16: This->index_size = 2; break;
>  case D3DFMT_INDEX32: This->index_size = 4; break;
> @@ -73,11 +70,10 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 *This )
>  }
>
>  struct pipe_resource *
> -NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This )
> +NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This, unsigned *offset )
>  {
>  /* The resource may change */
> -This->buffer = NineBuffer9_GetResource(>base, >offset);
> -return This->buffer;
> +return NineBuffer9_GetResource(>base, offset);
>  }
>
>  HRESULT NINE_WINAPI
> diff --git a/src/gallium/state_trackers/nine/indexbuffer9.h 
> b/src/gallium/state_trackers/nine/indexbuffer9.h
> index 0efad7f5f1..e688488da8 100644
> --- a/src/gallium/state_trackers/nine/indexbuffer9.h
> +++ b/src/gallium/state_trackers/nine/indexbuffer9.h
> @@ -37,8 +37,6 @@ struct NineIndexBuffer9
>  struct NineBuffer9 base;
>
>  /* g3d stuff */
> -struct pipe_resource *buffer;
> -unsigned offset;
>  unsigned index_size;
>
>  D3DINDEXBUFFER_DESC desc;
> @@ -65,7 +63,8 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 *This );
>  /*** Nine private ***/
>
>  struct pipe_resource *
> -NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This );
> +NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This,
> +unsigned *offset );
>
>  /*** Direct3D public ***/
>
> diff --git a/src/gallium/state_trackers/nine/nine_state.c 
> b/src/gallium/state_trackers/nine/nine_state.c
> index 0fc4c8315a..30935760ae 100644
> --- a/src/gallium/state_trackers/nine/nine_state.c
> +++ b/src/gallium/state_trackers/nine/nine_state.c
> @@ -1575,12 +1575,11 @@ nine_context_set_indices(struct NineDevice9 *device,
>  {
>  struct pipe_resource *res = NULL;
>  UINT IndexSize = 0;
> -UINT OffsetInBytes = 0;
> +unsigned OffsetInBytes = 0;
>
>  if (idxbuf) {
> -res = NineIndexBuffer9_GetBuffer(idxbuf);
> +res = NineIndexBuffer9_GetBuffer(idxbuf, );
>  IndexSize = idxbuf->index_size;
> -OffsetInBytes = idxbuf->offset;
>  }
>
>  nine_context_set_indices_apply(device, res, IndexSize, OffsetInBytes);
> @@ -2540,6 +2539,7 @@ init_draw_info(struct pipe_draw_info *info,
>  if (dev->context.stream_instancedata_mask & 
> dev->context.stream_usage_mask)
>  info->instance_count = MAX2(dev->context.stream_freq[0] & 0x7F, 
> 1);
>  info->primitive_restart = FALSE;
> +info->has_user_indices = FALSE;
>  info->restart_index = 0;
>  info->count_from_stream_output = NULL;
>  info->indirect = NULL;
> @@ -2561,17 +2561,18 @@ CSMT_ITEM_NO_WAIT(nine_context_draw_primitive,
>  info.index_bias = 0;
>  info.min_index = info.start;
>  info.max_index = info.count - 1;
> +info.index.resource = NULL;
>
>  context->pipe->draw_vbo(context->pipe, );
>  }
>
>  

Re: [Mesa-dev] [PATCH] u_format_test: Ignore S3TC errors.

[Rhys Kidd]

On Mon, May 22, 2017 at 1:07 PM Jose Fonseca  wrote:

> This prevents spurious failures when libtxc-dxtn-s2tc is installed.
>
> Note: lp_test_format does need any change


s/does/doesn't/

With that commit message fix:

Reviewed-by: Rhys Kidd 

since we were already ignoring
> S3TC failures there.
> ---
>  src/gallium/tests/unit/u_format_test.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/src/gallium/tests/unit/u_format_test.c
> b/src/gallium/tests/unit/u_format_test.c
> index 3145d13616..69d6c7dd3a 100644
> --- a/src/gallium/tests/unit/u_format_test.c
> +++ b/src/gallium/tests/unit/u_format_test.c
> @@ -220,6 +220,11 @@ test_format_fetch_rgba_float(const struct
> util_format_description *format_desc,
>}
> }
>
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, "
> obtained\n");
>print_unpacked_rgba_doubl(format_desc, "", test->unpacked,
> " expected\n");
> @@ -252,6 +257,11 @@ test_format_unpack_rgba_float(const struct
> util_format_description *format_desc,
>}
> }
>
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, "
> obtained\n");
>print_unpacked_rgba_doubl(format_desc, "", test->unpacked,
> " expected\n");
> @@ -302,6 +312,11 @@ test_format_pack_rgba_float(const struct
> util_format_description *format_desc,
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_packed(format_desc, "FAILED: ", packed, " obtained\n");
>print_packed(format_desc, "", test->packed, " expected\n");
> @@ -365,6 +380,11 @@ test_format_unpack_rgba_8unorm(const struct
> util_format_description *format_desc
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, "
> obtained\n");
>print_unpacked_rgba_8unorm(format_desc, "", expected, "
> expected\n");
> @@ -422,6 +442,11 @@ test_format_pack_rgba_8unorm(const struct
> util_format_description *format_desc,
> if ((test->unpacked[0][0][0] * 255.0) != (int)(test->unpacked[0][0][0]
> * 255.0))
>success = TRUE;
>
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_packed(format_desc, "FAILED: ", packed, " obtained\n");
>print_packed(format_desc, "", test->packed, " expected\n");
> --
> 2.11.0
>
> ___
> 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 6/6] util: Avoid computing hash twice in string_to_uint_map

[Thomas Helland]

This is not a hot path, but when we have the functionality we
should take advantage of it.
---
 src/util/string_to_uint_map.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/util/string_to_uint_map.h b/src/util/string_to_uint_map.h
index e0533ec6ea..3248696e88 100644
--- a/src/util/string_to_uint_map.h
+++ b/src/util/string_to_uint_map.h
@@ -138,12 +138,15 @@ public:
   assert(value != UINT_MAX);
   char *dup_key = strdup(key);
 
-  struct hash_entry *entry = _mesa_hash_table_search(this->ht, dup_key);
+  uint32_t hash = ht->key_hash_function(dup_key);
+  struct hash_entry *entry =
+_mesa_hash_table_search_pre_hashed(this->ht, hash, dup_key);
+
   if (entry) {
  entry->data = (void *) (intptr_t) (value + 1);
   } else {
- _mesa_hash_table_insert(this->ht, dup_key,
- (void *) (intptr_t) (value + 1));
+ _mesa_hash_table_insert_pre_hashed(this->ht, hash, dup_key,
+(void *) (intptr_t) (value + 1));
   }
 
   if (entry)
-- 
2.13.0

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

[Mesa-dev] [PATCH 2/6] nir: Prehash in instr_set to avoid hashing twice

[Thomas Helland]

This should prove benefitial in the common case of inserting
and not rewriting anything.

V2: Use hash_instr directly instead of going through the function
pointer embedded in the set
---
 src/compiler/nir/nir_instr_set.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_instr_set.c b/src/compiler/nir/nir_instr_set.c
index 9cb9ed43e8..bdc3b02173 100644
--- a/src/compiler/nir/nir_instr_set.c
+++ b/src/compiler/nir/nir_instr_set.c
@@ -508,7 +508,10 @@ nir_instr_set_add_or_rewrite(struct set *instr_set, 
nir_instr *instr)
if (!instr_can_rewrite(instr))
   return false;
 
-   struct set_entry *entry = _mesa_set_search(instr_set, instr);
+   uint32_t hash = hash_instr(instr);
+   struct set_entry *entry =
+  _mesa_set_search_pre_hashed(instr_set, hash, instr);
+
if (entry) {
   nir_ssa_def *def = nir_instr_get_dest_ssa_def(instr);
   nir_instr *match = (nir_instr *) entry->key;
@@ -526,7 +529,7 @@ nir_instr_set_add_or_rewrite(struct set *instr_set, 
nir_instr *instr)
   return true;
}
 
-   _mesa_set_add(instr_set, instr);
+   _mesa_set_add_pre_hashed(instr_set, hash, instr);
return false;
 }
 
-- 
2.13.0

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

[Mesa-dev] [PATCH 3/6] glsl: Prehash in constant propagation

[Thomas Helland]

This should reduce overhead since we can hash only once.
---
 src/compiler/glsl/opt_constant_propagation.cpp | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/opt_constant_propagation.cpp 
b/src/compiler/glsl/opt_constant_propagation.cpp
index 4039512097..553de9c803 100644
--- a/src/compiler/glsl/opt_constant_propagation.cpp
+++ b/src/compiler/glsl/opt_constant_propagation.cpp
@@ -454,15 +454,17 @@ ir_constant_propagation_visitor::kill(ir_variable *var, 
unsigned write_mask)
/* Add this writemask of the variable to the hash table of killed
 * variables in this block.
 */
-   hash_entry *kill_hash_entry = _mesa_hash_table_search(this->kills, var);
+   uint32_t hash = this->kills->key_hash_function(var);
+   hash_entry *kill_hash_entry =
+ _mesa_hash_table_search_pre_hashed(this->kills, hash, var);
if (kill_hash_entry) {
   kill_entry *entry = (kill_entry *) kill_hash_entry->data;
   entry->write_mask |= write_mask;
   return;
}
/* Not already in the hash table.  Make new entry. */
-   _mesa_hash_table_insert(this->kills, var,
-   new(this->lin_ctx) kill_entry(var, write_mask));
+   _mesa_hash_table_insert_pre_hashed(this->kills, hash, var,
+ new(this->lin_ctx) kill_entry(var, write_mask));
 }
 
 /**
-- 
2.13.0

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

[Mesa-dev] [PATCH 0/6] Prehash all the things

[Thomas Helland]

While this doesn't prehash all the things, it does switch quite a lot
of places from doing a search and then a subsequent insert to first
hash the key, and then use this hash when searching / inserting.
While our new pointer hashing function remedied much of our overhead
hashing pointers, there is still more to gain here. This cuts executed
instructions / task-clock by about 0.5% on a shader-db run on my i965
running machine. While that's not a lot, it is still a nice little 
improvement on the way to less overhead. The changes should also be
fairly trivial, so it's not much of a burden.

Thomas Helland (6):
  glsl: Prehash in refcount hash table to reduce hashing
  nir: Prehash in instr_set to avoid hashing twice
  glsl: Prehash in constant propagation
  glsl: Prehash in constant variable pass to avoid hashing twice
  glsl: Prehash to avoid computing the hash twice
  util: Avoid computing hash twice in string_to_uint_map

 src/compiler/glsl/ir_variable_refcount.cpp  | 7 +--
 src/compiler/glsl/opt_constant_propagation.cpp  | 8 +---
 src/compiler/glsl/opt_constant_variable.cpp | 6 --
 src/compiler/glsl/opt_copy_propagation_elements.cpp | 7 +--
 src/compiler/nir/nir_instr_set.c| 7 +--
 src/util/string_to_uint_map.h   | 9 ++---
 6 files changed, 30 insertions(+), 14 deletions(-)

-- 
2.13.0

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

[Mesa-dev] [PATCH 1/6] glsl: Prehash in refcount hash table to reduce hashing

[Thomas Helland]

_mesa_hash_table_search is one of our hottest function according to perf.
Callgrind shows the refcounting as one of the major users of the
searching functions. We can reduce the pain by prehashing, so that we
avoid hashing two times when inserting in the table.

On a short shader-db run (with validation disabled) it makes
1.2 million of 4.5 million calls to _hash_table_insert come from
the pre-hashed path.
---
 src/compiler/glsl/ir_variable_refcount.cpp | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ir_variable_refcount.cpp 
b/src/compiler/glsl/ir_variable_refcount.cpp
index 8306be10b9..bbb4c0ddd7 100644
--- a/src/compiler/glsl/ir_variable_refcount.cpp
+++ b/src/compiler/glsl/ir_variable_refcount.cpp
@@ -79,13 +79,16 @@ 
ir_variable_refcount_visitor::get_variable_entry(ir_variable *var)
 {
assert(var);
 
-   struct hash_entry *e = _mesa_hash_table_search(this->ht, var);
+   uint32_t hash = this->ht->key_hash_function(var);
+
+   struct hash_entry *e =
+  _mesa_hash_table_search_pre_hashed(this->ht, hash, var);
if (e)
   return (ir_variable_refcount_entry *)e->data;
 
ir_variable_refcount_entry *entry = new ir_variable_refcount_entry(var);
assert(entry->referenced_count == 0);
-   _mesa_hash_table_insert(this->ht, var, entry);
+   _mesa_hash_table_insert_pre_hashed(this->ht, hash, var, entry);
 
return entry;
 }
-- 
2.13.0

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

[Mesa-dev] [PATCH 4/6] glsl: Prehash in constant var pass to avoid hashing twice

[Thomas Helland]

Should help us reduce some hash table overhead.

V2: Fix whitespace error
---
 src/compiler/glsl/opt_constant_variable.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/opt_constant_variable.cpp 
b/src/compiler/glsl/opt_constant_variable.cpp
index 1c06ffe675..430bf194a1 100644
--- a/src/compiler/glsl/opt_constant_variable.cpp
+++ b/src/compiler/glsl/opt_constant_variable.cpp
@@ -62,7 +62,9 @@ public:
 static struct assignment_entry *
 get_assignment_entry(ir_variable *var, struct hash_table *ht)
 {
-   struct hash_entry *hte = _mesa_hash_table_search(ht, var);
+   uint32_t hash = ht->key_hash_function(var);
+   struct hash_entry *hte =
+ _mesa_hash_table_search_pre_hashed(ht, hash, var);
struct assignment_entry *entry;
 
if (hte) {
@@ -70,7 +72,7 @@ get_assignment_entry(ir_variable *var, struct hash_table *ht)
} else {
   entry = (struct assignment_entry *) calloc(1, sizeof(*entry));
   entry->var = var;
-  _mesa_hash_table_insert(ht, var, entry);
+  _mesa_hash_table_insert_pre_hashed(ht, hash, var, entry);
}
 
return entry;
-- 
2.13.0

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

[Mesa-dev] [PATCH 5/6] glsl: Prehash to avoid computing the hash twice

[Thomas Helland]

Copy propagation elements is a large user of the hash table.
We should not be computing the hash twice when we don't have to.
---
 src/compiler/glsl/opt_copy_propagation_elements.cpp | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index 9f79fa9202..d318417f6c 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -498,8 +498,11 @@ ir_copy_propagation_elements_visitor::visit_enter(ir_loop 
*ir)
 void
 ir_copy_propagation_elements_visitor::kill(kill_entry *k)
 {
+   uint32_t hash = lhs_ht->key_hash_function(k->var);
/* removal of lhs entries */
-   hash_entry *ht_entry = _mesa_hash_table_search(lhs_ht, k->var);
+   hash_entry *ht_entry =
+ _mesa_hash_table_search_pre_hashed(lhs_ht, hash, k->var);
+
if (ht_entry) {
   exec_list *lhs_list = (exec_list *) ht_entry->data;
   foreach_in_list_safe(acp_entry, entry, lhs_list) {
@@ -512,7 +515,7 @@ ir_copy_propagation_elements_visitor::kill(kill_entry *k)
}
 
/* removal of rhs entries */
-   ht_entry = _mesa_hash_table_search(rhs_ht, k->var);
+   ht_entry = _mesa_hash_table_search_pre_hashed(rhs_ht, hash, k->var);
if (ht_entry) {
   exec_list *rhs_list = (exec_list *) ht_entry->data;
   acp_ref *ref;
-- 
2.13.0

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

Re: [Mesa-dev] [PATCH] u_format_test: Ignore S3TC errors.

[Roland Scheidegger]

Reviewed-by: Roland Scheidegger 
Thanks!

Am 22.05.2017 um 19:06 schrieb Jose Fonseca:
> This prevents spurious failures when libtxc-dxtn-s2tc is installed.
> 
> Note: lp_test_format does need any change since we were already ignoring
> S3TC failures there.
> ---
>  src/gallium/tests/unit/u_format_test.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/src/gallium/tests/unit/u_format_test.c 
> b/src/gallium/tests/unit/u_format_test.c
> index 3145d13616..69d6c7dd3a 100644
> --- a/src/gallium/tests/unit/u_format_test.c
> +++ b/src/gallium/tests/unit/u_format_test.c
> @@ -220,6 +220,11 @@ test_format_fetch_rgba_float(const struct 
> util_format_description *format_desc,
>}
> }
>  
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, " 
> obtained\n");
>print_unpacked_rgba_doubl(format_desc, "", test->unpacked, " 
> expected\n");
> @@ -252,6 +257,11 @@ test_format_unpack_rgba_float(const struct 
> util_format_description *format_desc,
>}
> }
>  
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, " 
> obtained\n");
>print_unpacked_rgba_doubl(format_desc, "", test->unpacked, " 
> expected\n");
> @@ -302,6 +312,11 @@ test_format_pack_rgba_float(const struct 
> util_format_description *format_desc,
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>  
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_packed(format_desc, "FAILED: ", packed, " obtained\n");
>print_packed(format_desc, "", test->packed, " expected\n");
> @@ -365,6 +380,11 @@ test_format_unpack_rgba_8unorm(const struct 
> util_format_description *format_desc
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>  
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, " 
> obtained\n");
>print_unpacked_rgba_8unorm(format_desc, "", expected, " 
> expected\n");
> @@ -422,6 +442,11 @@ test_format_pack_rgba_8unorm(const struct 
> util_format_description *format_desc,
> if ((test->unpacked[0][0][0] * 255.0) != (int)(test->unpacked[0][0][0] * 
> 255.0))
>success = TRUE;
>  
> +   /* Ignore S3TC errors */
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> +  success = TRUE;
> +   }
> +
> if (!success) {
>print_packed(format_desc, "FAILED: ", packed, " obtained\n");
>print_packed(format_desc, "", test->packed, " expected\n");
> 

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

Re: [Mesa-dev] Mesa 17.1.1 release candidate

[Chuck Atkins]

>
> The candidate for the Mesa 17.1.1 is now available.


Excellent!


>From build perspective - SWR now ships it's final generated header, thus
> Python/mako is no longer required.
>

Just what I was looking for, thanks!

Is a source tarball available that I can test the build with? I would just
use the git tag but building from the source tarbal was the problem I
encountered in the first place.

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

Re: [Mesa-dev] [PATCH 06/24] i965/cnl: Add gen10 specific function declarations

[Anuj Phogat]

On Mon, May 22, 2017 at 10:07 AM, Rafael Antognolli
 wrote:
> On Fri, May 12, 2017 at 04:38:10PM -0700, Anuj Phogat wrote:
>> These declarations will help the code start compiling
>> once we wire up the makefiles for gen10. Later patches
>> will start using these functions for gen10.
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/isl/isl_priv.h  | 12 
>>  src/mesa/drivers/dri/i965/brw_blorp.h |  2 ++
>>  src/mesa/drivers/dri/i965/brw_state.h |  1 +
>>  3 files changed, 15 insertions(+)
>>
>> diff --git a/src/intel/isl/isl_priv.h b/src/intel/isl/isl_priv.h
>> index 3c4cc1e..04adefa 100644
>> --- a/src/intel/isl/isl_priv.h
>> +++ b/src/intel/isl/isl_priv.h
>> @@ -178,6 +178,10 @@ isl_gen9_surf_fill_state_s(const struct isl_device 
>> *dev, void *state,
>> const struct isl_surf_fill_state_info *restrict 
>> info);
>>
>>  void
>> +isl_gen10_surf_fill_state_s(const struct isl_device *dev, void *state,
>> +const struct isl_surf_fill_state_info *restrict 
>> info);
>> +
>> +void
>>  isl_gen4_buffer_fill_state_s(void *state,
>>   const struct isl_buffer_fill_state_info 
>> *restrict info);
>>
>> @@ -206,6 +210,10 @@ isl_gen9_buffer_fill_state_s(void *state,
>>   const struct isl_buffer_fill_state_info 
>> *restrict info);
>>
>>  void
>> +isl_gen10_buffer_fill_state_s(void *state,
>> +  const struct isl_buffer_fill_state_info 
>> *restrict info);
>> +
>> +void
>>  isl_gen4_emit_depth_stencil_hiz_s(const struct isl_device *dev, void *batch,
>>const struct 
>> isl_depth_stencil_hiz_emit_info *restrict info);
>>
>> @@ -233,4 +241,8 @@ void
>>  isl_gen9_emit_depth_stencil_hiz_s(const struct isl_device *dev, void *batch,
>>const struct 
>> isl_depth_stencil_hiz_emit_info *restrict info);
>>
>> +void
>> +isl_gen10_emit_depth_stencil_hiz_s(const struct isl_device *dev, void 
>> *batch,
>> +   const struct 
>> isl_depth_stencil_hiz_emit_info *restrict info);
>> +
>>  #endif /* ISL_PRIV_H */
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
>> b/src/mesa/drivers/dri/i965/brw_blorp.h
>> index ee4bf3b..d635d79 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.h
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.h
>> @@ -82,6 +82,8 @@ void gen8_blorp_exec(struct blorp_batch *batch,
>>   const struct blorp_params *params);
>>  void gen9_blorp_exec(struct blorp_batch *batch,
>>   const struct blorp_params *params);
>> +void gen10_blorp_exec(struct blorp_batch *batch,
>> +  const struct blorp_params *params);
>>
>>  #ifdef __cplusplus
>>  } /* extern "C" */
>> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
>> b/src/mesa/drivers/dri/i965/brw_state.h
>> index 4727e2a..4592e3e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_state.h
>> +++ b/src/mesa/drivers/dri/i965/brw_state.h
>> @@ -364,6 +364,7 @@ void gen7_init_atoms(struct brw_context *brw);
>>  void gen75_init_atoms(struct brw_context *brw);
>>  void gen8_init_atoms(struct brw_context *brw);
>>  void gen9_init_atoms(struct brw_context *brw);
>> +void gen10_init_atoms(struct brw_context *brw);
>
> I couldn't find it in the other patches, so pardon me if you did it. But you
> should also use the gen10_init_atoms inside brw_init_state() -
> brw_state_upload.c.
>
It is in  [PATCH V2 14/24] i965/cnl: Handle gen10 in switch cases
across the driver
>>  void upload_gs_state_for_tf(struct brw_context *brw);
>>
>> --
>> 2.9.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/13] egl: gbm: Misc cleanups and robustness patches

[Rob Herring]

On Thu, May 11, 2017 at 1:57 PM, Emil Velikov  wrote:
> Hi all,
>
> I was around the EGL/GBM codebase and I've noticed that we do a few
> things, rather badly:
>  - we have unnessesary layer of abstraction in GBM like the following
> gbm_dri_foo -> gbm_drm_foo -> gbm_foo
>  - the teardown path of platform_foo initialize is in bad shape
> Destroying someone else's dri screen, leaks etc.
>  - gbm copies a bunch of EGL's extension management
> Every so often we have to add DRI extension foo to GBM to align with
> EGL.
>
> The lot can be found in branch 'egl-gbm-less-copy' at
> https://github.com/evelikov/Mesa
>
> I've gone through the DRM/GBM, wayland and X11 platforms - both hardware
> and swrast based.
>
> Extra testong on different platforms will still be appreciated.

With the 1 goto I pointed out fixed,

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

Re: [Mesa-dev] How does FakeGLX work since Mesa 10?

[Brian Paul]

On 05/09/2017 12:07 PM, Tom Hudson wrote:

I'm trying to upgrade a Mesa 10 installation to Mesa 17. There have been
plenty of changes, but only one breakage that's left me perplexed.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=c00b250c8061d042d9905e61b9077462ee91008b

In this CL, Mesa stopped maintaining a __GLXcontext for FakeGLX; there's
just an XMesaContext.

Fake_glXGetCurrentContext() casts the XMesaContext to a __GLXContext and
returns it. Perhaps the reasonable assumption is that a context is an
opaque object.

However, glXGetCurrentDisplay() doesn't respect that assumption; it
assumes it is getting a valid __GLXContext and returns
__GLXContext::currentDpy, the first pointer.

The first pointer in an XMesaContext is *not* a pointer to a Display,
and so any code that relies on this code path seems doomed to
disappointment.

This is hitting us in open-source projects based on Ogre, but seems like
a breakage in the public API that other users would have run into in the
3 years since that commit?

Is this really a bug (which presumably I should file), or am I missing
something?
Does anyone have suggestions for working around it?


Hi Tom,

I just updated the bug report with a proposed patch.

Sorry for the breakage.  I think it happened a long time ago and it 
looks like you're the first to notice.


-Brian


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

Re: [Mesa-dev] [PATCH 11/13] egl: refactor dri2_create_screen() into three separate functions

[Rob Herring]

On Thu, May 11, 2017 at 1:57 PM, Emil Velikov  wrote:
> Split the create_screen into:
>  - create screen
>  - setup/bind extensions
>  - setup screen
>
> This will allow us to reuse the latter two on egl/drm. Said platform
> does create its own screen and attempts to reinvent the later two
> functions itself.
>
> Since the GBM ones tend to get out of sync quite often, and there is no
> distinct reason why it does so we'll drop them with latter commits.
>
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 37 
> ++---
>  src/egl/drivers/dri2/egl_dri2.h |  3 +++
>  src/egl/drivers/dri2/platform_android.c |  5 
>  src/egl/drivers/dri2/platform_surfaceless.c |  7 ++
>  src/egl/drivers/dri2/platform_wayland.c | 10 
>  src/egl/drivers/dri2/platform_x11.c | 15 
>  6 files changed, 58 insertions(+), 19 deletions(-)

[...]

> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index f1038957850..4c134e1460d 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1148,6 +1148,11 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> *dpy)
>goto cleanup;
> }
>
> +   if (!dri2_setup_extensions(dpy))
> +  goto cleanup_screen;

There's no such goto.

> +
> +   dri2_setup_screen(disp);
> +
> if (!droid_add_configs_for_visuals(drv, dpy)) {
>err = "DRI2: failed to add configs";
>goto cleanup;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9][RFC] GLSL preprocessor/parser improvements

[Thomas Helland]

2017-05-22 3:41 GMT+02:00 Timothy Arceri :
> I suspect you forgot to test with a debug build, there is issues with the
> string buffer  changes somewhere.
>
> ralloc.c:203: reralloc_size: Assertion `ralloc_parent(ptr) == ctx' failed.
>
> #0  0x770eb91f in raise () from /lib64/libc.so.6
> #1  0x770ed51a in abort () from /lib64/libc.so.6
> #2  0x770e3da7 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x770e3e52 in __assert_fail () from /lib64/libc.so.6
> #4  0x7442c73c in reralloc_size (ctx=ctx@entry=0x7fffd40cb910,
> ptr=, size=) at ralloc.c:203
> #5  0x744b519e in glcpp_preprocess
> (ralloc_ctx=ralloc_ctx@entry=0x7fffd40c9da0,
> shader=shader@entry=0x7fffea7cfcc8, info_log=info_log@entry=0x7fffd40ca058,
> extensions=extensions@entry=0x743ff070
>  const*, int), glcpp_parser*, unsigned int, bool)>,
> state=state@entry=0x7fffd40c9da0,
> gl_ctx=gl_ctx@entry=0x7fffe85c7010) at glsl/glcpp/pp.c:246
> #6  0x74402665 in _mesa_glsl_compile_shader
> (ctx=ctx@entry=0x7fffe85c7010, shader=shader@entry=0x7fffd40c8cc0,
> dump_ast=dump_ast@entry=false, dump_hir=dump_hir@entry=false,
> force_recompile=force_recompile@entry=false)
> at glsl/glsl_parser_extras.cpp:2065
>
>

Your suspicion is of course correct. Switching back and forth between
profiling and coding and I forgot to switch debug back on. I'll look into
this, plus addressing all of the nice feedback. Thanks for taking a look.

>
> On 22/05/17 06:49, Thomas Helland wrote:
>>
>> This patch series contains some of the work done by Vladislav
>> in the beginning of March, that seems to have been forgotten.
>>
>> For reference, that series, with review comments, can be found here:
>> https://lists.freedesktop.org/archives/mesa-dev/2017-January/139892.html
>>
>> I've adressed some of the review comments, most notably redoing the
>> string buffer implementation quite a bit, and adding tests.
>> The major change is that it is now decoupled from the parser
>> and instead lives in /src/util/ as a utility for easier reuse.
>> I've also closely followed the structure of our hash table and set
>> so that it should be quite familiar for everyone. My implementation
>> is also null terminated, while Vladislav's implementation was not.
>> My reasoning behind this was that it's less fragile if someone where
>> to access the contents of the buffer directly. I've also expanded
>> with some different functions that allow us to do more stuff.
>> Obviously this could be expanded upon further if need be.
>>
>> I've included some of Vladislav's less involved patches that
>> I think we should get in as soon as possible. I've added Ian's
>> r-b on the ones that he reviewed (I hope that's OK). The one
>> patch that is missing from this series is the hand-written
>> custom parser. While this was the thing that gave the biggest
>> speed-up, unfortunately it's also a bit harder to review,
>> so I've left that as a future exercise.
>>
>> I've run it through my complete shader-db and there's no changes
>> or breakages, so that's encouraging. It amounts to about a 3%
>> reduction in runtime and executed instructions on the shader-db run.
>> It should be noted that the i965 backend is the primary bottleneck
>> when running shader-db on my computer, so the numbers don't look all
>> that impressive due to this. I'll see if I can come up with some
>> numbers using the gallium noop driver.
>>
>> I have not done a very thorough job on testing that the output
>> of the preprocessor/parser is the same after this series.
>> However, there's no changes here that I believe should cause
>> any issues, so I feel quite confident that this series should
>> not cause any trouble. The original series did have some issues
>> discovered by running a fuzzer over it, however I expect that
>> was caused by the introduced hand-written fast-path scanner and
>> associated macro substitutaion that are not a part of this series.
>>
>> CC: Vladislav Egorov 
>> CC: Ian Romanick 
>>
>> Thomas Helland (5):
>>util: Add a string buffer implementation
>>util: Add tests for the string buffer
>>glsl: Change the parser to use the string buffer
>>glcpp: Use string_buffer for line continuation removal
>>glcpp: Avoid unnecessary call to strlen
>>
>> Vladislav Egorov (4):
>>glcpp: Avoid unnecessary strcmp()
>>glcpp: Skip unnecessary line continuations removal
>>ralloc: Use strnlen() inside of strncat()
>>glcpp: Use Bloom filter before identifier search
>>
>>   configure.ac|   1 +
>>   src/compiler/glsl/glcpp/glcpp-lex.l |   3 +-
>>   src/compiler/glsl/glcpp/glcpp-parse.y   | 123 +---
>>   src/compiler/glsl/glcpp/glcpp.h |  18 ++-
>>   src/compiler/glsl/glcpp/pp.c|  73 ++
>>  

[Mesa-dev] [Bug 100988] glXGetCurrentDisplay() no longer works for FakeGLX contexts?

[bugzilla-daemon]

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

Brian Paul  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |bri...@vmware.com
   |org |

--- Comment #1 from Brian Paul  ---
Created attachment 131440
  --> https://bugs.freedesktop.org/attachment.cgi?id=131440=edit
Fix for glxGetCurrentDisplay()

Hi Tom,

Looks like this has been broken for a long time.  Can you try the attached
patch?

I hacked glxgears.c to call glXGetCurrentDisplay() and it seemed to work, but
it would be great if you could check too.

Thanks.  Sorry for the slow reply.  I was out for a couple weeks.

-- 
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 1/3] etnaviv: Add support for extended texture formats

[Lucas Stach]

Am Dienstag, den 16.05.2017, 21:31 +0200 schrieb Christian Gmeiner:
> Hi Wladimir.
> 
> I started working on this topic last week and thought some time on how
> to add those ext texture formats in a clean and nice way. I come up
> with this patches:
> 
> https://github.com/austriancoder/mesa/commit/1fac9dd179976dce3d991bb0715707021c093f1a.patch
> https://github.com/austriancoder/mesa/commit/f408fc40a028fa00e87900e6fd4cce65ee6640c2.patch
> 
> IMO it is a simpler implementation as I do not need two variants of
> macros (base and extended) and there is no need for
> translate_texture_format_ext(..).
> What is your opinion about it?

This looks much cleaner. I like it!

Just a heads up if you haven't noticed: the first patch is broken, as
sv->base isn't initialized yet at the point where the format is
converted. I had to apply the following diff to make it work:

>8
-   const uint32_t format = translate_texture_format(sv->base.format);
+   const uint32_t format = translate_texture_format(so->format);
8<

Regards,
Lucas

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

Re: [Mesa-dev] [PATCH v3 01/15] st/dri: refactor multi-planar YUV import path

[Lucas Stach]

Am Mittwoch, den 10.05.2017, 23:15 +0530 schrieb Varad Gautam:
> From: Varad Gautam 
> 
> we currently ignore the plane count when converting from
> __DRI_IMAGE_FORMAT* tokens to __DRI_IMAGE_FOURCC* for multiplanar
> images, and only return the first plane's simplified fourcc.
> 
> this adds a fourcc to __DRI_IMAGE_FORMAT_* mapping to dri, allowing
> us to return the correct fourcc format from DRIimage queries, and
> simplifies the multiplane import logic.
> 
> Signed-off-by: Varad Gautam 
> ---
>  src/gallium/state_trackers/dri/dri2.c   | 288 
> +++-
>  src/gallium/state_trackers/dri/dri_screen.h |  13 ++
>  2 files changed, 168 insertions(+), 133 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index ed6004f..0c5783c 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -52,93 +52,133 @@
>  #include "dri_query_renderer.h"
>  #include "dri2_buffer.h"
>  
> -static int convert_fourcc(int format, int *dri_components_p)
> +/* format list taken from intel_screen.c */
> +static struct image_format image_formats[] = {
> +   { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_ABGR, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ABGR, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> +
> +   { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_XBGR, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_XBGR, 4 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_ARGB1555, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB1555, 2 } } },
> +
> +   { __DRI_IMAGE_FOURCC_RGB565, __DRI_IMAGE_COMPONENTS_RGB, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_RGB565, 2 } } },
> +
> +   { __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_R16, __DRI_IMAGE_COMPONENTS_R, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R16, 1 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_GR88, __DRI_IMAGE_COMPONENTS_RG, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR88, 2 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_GR1616, __DRI_IMAGE_COMPONENTS_RG, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_GR1616, 2 }, } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YUV444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU411, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 2, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU420, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU422, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_YVU444, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 2, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 } } },
> +
> +   { __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
> +   { 1, 1, 1, 

Re: [Mesa-dev] [PATCH 2/7] egl/x11: check for dri2_dpy->flush before using the flush extension

[Emil Velikov]

On 16 May 2017 at 18:32, Chad Versace  wrote:
> On Mon 15 May 2017, Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Analogous to previous commit.
>>
>> Signed-off-by: Emil Velikov 
>> ---
>
>> If people prefer I can split the whitespace/indent changes in
>> this/previous path from the rest. Don't feel too strongly either way.
>
> I do think the patches would be easier to review if you did that. As
> written, it's difficult to see what's behavioral change vs cosmetic
> cleanups.
>
Ack, I will be less for the future.

>>
>>  src/egl/drivers/dri2/platform_x11.c | 22 +-
>>  1 file changed, 9 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/platform_x11.c 
>> b/src/egl/drivers/dri2/platform_x11.c
>> index 3bce0bb3f21..becf00547e6 100644
>> --- a/src/egl/drivers/dri2/platform_x11.c
>> +++ b/src/egl/drivers/dri2/platform_x11.c
>> @@ -817,8 +817,7 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay *disp,
>> if (draw->Type == EGL_PIXMAP_BIT || draw->Type == EGL_PBUFFER_BIT)
>>return EGL_TRUE;
>>
>> -   if (dri2_dpy->flush)
>> -  dri2_dpy->flush->flush(dri2_surf->dri_drawable);
>> +   dri2_dpy->flush->flush(dri2_surf->dri_drawable);
>>
>> if (dri2_surf->have_fake_front)
>>render_attachment = XCB_DRI2_ATTACHMENT_BUFFER_FAKE_FRONT_LEFT;
>> @@ -880,8 +879,7 @@ dri2_x11_swap_buffers_msc(_EGLDriver *drv, _EGLDisplay 
>> *disp, _EGLSurface *draw,
>>  * happened.  The driver should still be using the viewport hack to catch
>>  * window resizes.
>>  */
>> -   if (dri2_dpy->flush &&
>> -   dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
>> +   if (dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
>>dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
>>
>> return swap_count;
>> @@ -893,19 +891,17 @@ dri2_x11_swap_buffers(_EGLDriver *drv, _EGLDisplay 
>> *disp, _EGLSurface *draw)
>> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
>>
>> -   if (dri2_dpy->dri2) {
>> -  if (dri2_x11_swap_buffers_msc(drv, disp, draw, 0, 0, 0) != -1) {
>> -  return EGL_TRUE;
>> -  }
>> +   if (!dri2_dpy->flush) {
>> +  dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
>> +  return EGL_TRUE;
>
> Yes, thank you.
>
> I'll say it again to anyone who's reading. The Go style guide insists on
> this, for good reason.
>
> https://github.com/golang/go/wiki/CodeReviewComments#indent-error-flow
>
> Try to keep the normal code path at a minimal indentation, and indent
> the error handling, dealing with it first. This improves the readability
> of the code by permitting visually scanning the normal path quickly.
>
>> +   }
>> +
>> +   if (dri2_x11_swap_buffers_msc(drv, disp, draw, 0, 0, 0) == -1) {
>>/* Swap failed with a window drawable. */
>>_eglError(EGL_BAD_NATIVE_WINDOW, __func__);
>>return EGL_FALSE;
>> -   } else {
>> -  assert(dri2_dpy->swrast);
>> -
>> -  dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
>> -  return EGL_TRUE;
>> }
>> +   return EGL_TRUE;
>>  }
>
> There's a lot of hidden complexity in platform_x11.c, and I'm unsure if
> this patch preserves proper extension checks. I defer to someone who
> knows this code better.

Just sent out updated/split patches adding a bit of description about these.

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

[Mesa-dev] [PATCH 2/7] egl/x11: check for dri2_dpy->flush before using the flush extension

[Emil Velikov]

From: Emil Velikov 

Analogous to earlier commit.

Note that the dri2_x11_post_sub_buffer and dri2_x11_swap_buffers_region
paths already implicitly require __DRI2_FLUSH. The corresponding
extensions (NV_post_sub_buffer and NOK_swap_region) are enabled only
with DRI2.

v2: Split cosmetic changes into separate patch.

Signed-off-by: Emil Velikov 
---
Do we want to keep the old extensions? They seems to be implemented 
only for EGL/X11 and a quick search shows a) one piglit test for the 
latter and b) no binaries that use either one on my workstation.

Afaict most of their functionality can be considered obsolete with
EXT_swap_buffers_with_damage, EXT_buffer_age and KHR_partial_update?
---
 src/egl/drivers/dri2/platform_x11.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 3bce0bb3f21..7ca2611b110 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -817,8 +817,7 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay *disp,
if (draw->Type == EGL_PIXMAP_BIT || draw->Type == EGL_PBUFFER_BIT)
   return EGL_TRUE;
 
-   if (dri2_dpy->flush)
-  dri2_dpy->flush->flush(dri2_surf->dri_drawable);
+   dri2_dpy->flush->flush(dri2_surf->dri_drawable);
 
if (dri2_surf->have_fake_front)
   render_attachment = XCB_DRI2_ATTACHMENT_BUFFER_FAKE_FRONT_LEFT;
@@ -880,8 +879,7 @@ dri2_x11_swap_buffers_msc(_EGLDriver *drv, _EGLDisplay 
*disp, _EGLSurface *draw,
 * happened.  The driver should still be using the viewport hack to catch
 * window resizes.
 */
-   if (dri2_dpy->flush &&
-   dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
+   if (dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
   dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
 
return swap_count;
@@ -893,7 +891,7 @@ dri2_x11_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
 
-   if (dri2_dpy->dri2) {
+   if (dri2_dpy->flush) {
   if (dri2_x11_swap_buffers_msc(drv, disp, draw, 0, 0, 0) != -1) {
   return EGL_TRUE;
   }
-- 
2.12.2

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

[Mesa-dev] [PATCH 1.5/7] egl/drm: flatten codeflow

[Emil Velikov]

From: Emil Velikov 

Rework the code to return early and drop an indentation level.
No functional change, yet it should be easier to read.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 39 +++--
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index e349264f91e..75ff5f9891d 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -428,30 +428,31 @@ dri2_drm_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
 
if (!dri2_dpy->flush) {
   dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
-   } else {
-  if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
- if (dri2_surf->current)
-_eglError(EGL_BAD_SURFACE, "dri2_swap_buffers");
- for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
-if (dri2_surf->color_buffers[i].age > 0)
-   dri2_surf->color_buffers[i].age++;
-
- /* Make sure we have a back buffer in case we're swapping without
-  * ever rendering. */
- if (get_back_bo(dri2_surf) < 0) {
-_eglError(EGL_BAD_ALLOC, "dri2_swap_buffers");
-return EGL_FALSE;
- }
+  return EGL_TRUE;
+   }
 
- dri2_surf->current = dri2_surf->back;
- dri2_surf->current->age = 1;
- dri2_surf->back = NULL;
+   if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
+  if (dri2_surf->current)
+ _eglError(EGL_BAD_SURFACE, "dri2_swap_buffers");
+  for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
+ if (dri2_surf->color_buffers[i].age > 0)
+dri2_surf->color_buffers[i].age++;
+
+  /* Make sure we have a back buffer in case we're swapping without
+   * ever rendering. */
+  if (get_back_bo(dri2_surf) < 0) {
+ _eglError(EGL_BAD_ALLOC, "dri2_swap_buffers");
+ return EGL_FALSE;
   }
 
-  dri2_flush_drawable_for_swapbuffers(disp, draw);
-  dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
+  dri2_surf->current = dri2_surf->back;
+  dri2_surf->current->age = 1;
+  dri2_surf->back = NULL;
}
 
+   dri2_flush_drawable_for_swapbuffers(disp, draw);
+   dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
+
return EGL_TRUE;
 }
 
-- 
2.12.2

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

[Mesa-dev] [PATCH 3.5/7] egl/x11: flatten codeflow

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_x11.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 7ca2611b110..becf00547e6 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -891,19 +891,17 @@ dri2_x11_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
 
-   if (dri2_dpy->flush) {
-  if (dri2_x11_swap_buffers_msc(drv, disp, draw, 0, 0, 0) != -1) {
-  return EGL_TRUE;
-  }
+   if (!dri2_dpy->flush) {
+  dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
+  return EGL_TRUE;
+   }
+
+   if (dri2_x11_swap_buffers_msc(drv, disp, draw, 0, 0, 0) == -1) {
   /* Swap failed with a window drawable. */
   _eglError(EGL_BAD_NATIVE_WINDOW, __func__);
   return EGL_FALSE;
-   } else {
-  assert(dri2_dpy->swrast);
-
-  dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
-  return EGL_TRUE;
}
+   return EGL_TRUE;
 }
 
 static EGLBoolean
-- 
2.12.2

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

[Mesa-dev] [PATCH 1/7] egl/drm: check for dri2_dpy->flush before using the flush extension

[Emil Velikov]

From: Emil Velikov 

The current __DRI_DRI2 imples __DRI2_FLUSH. At the same time, one can
use __DRI_IMAGE_DRIVER alongside the latter, so the current check is
confusing at best.

Check for what we use.

v2: Split out from whitespace changes

Reviewed-by: Chad Versace  (v1)
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 9431d95e0a7..e349264f91e 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -426,7 +426,7 @@ dri2_drm_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
unsigned i;
 
-   if (dri2_dpy->swrast) {
+   if (!dri2_dpy->flush) {
   dri2_dpy->core->swapBuffers(dri2_surf->dri_drawable);
} else {
   if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH v2] drirc: Add allow_glsl_builtin_variable_redeclaration for Dead Island Riptide Definitive Edition

[Marek Olšák]

Pushed, thanks.

Marek

On Sun, May 21, 2017 at 11:46 PM, Benedikt Schemmer  wrote:
> From: Benedikt Schemmer 
>
> This patch sets the allow_glsl_builtin_variable_redeclaration for Dead
> Island Riptide Definitive Edition.
>
> Tested with Mesa git as of today and Dying Light, Dead Island Definitive
> Edition and Dead Island Riptide Definite Edition
>
> v2: set only required option and match option name
>
> Please kindly review and push.
>
> Thanks,
> Benedikt
>
> ---
>  src/mesa/drivers/dri/common/drirc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/drirc
> b/src/mesa/drivers/dri/common/drirc
> index 8093e8e42a..d820462fad 100644
> --- a/src/mesa/drivers/dri/common/drirc
> +++ b/src/mesa/drivers/dri/common/drirc
> @@ -92,6 +92,10 @@ TODO: document the other workarounds.
>   value="true" />
>  
>
> + executable="DeadIslandRiptideGame">
> + value="true" />
> +
> +
>  
>   value="true" />
>  
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/9] util: Add tests for the string buffer

[Ian Romanick]

New tests should use gtest.  Other tests can't be made to produce XML
output that can be processed by Jenkins.

On 05/21/2017 01:49 PM, Thomas Helland wrote:
> More tests could probably be added, but this should cover
> concatenation, resizing, clearing, formatted printing,
> and checking the length, so it should be quite complete.
> ---
>  configure.ac|  1 +
>  src/util/Makefile.am|  3 +-
>  src/util/tests/string_buffer/Makefile.am| 34 ++
>  src/util/tests/string_buffer/append_and_print.c | 82 
> +
>  4 files changed, 119 insertions(+), 1 deletion(-)
>  create mode 100644 src/util/tests/string_buffer/Makefile.am
>  create mode 100644 src/util/tests/string_buffer/append_and_print.c
> 
> diff --git a/configure.ac b/configure.ac
> index 06883a9667..0d44d99e76 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2833,6 +2833,7 @@ AC_CONFIG_FILES([Makefile
>   src/mesa/main/tests/Makefile
>   src/util/Makefile
>   src/util/tests/hash_table/Makefile
> + src/util/tests/string_buffer/Makefile
>   src/vulkan/Makefile])
>  
>  AC_OUTPUT
> diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> index f094eb4a0d..c730fb48d3 100644
> --- a/src/util/Makefile.am
> +++ b/src/util/Makefile.am
> @@ -19,7 +19,8 @@
>  # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
>  # IN THE SOFTWARE.
>  
> -SUBDIRS = . tests/hash_table
> +SUBDIRS = . tests/hash_table \
> +  . tests/string_buffer
>  
>  include Makefile.sources
>  
> diff --git a/src/util/tests/string_buffer/Makefile.am 
> b/src/util/tests/string_buffer/Makefile.am
> new file mode 100644
> index 00..60039a90d2
> --- /dev/null
> +++ b/src/util/tests/string_buffer/Makefile.am
> @@ -0,0 +1,34 @@
> +# Copyright © 2009 Intel Corporation
> +#
> +#  Permission is hereby granted, free of charge, to any person obtaining a
> +#  copy of this software and associated documentation files (the "Software"),
> +#  to deal in the Software without restriction, including without limitation
> +#  on the rights to use, copy, modify, merge, publish, distribute, sub
> +#  license, and/or sell copies of the Software, and to permit persons to whom
> +#  the Software is furnished to do so, subject to the following conditions:
> +#
> +#  The above copyright notice and this permission notice (including the next
> +#  paragraph) shall be included in all copies or substantial portions of the
> +#  Software.
> +#
> +#  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +#  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +#  FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
> +#  ADAM JACKSON BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
> +#  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> +#  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> +
> +AM_CPPFLAGS = \
> + -I$(top_srcdir)/include \
> + -I$(top_srcdir)/src/util \
> + $(DEFINES)
> +
> +LDADD = \
> + $(top_builddir)/src/util/libmesautil.la \
> + $(PTHREAD_LIBS) \
> + $(DLOPEN_LIBS)
> +
> +TESTS = append_and_print \
> + $()
> +
> +check_PROGRAMS = $(TESTS)
> diff --git a/src/util/tests/string_buffer/append_and_print.c 
> b/src/util/tests/string_buffer/append_and_print.c
> new file mode 100644
> index 00..bbc2727877
> --- /dev/null
> +++ b/src/util/tests/string_buffer/append_and_print.c
> @@ -0,0 +1,82 @@
> +/*
> + * Copyright © 2017 Thomas Helland
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "string_buffer.h"
> +
> +int
> +main(int argc, char **argv)
> +{
> +   (void) 

Re: [Mesa-dev] [PATCH] mesa: add APPLE_vertex_array_object stubs

[Ian Romanick]

WTF?  I gave review feedback on IRC, and you said you were going to send
a different patch... yet this patch landed.  If you're not going to take
review feedback, why do you ask for it?

On 05/18/2017 07:50 PM, Timothy Arceri wrote:
> APPLE_vertex_array_object support was removed in 7927d0378fc7.
> However it turns out we can't remove the functions because this
> can cause issues when libglapi is used together with DRI1 drivers
> which were branched off from master a few years ago.
> ---
>  src/mapi/glapi/gen/APPLE_vertex_array_object.xml | 27 
> 
>  src/mapi/glapi/gen/Makefile.am   |  1 +
>  src/mapi/glapi/gen/gl_API.xml|  2 +-
>  src/mapi/glapi/tests/check_table.cpp |  2 ++
>  src/mesa/main/arrayobj.c | 16 ++
>  src/mesa/main/arrayobj.h |  4 
>  src/mesa/main/tests/dispatch_sanity.cpp  |  2 ++
>  7 files changed, 53 insertions(+), 1 deletion(-)
>  create mode 100644 src/mapi/glapi/gen/APPLE_vertex_array_object.xml
> 
> diff --git a/src/mapi/glapi/gen/APPLE_vertex_array_object.xml 
> b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
> new file mode 100644
> index 000..7312f9b
> --- /dev/null
> +++ b/src/mapi/glapi/gen/APPLE_vertex_array_object.xml
> @@ -0,0 +1,27 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + 
> +
> +
> +
> +
> + 
> +
> +
> +
> +
> + 
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index ecd1c71..33139bd 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -182,20 +182,21 @@ API_XML = \
>   ARB_texture_view.xml \
>   ARB_uniform_buffer_object.xml \
>   ARB_vertex_array_object.xml \
>   ARB_vertex_attrib_64bit.xml \
>   ARB_vertex_attrib_binding.xml \
>   ARB_viewport_array.xml \
>   AMD_draw_buffers_blend.xml \
>   AMD_performance_monitor.xml \
>   ARB_vertex_type_2_10_10_10_rev.xml \
>   APPLE_object_purgeable.xml \
> + APPLE_vertex_array_object.xml \
>   EXT_draw_buffers2.xml \
>   EXT_framebuffer_object.xml \
>   EXT_gpu_shader4.xml \
>   EXT_packed_depth_stencil.xml \
>   EXT_provoking_vertex.xml \
>   EXT_separate_shader_objects.xml \
>   EXT_texture_array.xml \
>   EXT_texture_integer.xml \
>   EXT_transform_feedback.xml \
>   EXT_window_rectangles.xml \
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 762fb5a..630d6b8 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -12524,21 +12524,21 @@
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
> -
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> diff --git a/src/mapi/glapi/tests/check_table.cpp 
> b/src/mapi/glapi/tests/check_table.cpp
> index a1041bce..09bf4f3 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1397,21 +1397,23 @@ const struct name_offset known_dispatch[] = {
> { "glColorFragmentOp3ATI", _O(ColorFragmentOp3ATI) },
> { "glDeleteFragmentShaderATI", _O(DeleteFragmentShaderATI) },
> { "glEndFragmentShaderATI", _O(EndFragmentShaderATI) },
> { "glGenFragmentShadersATI", _O(GenFragmentShadersATI) },
> { "glPassTexCoordATI", _O(PassTexCoordATI) },
> { "glSampleMapATI", _O(SampleMapATI) },
> { "glSetFragmentShaderConstantATI", _O(SetFragmentShaderConstantATI) },
> { "glPointParameteri", _O(PointParameteri) },
> { "glPointParameteriv", _O(PointParameteriv) },
> { "glActiveStencilFaceEXT", _O(ActiveStencilFaceEXT) },
> +   { "glBindVertexArrayAPPLE", _O(BindVertexArrayAPPLE) },
> { "glDeleteVertexArrays", _O(DeleteVertexArrays) },
> +   { "glGenVertexArraysAPPLE", _O(GenVertexArraysAPPLE) },
> { "glIsVertexArray", _O(IsVertexArray) },
> { "glGetProgramNamedParameterdvNV", _O(GetProgramNamedParameterdvNV) },
> { "glGetProgramNamedParameterfvNV", _O(GetProgramNamedParameterfvNV) },
> { "glProgramNamedParameter4dNV", _O(ProgramNamedParameter4dNV) },
> { "glProgramNamedParameter4dvNV", _O(ProgramNamedParameter4dvNV) },
> { "glProgramNamedParameter4fNV", _O(ProgramNamedParameter4fNV) },
> { "glProgramNamedParameter4fvNV", _O(ProgramNamedParameter4fvNV) },
> { "glPrimitiveRestartIndex", _O(PrimitiveRestartIndex) },
> { "glPrimitiveRestartNV", _O(PrimitiveRestartNV) },
> { "glDepthBoundsEXT", _O(DepthBoundsEXT) },
> diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
> index 82c00fb..b986229 100644
> --- a/src/mesa/main/arrayobj.c
> +++ b/src/mesa/main/arrayobj.c
> @@ -466,20 +466,28 @@ _mesa_BindVertexArray( GLuint id )
> */
>ctx->Array._DrawArrays = NULL;
>

Re: [Mesa-dev] [PATCH 06/24] i965/cnl: Add gen10 specific function declarations

[Rafael Antognolli]

On Fri, May 12, 2017 at 04:38:10PM -0700, Anuj Phogat wrote:
> These declarations will help the code start compiling
> once we wire up the makefiles for gen10. Later patches
> will start using these functions for gen10.
> 
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/isl/isl_priv.h  | 12 
>  src/mesa/drivers/dri/i965/brw_blorp.h |  2 ++
>  src/mesa/drivers/dri/i965/brw_state.h |  1 +
>  3 files changed, 15 insertions(+)
> 
> diff --git a/src/intel/isl/isl_priv.h b/src/intel/isl/isl_priv.h
> index 3c4cc1e..04adefa 100644
> --- a/src/intel/isl/isl_priv.h
> +++ b/src/intel/isl/isl_priv.h
> @@ -178,6 +178,10 @@ isl_gen9_surf_fill_state_s(const struct isl_device *dev, 
> void *state,
> const struct isl_surf_fill_state_info *restrict 
> info);
>  
>  void
> +isl_gen10_surf_fill_state_s(const struct isl_device *dev, void *state,
> +const struct isl_surf_fill_state_info *restrict 
> info);
> +
> +void
>  isl_gen4_buffer_fill_state_s(void *state,
>   const struct isl_buffer_fill_state_info 
> *restrict info);
>  
> @@ -206,6 +210,10 @@ isl_gen9_buffer_fill_state_s(void *state,
>   const struct isl_buffer_fill_state_info 
> *restrict info);
>  
>  void
> +isl_gen10_buffer_fill_state_s(void *state,
> +  const struct isl_buffer_fill_state_info 
> *restrict info);
> +
> +void
>  isl_gen4_emit_depth_stencil_hiz_s(const struct isl_device *dev, void *batch,
>const struct 
> isl_depth_stencil_hiz_emit_info *restrict info);
>  
> @@ -233,4 +241,8 @@ void
>  isl_gen9_emit_depth_stencil_hiz_s(const struct isl_device *dev, void *batch,
>const struct 
> isl_depth_stencil_hiz_emit_info *restrict info);
>  
> +void
> +isl_gen10_emit_depth_stencil_hiz_s(const struct isl_device *dev, void *batch,
> +   const struct 
> isl_depth_stencil_hiz_emit_info *restrict info);
> +
>  #endif /* ISL_PRIV_H */
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
> b/src/mesa/drivers/dri/i965/brw_blorp.h
> index ee4bf3b..d635d79 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.h
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.h
> @@ -82,6 +82,8 @@ void gen8_blorp_exec(struct blorp_batch *batch,
>   const struct blorp_params *params);
>  void gen9_blorp_exec(struct blorp_batch *batch,
>   const struct blorp_params *params);
> +void gen10_blorp_exec(struct blorp_batch *batch,
> +  const struct blorp_params *params);
>  
>  #ifdef __cplusplus
>  } /* extern "C" */
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> b/src/mesa/drivers/dri/i965/brw_state.h
> index 4727e2a..4592e3e 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -364,6 +364,7 @@ void gen7_init_atoms(struct brw_context *brw);
>  void gen75_init_atoms(struct brw_context *brw);
>  void gen8_init_atoms(struct brw_context *brw);
>  void gen9_init_atoms(struct brw_context *brw);
> +void gen10_init_atoms(struct brw_context *brw);

I couldn't find it in the other patches, so pardon me if you did it. But you
should also use the gen10_init_atoms inside brw_init_state() -
brw_state_upload.c.

>  void upload_gs_state_for_tf(struct brw_context *brw);
>  
> -- 
> 2.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 29/65] tgsi: add new Bindless flag to tgsi_instruction_texture

[Marek Olšák]

On Fri, May 19, 2017 at 6:52 PM, Samuel Pitoiset
 wrote:
> Old-style images are identified using TGSI_FILE_SAMPLER, but
> bindless samplers can be TGSI_FILE_CONSTANT or TGSI_FILE_TEMPORARY.
>
> To avoid backend compilers to be confused, this adds a new flag
> that will only be set for bindless samplers.

Sorry, I don't understand it. Why is it necessary? It seems to me that
this is enough to tell whether the sampler is bindless: File !=
TGSI_FILE_SAMPLER && File != TGSI_FILE_IMAGE.

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

[Mesa-dev] [PATCH] u_format_test: Ignore S3TC errors.

[Jose Fonseca]

This prevents spurious failures when libtxc-dxtn-s2tc is installed.

Note: lp_test_format does need any change since we were already ignoring
S3TC failures there.
---
 src/gallium/tests/unit/u_format_test.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/gallium/tests/unit/u_format_test.c 
b/src/gallium/tests/unit/u_format_test.c
index 3145d13616..69d6c7dd3a 100644
--- a/src/gallium/tests/unit/u_format_test.c
+++ b/src/gallium/tests/unit/u_format_test.c
@@ -220,6 +220,11 @@ test_format_fetch_rgba_float(const struct 
util_format_description *format_desc,
   }
}
 
+   /* Ignore S3TC errors */
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
+  success = TRUE;
+   }
+
if (!success) {
   print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, " 
obtained\n");
   print_unpacked_rgba_doubl(format_desc, "", test->unpacked, " 
expected\n");
@@ -252,6 +257,11 @@ test_format_unpack_rgba_float(const struct 
util_format_description *format_desc,
   }
}
 
+   /* Ignore S3TC errors */
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
+  success = TRUE;
+   }
+
if (!success) {
   print_unpacked_rgba_float(format_desc, "FAILED: ", unpacked, " 
obtained\n");
   print_unpacked_rgba_doubl(format_desc, "", test->unpacked, " 
expected\n");
@@ -302,6 +312,11 @@ test_format_pack_rgba_float(const struct 
util_format_description *format_desc,
if (util_is_double_nan(test->unpacked[0][0][0]))
   success = TRUE;
 
+   /* Ignore S3TC errors */
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
+  success = TRUE;
+   }
+
if (!success) {
   print_packed(format_desc, "FAILED: ", packed, " obtained\n");
   print_packed(format_desc, "", test->packed, " expected\n");
@@ -365,6 +380,11 @@ test_format_unpack_rgba_8unorm(const struct 
util_format_description *format_desc
if (util_is_double_nan(test->unpacked[0][0][0]))
   success = TRUE;
 
+   /* Ignore S3TC errors */
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
+  success = TRUE;
+   }
+
if (!success) {
   print_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, " 
obtained\n");
   print_unpacked_rgba_8unorm(format_desc, "", expected, " 
expected\n");
@@ -422,6 +442,11 @@ test_format_pack_rgba_8unorm(const struct 
util_format_description *format_desc,
if ((test->unpacked[0][0][0] * 255.0) != (int)(test->unpacked[0][0][0] * 
255.0))
   success = TRUE;
 
+   /* Ignore S3TC errors */
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
+  success = TRUE;
+   }
+
if (!success) {
   print_packed(format_desc, "FAILED: ", packed, " obtained\n");
   print_packed(format_desc, "", test->packed, " expected\n");
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

[Jose Fonseca]

On 22/05/17 17:29, Eric Anholt wrote:

Jose Fonseca  writes:


I suppose the failures happen with S2TC lib-dxtn implementation.
Because I haven't seen them failing with the old implementation, or when
no implementation is present (as the tests will just skip.)

We could craft the test cases so they aren't sensitive to S2TC.  On the
other hand the patent expires this year IIRC, so probably not worth
spending time on it.

Honestly, I'm happy skipping all s3tc unit tests until we have full s3tc
in Mesa mainline source tree.


I don't see s2tc in any logs or in the travis-ci, so I don't think it's
installed.


It's probably pre-installed.  If you want to be sure you can do `dpkg -l 
'libtxc-dxtn-*'`



Do you have a suggestion for how to rip out the s3tc unit tests under
scons?  I'd really like to be able to push my code to github again
without getting build errors thrown back at me.


Sure.  I'll post a review soon.

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

Re: [Mesa-dev] [RFC PATCH 28/65] tc: add ARB_bindless_texture support

[Marek Olšák]

On Fri, May 19, 2017 at 6:52 PM, Samuel Pitoiset
 wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/auxiliary/util/u_threaded_context.c| 147 
> +
>  .../auxiliary/util/u_threaded_context_calls.h  |   4 +
>  2 files changed, 151 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_threaded_context.c 
> b/src/gallium/auxiliary/util/u_threaded_context.c
> index 8ea7f8aa26..36c2e4ed46 100644
> --- a/src/gallium/auxiliary/util/u_threaded_context.c
> +++ b/src/gallium/auxiliary/util/u_threaded_context.c
> @@ -1086,6 +1086,147 @@ tc_stream_output_target_destroy(struct pipe_context 
> *_pipe,
>
>
>  /
> + * bindless
> + */
> +
> +static uint64_t
> +tc_create_texture_handle(struct pipe_context *_pipe,
> + struct pipe_resource *res,
> + struct pipe_sampler_view *view,
> + const struct pipe_sampler_state *state)
> +{
> +   struct threaded_context *tc = threaded_context(_pipe);
> +   struct pipe_context *pipe = tc->pipe;
> +
> +   tc_sync(tc);
> +   return pipe->create_texture_handle(pipe, res, view, state);
> +}
> +
> +struct tc_delete_texture_handle
> +{
> +   uint64_t handle;
> +};

You can just add uint64_t handle into union tc_payload directly,
remove tc_payload::__use_8_bytes, and use tc_add_small_call instead.

> +
> +static void
> +tc_call_delete_texture_handle(struct pipe_context *pipe,
> +  union tc_payload *payload)
> +{
> +   struct tc_delete_texture_handle *p =
> +  (struct tc_delete_texture_handle *)payload;
> +
> +   pipe->delete_texture_handle(pipe, p->handle);
> +}
> +
> +static void
> +tc_delete_texture_handle(struct pipe_context *_pipe, uint64_t handle)
> +{
> +   struct threaded_context *tc = threaded_context(_pipe);
> +   struct tc_delete_texture_handle *p =
> +  tc_add_struct_typed_call(tc, TC_CALL_delete_texture_handle,
> +   tc_delete_texture_handle);
> +
> +   p->handle = handle;
> +}
> +
> +struct tc_make_texture_handle_resident
> +{
> +   uint64_t handle;
> +   bool resident;
> +};
> +
> +static void
> +tc_call_make_texture_handle_resident(struct pipe_context *pipe,
> + union tc_payload *payload)
> +{
> +   struct tc_make_texture_handle_resident *p =
> +  (struct tc_make_texture_handle_resident *)payload;
> +
> +   pipe->make_texture_handle_resident(pipe, p->handle, p->resident);
> +}
> +
> +static void
> +tc_make_texture_handle_resident(struct pipe_context *_pipe, uint64_t handle,
> +bool resident)
> +{
> +   struct threaded_context *tc = threaded_context(_pipe);
> +   struct tc_make_texture_handle_resident *p =
> +  tc_add_struct_typed_call(tc, TC_CALL_make_texture_handle_resident,
> +   tc_make_texture_handle_resident);
> +
> +   p->handle = handle;
> +   p->resident = resident;
> +}
> +
> +static uint64_t
> +tc_create_image_handle(struct pipe_context *_pipe,
> +   const struct pipe_image_view *image)
> +{
> +   struct threaded_context *tc = threaded_context(_pipe);
> +   struct pipe_context *pipe = tc->pipe;
> +
> +   tc_sync(tc);
> +   return pipe->create_image_handle(pipe, image);
> +}
> +
> +struct tc_delete_image_handle
> +{
> +   uint64_t handle;
> +};

Same here.

Marek

> +
> +static void
> +tc_call_delete_image_handle(struct pipe_context *pipe,
> +union tc_payload *payload)
> +{
> +   struct tc_delete_image_handle *p =
> +  (struct tc_delete_image_handle *)payload;
> +
> +   pipe->delete_image_handle(pipe, p->handle);
> +}
> +
> +static void
> +tc_delete_image_handle(struct pipe_context *_pipe, uint64_t handle)
> +{
> +   struct threaded_context *tc = threaded_context(_pipe);
> +   struct tc_delete_image_handle *p =
> +  tc_add_struct_typed_call(tc, TC_CALL_delete_image_handle,
> +   tc_delete_image_handle);
> +
> +   p->handle = handle;
> +}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 15/24] i965/cnl: Start using CNL MOCS defines

[Rafael Antognolli]

On Tue, May 16, 2017 at 04:01:30PM -0700, Anuj Phogat wrote:
> On Tue, May 16, 2017 at 10:34 AM, Anuj Phogat  wrote:
> > CNL MOCS defines are duplicates of SKL MOCS defines.
> >
> I can actually drop this patch and continue using SKL MOCS defines for gen10+.
> I also noticed that vulkan needs separate MOCS defines for each gen. Any
> preferences for GL driver?

I liked the way the vulkan driver does it, and would like to make the GL
driver do the same, at least on the gen specific code. That said, I don't have
a preference regarding keeping it or dropping it.

Also consider it:

Reviewed-by: Rafael Antognolli 

> > V2: Rebased.
> >
> > Signed-off-by: Anuj Phogat 
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c| 6 +++---
> >  src/mesa/drivers/dri/i965/brw_state.h| 8 
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 ++
> >  src/mesa/drivers/dri/i965/genX_state_upload.c| 4 +++-
> >  4 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index 8d3bcbb..bcc72df 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -100,9 +100,9 @@ brw_blorp_init(struct brw_context *brw)
> >brw->blorp.exec = gen9_blorp_exec;
> >break;
> > case 10:
> > -  brw->blorp.mocs.tex = SKL_MOCS_WB;
> > -  brw->blorp.mocs.rb = SKL_MOCS_PTE;
> > -  brw->blorp.mocs.vb = SKL_MOCS_WB;
> > +  brw->blorp.mocs.tex = CNL_MOCS_WB;
> > +  brw->blorp.mocs.rb = CNL_MOCS_PTE;
> > +  brw->blorp.mocs.vb = CNL_MOCS_WB;
> >brw->blorp.exec = gen10_blorp_exec;
> >break;
> > default:
> > diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> > b/src/mesa/drivers/dri/i965/brw_state.h
> > index 4592e3e..4503946 100644
> > --- a/src/mesa/drivers/dri/i965/brw_state.h
> > +++ b/src/mesa/drivers/dri/i965/brw_state.h
> > @@ -410,6 +410,14 @@ void upload_gs_state_for_tf(struct brw_context *brw);
> >  /* TC=LLC/eLLC, LeCC=PTE, LRUM=3, L3CC=WB */
> >  #define SKL_MOCS_PTE (1 << 1)
> >
> > +/* Cannonlake: MOCS is now an index into an array of 62 different caching
> > + * configurations programmed by the kernel.
> > + */
> > +/* TC=LLC/eLLC, LeCC=WB, LRUM=3, L3CC=WB */
> > +#define CNL_MOCS_WB  (2 << 1)
> > +/* TC=LLC/eLLC, LeCC=PTE, LRUM=3, L3CC=WB */
> > +#define CNL_MOCS_PTE (1 << 1)
> > +
> >  #ifdef __cplusplus
> >  }
> >  #endif
> > 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 c95fb37..c1003cd 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -64,12 +64,14 @@ uint32_t tex_mocs[] = {
> > [7] = GEN7_MOCS_L3,
> > [8] = BDW_MOCS_WB,
> > [9] = SKL_MOCS_WB,
> > +   [10] = CNL_MOCS_WB,
> >  };
> >
> >  uint32_t rb_mocs[] = {
> > [7] = GEN7_MOCS_L3,
> > [8] = BDW_MOCS_PTE,
> > [9] = SKL_MOCS_PTE,
> > +   [10] = CNL_MOCS_PTE,
> >  };
> >
> >  static void
> > diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> > b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > index 6619d4d..5710878 100644
> > --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> > +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > @@ -333,7 +333,9 @@ genX(emit_vertex_buffer_state)(struct brw_context *brw,
> >  #endif
> >  #endif
> >
> > -#if GEN_GEN == 9
> > +#if GEN_GEN == 10
> > +  .VertexBufferMOCS = CNL_MOCS_WB,
> > +#elif GEN_GEN == 9
> >.VertexBufferMOCS = SKL_MOCS_WB,
> >  #elif GEN_GEN == 8
> >.VertexBufferMOCS = BDW_MOCS_WB,
> > --
> > 2.9.3
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vc4: Remove dead code in vc4_dump_surface_msaa()

[Eric Anholt]

Rhys Kidd  writes:

> Coverity caught the use of dead code copy-paste for
> found_colors[] and num_found_colors.

Reviewed and pushed.  Thanks!


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

Re: [Mesa-dev] [PATCH] glsl: Fix g++ initializer order warning

[Matt Turner]

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

Re: [Mesa-dev] [PATCH V2 00/24] Add Cannonlake support

[Anuj Phogat]

On Fri, May 12, 2017 at 4:38 PM, Anuj Phogat  wrote:
> This series adds support for Cannonlake.
>
> Changes from V1 to V2:
> - Incorporated the review comments from V1.
> - Rebased 8 months old CNL branch on top of master
> - Wired up Linux and Android build files for gen10
> - Replaced the use of few gen9 functions with gen10 specific functions.
> - Squashed few patches, dropped few and created new patches.
>
Thanks to Jason and Ken who have reviewed few patches in this series.
Rest of them are still waiting for the review. I really want to land this series
(at least first 15-16 patches) soon. There are some very easy patches any
one can review like enabling Mesa to build for gen10 etc. Please take a
look at them. Thanks :).

> What's remaining:
> - Add missing gen10 bits in Vulkan driver.
> - Fix failing piglit, cts tests for GL and Vulkan.
>
> You can also find this series at:
> https://github.com/aphogat/mesa.git
> branch: reviews
>
> Anuj Phogat (18):
>   i965/cnl: Define genX(x) and GENX(x) for gen10
>   i965/cnl: Include gen10_pack.h
>   i965/cnl: Add gen10 specific function declarations
>   i965/cnl: Update the script generating genX_bits.h
>   i965/cnl: Add isl_gen10 header and source files
>   i965/cnl: Wire up Mesa build files for gen10
>   i965/cnl: Wire up android Mesa build files for gen10
>   i965/cnl: Add pci id for INTEL_DEVID_OVERRIDE
>   i965/cnl: Add cnl bits in aubinator
>   i965/cnl: Update few assertions
>   i965/cnl: Handle gen10 in switch cases across the driver
>   i965/cnl: Start using CNL MOCS defines
>   i965/cnl: Start using gen10 specific functions
>   i965/cnl: Don't resolve single sampled color rb in case of sRGB formats
>   i965/cnl: Make URB {VS, GS, HS, DS} sizes non multiple of 3
>   i965/cnl: Reformat surface_format_info table to accomodate gen10+
>   i965/cnl: Enable CCS_E and RT support for few formats
>   i965: Simplify get_l3_way_size() function
>
> Ben Widawsky (5):
>   i965: Make feature macros gen8 based
>   i965/cnl: Add a preliminary device for Cannonlake
>   i965/cnl: Implement new pipe control workaround
>   i965/cnl: Implement depth count workaround
>   i965/cnl: Restore lossless compression for sRGB formats
>
> Jason Ekstrand (1):
>   i965/cnl: Add gen10.xml
>
>  include/pci_ids/i965_pci_ids.h   |   12 +
>  src/intel/Android.genxml.mk  |5 +
>  src/intel/Android.isl.mk |   20 +
>  src/intel/Android.vulkan.mk  |   21 +
>  src/intel/Makefile.isl.am|4 +
>  src/intel/Makefile.sources   |   12 +-
>  src/intel/Makefile.vulkan.am |7 +-
>  src/intel/common/gen_device_info.c   |   71 +-
>  src/intel/common/gen_device_info.h   |1 +
>  src/intel/common/gen_l3_config.c |   11 +-
>  src/intel/compiler/brw_compiler.h|2 +-
>  src/intel/compiler/brw_eu.c  |2 +
>  src/intel/compiler/brw_eu_compact.c  |1 +
>  src/intel/genxml/gen10.xml   | 3563 
> ++
>  src/intel/genxml/genX_pack.h |2 +
>  src/intel/genxml/gen_bits_header.py  |6 +-
>  src/intel/genxml/gen_macros.h|3 +
>  src/intel/isl/isl.c  |9 +
>  src/intel/isl/isl_format.c   |  498 +--
>  src/intel/isl/isl_gen10.c|   41 +
>  src/intel/isl/isl_gen10.h|   45 +
>  src/intel/isl/isl_priv.h |   12 +
>  src/intel/tools/aubinator.c  |8 +-
>  src/intel/vulkan/anv_cmd_buffer.c|1 +
>  src/intel/vulkan/anv_device.c|1 +
>  src/intel/vulkan/anv_entrypoints_gen.py  |1 +
>  src/mesa/drivers/dri/i965/Android.mk |   24 +-
>  src/mesa/drivers/dri/i965/Makefile.am|6 +-
>  src/mesa/drivers/dri/i965/Makefile.sources   |4 +
>  src/mesa/drivers/dri/i965/brw_blorp.c|6 +
>  src/mesa/drivers/dri/i965/brw_blorp.h|2 +
>  src/mesa/drivers/dri/i965/brw_context.c  |2 +-
>  src/mesa/drivers/dri/i965/brw_formatquery.c  |1 +
>  src/mesa/drivers/dri/i965/brw_pipe_control.c |   11 +
>  src/mesa/drivers/dri/i965/brw_program.c  |2 +-
>  src/mesa/drivers/dri/i965/brw_queryobj.c |8 +
>  src/mesa/drivers/dri/i965/brw_state.h|9 +
>  src/mesa/drivers/dri/i965/brw_state_upload.c |4 +-
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +
>  src/mesa/drivers/dri/i965/gen7_urb.c |   12 +
>  src/mesa/drivers/dri/i965/genX_state_upload.c|4 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c|2 +-
>  src/mesa/drivers/dri/i965/intel_screen.c |2 +
>  43 files changed, 4180 insertions(+), 280 deletions(-)
>  

[Mesa-dev] [PATCH] Revert "gallium: remove unused PIPE_CC_GCC_VERSION"

[Brian Paul]

This reverts commit e60928f4c4bd4484821d83f2b16a910ea9f5f9d9.

PIPE_CC_GCC_VERSION is used by some of our in-house code which hasn't
been upstreamed yet.
---
 src/gallium/include/pipe/p_config.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/include/pipe/p_config.h 
b/src/gallium/include/pipe/p_config.h
index 98c433f..3fa43ed 100644
--- a/src/gallium/include/pipe/p_config.h
+++ b/src/gallium/include/pipe/p_config.h
@@ -53,6 +53,7 @@
 
 #if defined(__GNUC__)
 #define PIPE_CC_GCC
+#define PIPE_CC_GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)
 #endif
 
 /*
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

[Eric Anholt]

Jose Fonseca  writes:

> I suppose the failures happen with S2TC lib-dxtn implementation. 
> Because I haven't seen them failing with the old implementation, or when 
> no implementation is present (as the tests will just skip.)
>
> We could craft the test cases so they aren't sensitive to S2TC.  On the 
> other hand the patent expires this year IIRC, so probably not worth 
> spending time on it.
>
> Honestly, I'm happy skipping all s3tc unit tests until we have full s3tc 
> in Mesa mainline source tree.

I don't see s2tc in any logs or in the travis-ci, so I don't think it's
installed.

Do you have a suggestion for how to rip out the s3tc unit tests under
scons?  I'd really like to be able to push my code to github again
without getting build errors thrown back at me.


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

Re: [Mesa-dev] [PATCH] travis: Disable scons tests, since the gallium unit tests fail.

[Eric Anholt]

Rhys Kidd  writes:

> On 21 May 2017 at 19:33, Roland Scheidegger  wrote:
>
>> I suppose the s3tc problems should go away rather sooner than later, but
>> isn't it possible to just disable the formats tests?
>>
>
> Yes, see USE_TXC_DXTN that was introduced in
> 29322daef2b77c4d869d2945fa1226e6b433c68
> to address this issue with a small subset of the tests run by scons.
>
> It's objective was to provide this option prior to October 2, 2017 when
> this should all fall away.
>
> Does that achieve what you are looking to do Eric?

I don't believe anybody here can legally use the USE_TXC_DXTN option on
Travis, and would rather it didn't exist because of that.  I haven't
enabled it, myself.


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

Re: [Mesa-dev] [PATCH] docs: Document ASTC extension support for SKL and BXT

[Anuj Phogat]

On Fri, May 19, 2017 at 4:42 PM, Nanley Chery  wrote:
> Cc: Anuj Phogat 
> Signed-off-by: Nanley Chery 
> ---
>  docs/features.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index e18bf54a48..05d776be08 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -306,8 +306,8 @@ Khronos, ARB, and OES extensions that are not part of any 
> OpenGL or OpenGL ES ve
>GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+)
>GL_KHR_blend_equation_advanced_coherent   DONE (i965/gen9+)
>GL_KHR_no_error   started (Timothy 
> Arceri)
> -  GL_KHR_texture_compression_astc_hdr   DONE (core only)
> -  GL_KHR_texture_compression_astc_sliced_3d not started
> +  GL_KHR_texture_compression_astc_hdr   DONE (i965/bxt+)
> +  GL_KHR_texture_compression_astc_sliced_3d DONE (i965/gen9+)
>GL_OES_depth_texture_cube_map DONE (all drivers 
> that support GLSL 1.30+)
>GL_OES_EGL_image  DONE (all drivers)
>GL_OES_EGL_image_external_essl3   not started
> --
> 2.12.2
>
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600: fix compilation error without amdgpu

[Emil Velikov]

This patch won't be sufficient since you'll error out at link time,
when building w/o radeonsi. There are three possible routes [1].
Let me know which one you prefer :-)

-Emil
[1] https://lists.freedesktop.org/archives/mesa-dev/2017-May/156429.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeon: pass flags that can change shaders to disk_cache_create()

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sat, May 20, 2017 at 3:36 AM, Timothy Arceri  wrote:
> I wasn't sure if I should filter the flags so that we only use
> flags that actually change the shader output. To avoid manual
> updates we just pass in everything for now.
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 2d8feee..ac6c552 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -861,21 +861,22 @@ static void r600_disk_cache_create(struct 
> r600_common_screen *rscreen)
> if 
> (disk_cache_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo,
>   
> _timestamp)) {
> res = asprintf(_str, "%u_%u",
>mesa_timestamp, 
> llvm_timestamp);
> }
> }
>  #endif
> if (res != -1) {
> rscreen->disk_shader_cache =
> disk_cache_create(r600_get_chip_name(rscreen),
> - timestamp_str, 0);
> + timestamp_str,
> + rscreen->debug_flags);
> free(timestamp_str);
> }
> }
>  }
>
>  static struct disk_cache *r600_get_disk_shader_cache(struct pipe_screen 
> *pscreen)
>  {
> struct r600_common_screen *rscreen = (struct 
> r600_common_screen*)pscreen;
> return rscreen->disk_shader_cache;
>  }
> --
> 2.9.4
>
> ___
> 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] i965/gen4: Depth buffer setup cleanup

[Pohjolainen, Topi]

On Sun, May 21, 2017 at 06:15:46PM +0300, Pohjolainen, Topi wrote:
> On Sat, May 20, 2017 at 10:29:51PM +0300, Topi Pohjolainen wrote:
> > First this series removes logic considering separate stencil 
> > gen < 6 only code paths (where we always use combined
> > depth-stencil).
> > 
> > Then patch 5 simplifies the workaround we need for aligning
> > depth buffer. On gen < 6 there is no support for telling which
> > mip-level to draw and hence the driver needs to offset the
> > buffer accordingly. Unfortunately hardware also requires
> > aligned buffer offsets forcing the driver to use temporary
> > aligned copies (which are reconciled back into the mipmapped
> > buffer later on).
> > 
> > However, in case of combined depth-stencil there are cases
> > where there is no depth attachment but stencil only (which
> > is also backed by combined depth-stencil). In those cases
> > current logic fails to offset the buffer correctly when the
> > miplevel is already aligned and doesn't need a copy. Driver
> > correctly sets the intra tile offsets (g45 and ilk) but
> > leaves the page aligned offset zero. This gets fixed
> > by patch 5.
> > I considered fixing this first and only then do the
> > cleanups but unfortunately that would make ugly even
> > uglier.
> 
> I take this back, there is a simple fix for this that can be
> backported without the clean-ups. I'm also looking at failures
> in "copyteximage 2D_ARRAY -auto", and I think I might be able to
> provide a fix for those also. So the whole series will get
> another version.

Well, fixing the rendering of arrayed depth is harder. Current logic simply
fails to move individual slice into aligned position. Depth alignment
workaround, brw_workaround_depthstencil_alignment(), detects correctly that a
slice is not aligned and kicks off intel_renderbuffer_move_to_temp(). Only
problem is that this will move the entire level including all the slices in it
(see intel_miptree_copy_teximage()). Therefore, one actually gets identical
array where the slice of interest is in non-aligned offset. The entire move
therefore is in vain.
Fixing this is not trivial, reconciling the temporary move (see
intel_finalize_mipmap_tree()), also relies on intel_miptree_copy_teximage()
which in turn is not built to handle images containing single slices of
arrays.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600: fix compilation error without amdgpu

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, May 22, 2017 at 11:37 AM, Marc Dietrich  wrote:
> This fixes the following compilation error when amdgpu is not selected.
>
>   CC   common/common_libamd_common_la-ac_gpu_info.lo
> In file included from common/ac_gpu_info.c:26:0:
> common/ac_gpu_info.h:31:10: fatal error: amdgpu.h: No such file or directory
>  #include 
>   ^~
> compilation terminated.
>
> Signed-off-by: Marc Dietrich 
> ---
>  src/amd/Makefile.common.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/Makefile.common.am b/src/amd/Makefile.common.am
> index dff461c35d..677fd52975 100644
> --- a/src/amd/Makefile.common.am
> +++ b/src/amd/Makefile.common.am
> @@ -26,6 +26,7 @@ COMMON_LIBS = common/libamd_common.la
>  # TODO cleanup these
>  common_libamd_common_la_CPPFLAGS = \
> $(AMDGPU_CFLAGS) \
> +   $(RADEON_CFLAGS) \
> $(VALGRIND_CFLAGS) \
> $(DEFINES) \
> -I$(top_srcdir)/include \
> --
> 2.12.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/nine: Fix a regression and syntax cleanup

[Marek Olšák]

I'm not so familiar with this code, but it looks good to me.

Marek

On Mon, May 22, 2017 at 12:22 AM, Axel Davy  wrote:
> A few cleanups and in particular initializing properly
> the new pipe_draw_info fields.
> This should fix the regression caused by
> 330d0607ed60fd3edca192e54b4246310f06652f
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101088
>
> Signed-off-by: Axel Davy 
> ---
>  src/gallium/state_trackers/nine/device9.c  |  2 +-
>  src/gallium/state_trackers/nine/indexbuffer9.c |  8 ++--
>  src/gallium/state_trackers/nine/indexbuffer9.h |  5 ++---
>  src/gallium/state_trackers/nine/nine_state.c   | 20 +++-
>  4 files changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/device9.c 
> b/src/gallium/state_trackers/nine/device9.c
> index db33fdd580..37880405e9 100644
> --- a/src/gallium/state_trackers/nine/device9.c
> +++ b/src/gallium/state_trackers/nine/device9.c
> @@ -2927,7 +2927,7 @@ NineDevice9_DrawIndexedPrimitiveUP( struct NineDevice9 
> *This,
> ibuf,
> ibuf ? NULL : 
> (void*)pIndexData,
> index_offset,
> -  index_size);
> +   index_size);
>  NineAfterDraw(This);
>
>  pipe_vertex_buffer_unreference();
> diff --git a/src/gallium/state_trackers/nine/indexbuffer9.c 
> b/src/gallium/state_trackers/nine/indexbuffer9.c
> index d5f5492563..e73d29b5bd 100644
> --- a/src/gallium/state_trackers/nine/indexbuffer9.c
> +++ b/src/gallium/state_trackers/nine/indexbuffer9.c
> @@ -49,9 +49,6 @@ NineIndexBuffer9_ctor( struct NineIndexBuffer9 *This,
>  if (FAILED(hr))
>  return hr;
>
> -This->buffer = NULL;
> -This->offset = 0;
> -
>  switch (pDesc->Format) {
>  case D3DFMT_INDEX16: This->index_size = 2; break;
>  case D3DFMT_INDEX32: This->index_size = 4; break;
> @@ -73,11 +70,10 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 *This )
>  }
>
>  struct pipe_resource *
> -NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This )
> +NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This, unsigned *offset )
>  {
>  /* The resource may change */
> -This->buffer = NineBuffer9_GetResource(>base, >offset);
> -return This->buffer;
> +return NineBuffer9_GetResource(>base, offset);
>  }
>
>  HRESULT NINE_WINAPI
> diff --git a/src/gallium/state_trackers/nine/indexbuffer9.h 
> b/src/gallium/state_trackers/nine/indexbuffer9.h
> index 0efad7f5f1..e688488da8 100644
> --- a/src/gallium/state_trackers/nine/indexbuffer9.h
> +++ b/src/gallium/state_trackers/nine/indexbuffer9.h
> @@ -37,8 +37,6 @@ struct NineIndexBuffer9
>  struct NineBuffer9 base;
>
>  /* g3d stuff */
> -struct pipe_resource *buffer;
> -unsigned offset;
>  unsigned index_size;
>
>  D3DINDEXBUFFER_DESC desc;
> @@ -65,7 +63,8 @@ NineIndexBuffer9_dtor( struct NineIndexBuffer9 *This );
>  /*** Nine private ***/
>
>  struct pipe_resource *
> -NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This );
> +NineIndexBuffer9_GetBuffer( struct NineIndexBuffer9 *This,
> +unsigned *offset );
>
>  /*** Direct3D public ***/
>
> diff --git a/src/gallium/state_trackers/nine/nine_state.c 
> b/src/gallium/state_trackers/nine/nine_state.c
> index 0fc4c8315a..30935760ae 100644
> --- a/src/gallium/state_trackers/nine/nine_state.c
> +++ b/src/gallium/state_trackers/nine/nine_state.c
> @@ -1575,12 +1575,11 @@ nine_context_set_indices(struct NineDevice9 *device,
>  {
>  struct pipe_resource *res = NULL;
>  UINT IndexSize = 0;
> -UINT OffsetInBytes = 0;
> +unsigned OffsetInBytes = 0;
>
>  if (idxbuf) {
> -res = NineIndexBuffer9_GetBuffer(idxbuf);
> +res = NineIndexBuffer9_GetBuffer(idxbuf, );
>  IndexSize = idxbuf->index_size;
> -OffsetInBytes = idxbuf->offset;
>  }
>
>  nine_context_set_indices_apply(device, res, IndexSize, OffsetInBytes);
> @@ -2540,6 +2539,7 @@ init_draw_info(struct pipe_draw_info *info,
>  if (dev->context.stream_instancedata_mask & 
> dev->context.stream_usage_mask)
>  info->instance_count = MAX2(dev->context.stream_freq[0] & 0x7F, 
> 1);
>  info->primitive_restart = FALSE;
> +info->has_user_indices = FALSE;
>  info->restart_index = 0;
>  info->count_from_stream_output = NULL;
>  info->indirect = NULL;
> @@ -2561,17 +2561,18 @@ CSMT_ITEM_NO_WAIT(nine_context_draw_primitive,
>  info.index_bias = 0;
>  info.min_index = info.start;
>  info.max_index = info.count - 1;
> +info.index.resource = NULL;
>
>  context->pipe->draw_vbo(context->pipe, );
>  }
>
>  CSMT_ITEM_NO_WAIT(nine_context_draw_indexed_primitive,
>

[Mesa-dev] [PATCH v2 13/13] gbm: manage only the required set of DRI extensions

[Emil Velikov]

From: Emil Velikov 

Currently GBM attempts to know all the extensions that might be required
by EGL/DRM [at some later stage].

That is a bit unclear and we often forget to update GBM as EGL gets
attention.

To avoid that, simply let EGL manage it's own required extensions based
on the base primitive (screen) we provide it.

v2: Rework the approach - GBM should not dive into EGL/DRM.

Cc: Rob Herring 
Signed-off-by: Emil Velikov 
---
Rob can you give the series a quick test.
I'm 99.99% sure that it should be fine on your end.

https://github.com/evelikov/Mesa/tree/egl-gbm-less-copy

Thanks
Emil
---
 src/gbm/backends/dri/gbm_dri.c| 1 -
 src/gbm/backends/dri/gbm_driint.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 9b08ae31a50..7fb569078b2 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -256,7 +256,6 @@ static struct dri_extension_match dri_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
{ __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
-   { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
{ NULL, 0, 0 }
 };
 
diff --git a/src/gbm/backends/dri/gbm_driint.h 
b/src/gbm/backends/dri/gbm_driint.h
index 68220cb85d0..db9038a623a 100644
--- a/src/gbm/backends/dri/gbm_driint.h
+++ b/src/gbm/backends/dri/gbm_driint.h
@@ -56,7 +56,6 @@ struct gbm_dri_device {
const __DRIimageExtension  *image;
const __DRIswrastExtension *swrast;
const __DRI2flushExtension *flush;
-   const __DRI2interopExtension *interop;
 
const __DRIconfig   **driver_configs;
const __DRIextension **loader_extensions;
-- 
2.12.2

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

[Mesa-dev] [PATCH v2 12/13] egl/drm: use dri2_setup_extensions() over the extensions provided by GBM

[Emil Velikov]

From: Emil Velikov 

Allows us to keep things in sync easier and lets us simplify the
interface between the two even further.

v2: Don't set GBM's extensions.

Cc: Rob Herring 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 80e824f3d54..0e16d520bd8 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -716,12 +716,8 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
dri2_dpy->dri_screen = dri2_dpy->gbm_dri->screen;
dri2_dpy->core = dri2_dpy->gbm_dri->core;
dri2_dpy->dri2 = dri2_dpy->gbm_dri->dri2;
-   dri2_dpy->fence = dri2_dpy->gbm_dri->fence;
-   dri2_dpy->image = dri2_dpy->gbm_dri->image;
-   dri2_dpy->flush = dri2_dpy->gbm_dri->flush;
dri2_dpy->swrast = dri2_dpy->gbm_dri->swrast;
dri2_dpy->driver_configs = dri2_dpy->gbm_dri->driver_configs;
-   dri2_dpy->interop = dri2_dpy->gbm_dri->interop;
 
dri2_dpy->gbm_dri->lookup_image = dri2_lookup_egl_image;
dri2_dpy->gbm_dri->lookup_user_data = disp;
@@ -737,6 +733,11 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
dri2_dpy->gbm_dri->base.surface_release_buffer = release_buffer;
dri2_dpy->gbm_dri->base.surface_has_free_buffers = has_free_buffers;
 
+   if (!dri2_setup_extensions(disp)) {
+  err = "DRI2: failed to find required DRI extensions";
+  goto cleanup;
+   }
+
dri2_setup_screen(disp);
 
if (!drm_add_configs_for_visuals(drv, disp)) {
-- 
2.12.2

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

Re: [Mesa-dev] Please dont remove support for working hardware

[Jason Ekstrand]

No one is suggesting we completely drop support for old hardware.  The
drivers will still exist and work; they will just live in a legacy branch.
We will also ensure that they are installable alongside the modern drivers
and the expectation is that distros will continue to package them.  The
thing that's being suggested is that we move them out of the master branch
where we tend to break them more than fix them.  They can continue to get
bugfixes on the legacy branch, they just won't get the random breakage from
changes made for other drivers.

On Mon, May 22, 2017 at 4:36 AM, hgkldj...@t-online.de <
hgkldj...@t-online.de> wrote:

> I have read on https://phoronix.com/scan.php?page=news_item=Mesa-2017-
> Cleanup-Discussion that there is a discussion about removing still
> working hardware. Please fix the problems instead.
>
> Please, dont remove support for it. I have spend in the last year over 100
> hours of testing such hardware and reporting anonymously(privacy is
> important for me) bugs.
>
> I still like to use such hardware when no new hardware is required for a
> special use case. Also free software is always been talked about that it
> does not drop support for working hardware. Many linux developers laugh at
> the microsoft windows world when a new windows is been released and then
> there are no drivers for it. Then the general sentense of many people deep
> inside the linux community is "thats what happen when you use closed source
> software, take linux to fix this".
>
> Also its bad for nature to drop support of working hardware. Throw-away
> living is terrible for the nature!
>
> For example i have build for a development-usecase a modern amd-ryzen
> setup to a full-hd screen(no more space on desk). I put a GPU into this
> setup that include all required functionality: PCIe card with NV40 chip.
> The developer working on this hardware is now forced to not use gnome or
> kde-plasma because all bugs have been reported to for example imirkin and
> now waiting since one year for a bugfix. imirkin have bought a nv40 card
> for the PCI slot to fix those nv40 bugs. I am testing at least once a month
> a recent linux live image to see if the reported problems are fixed in the
> latest code.
>
> I also use machines for dedicated usage with much older hardware for using
> existing hardware that fullfills this usecase. For example a video-screen
> on a wall that should run 24/7 on a small vga screen -> you can use
> perfectly fine anything at radeon r200 series and defenetly everything at
> nouveau nv30 series.
>
>
>
> Please dont drop support for working hardware. Please fix the bugs instead
> of breaking completely the supprot for the hardware. I would still like to
> use the hardware and be able to say "linux is great, it does not force you
> to throw away fully working hardware".
> 
>
>
> Gesendet mit Telekom Mail  -
> kostenlos und sicher für alle!
>
> ___
> 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 v2] mesa: Avoid leaking surface in st_renderbuffer_delete

[Emil Velikov]

On 29 April 2017 at 15:37, Bartosz Tomczyk  wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100741
> Fixes: a5e733c6b52 mesa: drop current draw/read buffer when ctx is released
> CC: Rob Clark 
> v2: add comment in code

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Emil Velikov]

On 20 May 2017 at 01:16, Rob Herring  wrote:
> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov  
> wrote:
>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>>> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
>>> wrote:
 On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>
>>> -Original Message-
>>> From: Palli, Tapani
>>> >
>>> > It's just applied. Isn't it?
>>> > Yesterday without this patch
>>> > the color format is mismatch apparently.
>>>
>>> Yeah we do need this. TBH I don't quite understand why but will try to 
>>> figure
>>> it out. I remember we used to have a patch in Surfaceflinger at one 
>>> point
>>> because visual was hardcoded there and this might be related.
>>>
>>> // Tapani
>>
>> Sorry, that's for different issue, I mix it with RGB565 blending one.
>> This patch is required because some Android GLES test apps, like 
>> gl2_basic, need to create RGBA surface.
>
> Indeed it is.
>
> As Emil pointed out, the patch was merged before
> but reverted later since it broke desktop.
>
> So what's the current upstreaming plan?
>
 No idea about a plan, but how you can fix it once and for all:

 Extend the loader extension(s) to have a get_caps() callback,
 analogous to __DRIimageExtension::getCapabilities.
 Then the DRI module will query [the loader] and advertise the
 RGBX/RGBA visuals when possible.
>>>
>>> Could we do something compile time instead to enable just for Android?
>>> Seems like a lot of complexity when the platform needing these pixel
>>> formats doesn't need the backwards compatibility. Or maybe there are
>>> other things needing this interface?
>>>
>> Having a short/mid term ifdef ANDROID is perfectly fine.
>>
>> Can we address some of the existing ones before/alongside the newly added 
>> ones?
>> Afacit the nouveau bits are no longer applicable.
>
> Yeah. I don't explicitly warn for KK or less, but will add that and fix these.
>
>> While for the
>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
>> rework or MESA_LOADER_DRIVER_OVERRIDE.
>
> How does the build rework help? My only reservation with using an env
> var is generally Android things don't rely on them and it would break
> working systems. I'm not even completely certain I can set env vars
> globally. It would be nice if the build system could set defaults for
> env vars we could use.
>
IIRC with the rework you have the dri driver names are known as we
reach targets/dri/Android.mk
Thus one can reuse them to create the separate drivers
  - be that one blob + {sym,hard}links as we do in autotools/scons, or
 - completely separate drivers like i965 and other classic drivers.

On the envvar side - it is meant as a workaround. It's not something
we want to set by the build.
Android-x86 already sets some at boot time, so it should be possible
to add one there.

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

Re: [Mesa-dev] [PATCH v13 02/36] egl/main: add support for fourth plane tokens

[Emil Velikov]

On 22 May 2017 at 13:47, Daniel Stone  wrote:
> Hey,
>
> On 22 May 2017 at 13:43, Emil Velikov  wrote:
>> On 19 May 2017 at 10:37, Daniel Stone  wrote:
>>> The EGL_EXT_dma_buf_import_modifiers extension adds support for a
>>> fourth plane, just like DRM KMS API does.
>>>
>>> Bump maximum dma_buf plane count to four.
>>
>> Patch 1 and 2 are
>> Reviewed-by: Emil Velikov 
>> Feel free to push instead of constantly rebasing.
>>
>> Aside:
>> AFAICT the EXT_image_dma_buf_import_modifiers extension does not
>> mention much about the 4th plane fd/pitch/other properties.
>> Might want to add a small note that all they behave just like PLANE0-2
>> in EXT_image_dma_buf_import.
>
> There is this, from lines 123-135:
> For semi-planar and planar YUV formats, or other formats which require
> multiple memory planes, planes 1, 2 and 3 are specified by the following
> attributes, which have the same meanings as defined above for plane 0:
>
> * [...]
> * EGL_DMA_BUF_PLANE3_FD_EXT
> * EGL_DMA_BUF_PLANE3_OFFSET_EXT
> * EGL_DMA_BUF_PLANE3_PITCH_EXT
>
I was thinking about the error conditions as seen in below hunk [from
EXT_image_dma_buf_import].
The existing "see plane 0 meaning" should imply the error handling as
well, so I think we're spot on.

Thanks for the correction!
Emil

Add to the list of error conditions for eglCreateImageKHR:

   * If  is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT
 attribute indicates a single-plane format, EGL_BAD_ATTRIBUTE is
 generated if any of the EGL_DMA_BUF_PLANE1_* or EGL_DMA_BUF_PLANE2_*
 attributes are specified.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v13 13/36] st/dri: support format queries

[Brian Paul]

On 05/19/2017 08:48 AM, Lucas Stach wrote:

Am Freitag, den 19.05.2017, 10:37 +0100 schrieb Daniel Stone:

From: Varad Gautam 

ask the driver for supported dmabuf formats

v2: rebase to master.
v3: return false on failure.
v4: use pscreen->is_format_supported instead of adding a new query.
 (Lucas Stach)
Signed-off-by: Varad Gautam 
Signed-off-by: Daniel Stone 


Reviewed-by: Lucas Stach 


---
  src/gallium/state_trackers/dri/dri2.c | 91 +++
  1 file changed, 91 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 3f83cc96cc..814a08e3cb 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -216,6 +216,69 @@ static enum pipe_format dri2_format_to_pipe_format (int 
format)
 return pf;
  }

+static enum pipe_format fourcc_to_pipe_format(int fourcc) {


FWIW, the Mesa formatting standard would be:

static enum pipe_format
fourcc_to_pipe_format(int fourcc)
{

-Brian



+   enum pipe_format pf;
+
+   switch (fourcc) {
+   case __DRI_IMAGE_FOURCC_R8:
+  pf = PIPE_FORMAT_R8_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_GR88:
+  pf = PIPE_FORMAT_RG88_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_ARGB1555:
+  pf = PIPE_FORMAT_B5G5R5A1_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_R16:
+  pf = PIPE_FORMAT_R16_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_GR1616:
+  pf = PIPE_FORMAT_RG1616_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_RGB565:
+  pf = PIPE_FORMAT_B5G6R5_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_ARGB:
+  pf = PIPE_FORMAT_BGRA_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_XRGB:
+  pf = PIPE_FORMAT_BGRX_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_ABGR:
+  pf = PIPE_FORMAT_RGBA_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_XBGR:
+  pf = PIPE_FORMAT_RGBX_UNORM;
+  break;
+
+   case __DRI_IMAGE_FOURCC_NV12:
+  pf = PIPE_FORMAT_NV12;
+  break;
+   case __DRI_IMAGE_FOURCC_YUYV:
+  pf = PIPE_FORMAT_YUYV;
+  break;
+   case __DRI_IMAGE_FOURCC_YUV420:
+   case __DRI_IMAGE_FOURCC_YVU420:
+  pf = PIPE_FORMAT_YV12;
+  break;
+
+   case __DRI_IMAGE_FOURCC_SARGB:
+   case __DRI_IMAGE_FOURCC_YUV410:
+   case __DRI_IMAGE_FOURCC_YUV411:
+   case __DRI_IMAGE_FOURCC_YUV422:
+   case __DRI_IMAGE_FOURCC_YUV444:
+   case __DRI_IMAGE_FOURCC_NV16:
+   case __DRI_IMAGE_FOURCC_YVU410:
+   case __DRI_IMAGE_FOURCC_YVU411:
+   case __DRI_IMAGE_FOURCC_YVU422:
+   case __DRI_IMAGE_FOURCC_YVU444:
+   default:
+  pf = PIPE_FORMAT_NONE;
+   }
+
+   return pf;
+}
+
  /**
   * DRI2 flush extension.
   */
@@ -1343,6 +1406,31 @@ dri2_from_fds(__DRIscreen *screen, int width, int 
height, int fourcc,
 return img;
  }

+static boolean
+dri2_query_dma_buf_formats(__DRIscreen *_screen, int max, int *formats,
+   int *count)
+{
+   struct dri_screen *screen = dri_screen(_screen);
+   struct pipe_screen *pscreen = screen->base.screen;
+   const unsigned bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
+   int i, j;
+
+   for (i = 0, j = 0; (i < ARRAY_SIZE(image_formats)) &&
+ (j < max || max == 0); i++) {
+  if (pscreen->is_format_supported(pscreen,
+   fourcc_to_pipe_format(
+  image_formats[i].fourcc),
+   screen->target,
+   0, bind)) {
+ if (j < max)
+formats[j] = image_formats[i].fourcc;
+ j++;
+  }
+   }
+   *count = j;
+   return true;
+}
+
  static __DRIimage *
  dri2_from_dma_bufs(__DRIscreen *screen,
 int width, int height, int fourcc,
@@ -1529,6 +1617,7 @@ static __DRIimageExtension dri2ImageExtension = {
  .unmapImage   = dri2_unmap_image,
  .createImageWithModifiers = NULL,
  .createImageFromDmaBufs2  = NULL,
+.queryDmaBufFormats   = NULL,
  };


@@ -2075,6 +2164,7 @@ dri2_init_screen(__DRIscreen * sPriv)
   dri2ImageExtension.createImageFromFds = dri2_from_fds;
   dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
   dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
+ dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
}
 }

@@ -2152,6 +2242,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
dri2ImageExtension.createImageFromFds = dri2_from_fds;
dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
dri2ImageExtension.createImageFromDmaBufs2 = dri2_from_dma_bufs2;
+  dri2ImageExtension.queryDmaBufFormats = dri2_query_dma_buf_formats;
 }

 sPriv->extensions = dri_screen_extensions;



___

Re: [Mesa-dev] [PATCH v13 11/36] st/dri: implement createImageWithModifiers in DRIimage

[Emil Velikov]

On 19 May 2017 at 10:37, Daniel Stone  wrote:
> From: Varad Gautam 
>
> adds a pscreen->resource_create_with_modifiers() to create textures
> with modifier.
>
> Signed-off-by: Varad Gautam 
> Signed-off-by: Daniel Stone 
> ---
>  src/gallium/include/pipe/p_screen.h   | 18 
>  src/gallium/state_trackers/dri/dri2.c | 79 
> ---
>  2 files changed, 81 insertions(+), 16 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_screen.h 
> b/src/gallium/include/pipe/p_screen.h
> index 8b4239c61a..8eddf355d7 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -328,6 +328,24 @@ struct pipe_screen {
>  * driver doesn't support an on-disk shader cache.
>  */
> struct disk_cache *(*get_disk_shader_cache)(struct pipe_screen *screen);
> +
> +   /**
> +* Create a new texture object from the given template info, taking
> +* format modifiers into account. \p modifiers specifies a list of format
> +* modifier tokens, as defined in drm_fourcc.h. The driver then picks the
> +* best modifier among these and creates the resource. \p count must
> +* contain the size of \p modifiers array. The selected modifier is
> +* returned via \p modifier after a successful call.
> +*
> +* Returns NULL if an entry in \p modifiers is unsupported by the driver,
> +* or if only DRM_FORMAT_MOD_INVALID is provided.
> +*/
> +   struct pipe_resource * (*resource_create_with_modifiers)(
> +   struct pipe_screen *,
Style: move this to previous line.


> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 7614474e4a..713f482181 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -977,27 +977,38 @@ dri2_create_image_from_renderbuffer(__DRIcontext 
> *context,

> tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> -   if (use & __DRI_IMAGE_USE_SCANOUT)
> -  tex_usage |= PIPE_BIND_SCANOUT;
> -   if (use & __DRI_IMAGE_USE_SHARE)
> -  tex_usage |= PIPE_BIND_SHARED;
> -   if (use & __DRI_IMAGE_USE_LINEAR)
> -  tex_usage |= PIPE_BIND_LINEAR;
> -   if (use & __DRI_IMAGE_USE_CURSOR) {
> -  if (width != 64 || height != 64)
> - return NULL;
> -  tex_usage |= PIPE_BIND_CURSOR;
> +   if (use) {
> +  if (use & __DRI_IMAGE_USE_SCANOUT)
> + tex_usage |= PIPE_BIND_SCANOUT;
> +  if (use & __DRI_IMAGE_USE_SHARE)
> + tex_usage |= PIPE_BIND_SHARED;
> +  if (use & __DRI_IMAGE_USE_LINEAR)
> + tex_usage |= PIPE_BIND_LINEAR;
> +  if (use & __DRI_IMAGE_USE_CURSOR) {
> + if (width != 64 || height != 64)
> +return NULL;
> + tex_usage |= PIPE_BIND_CURSOR;
> +  }
Unrelated micro optimisation?

> }
>
> pf = dri2_format_to_pipe_format (format);
> @@ -1018,7 +1029,16 @@ dri2_create_image(__DRIscreen *_screen,
> templ.depth0 = 1;
> templ.array_size = 1;
>
> -   img->texture = screen->base.screen->resource_create(screen->base.screen, 
> );
> +   if (modifiers)
> +  img->texture = screen->base.screen
> +->resource_create_with_modifiers(screen->base.screen,
> + ,
> + modifiers,
> + count,
> + );
> +   else
> +  img->texture = screen->base.screen
> +->resource_create(screen->base.screen, );
Style:
   foo =
  screen->.

> if (!img->texture) {
>FREE(img);
>return NULL;
> @@ -1029,12 +1049,34 @@ dri2_create_image(__DRIscreen *_screen,
> img->dri_format = format;
> img->dri_components = 0;
> img->use = use;
> -   img->modifier = DRM_FORMAT_MOD_INVALID;
> +   img->modifier = modifier;
>
> img->loader_private = loaderPrivate;
> return img;
>  }
>
> +static __DRIimage *
> +dri2_create_image(__DRIscreen *_screen,
> +   int width, int height, int format,
> +   unsigned int use, void *loaderPrivate)
> +{
> +   return dri2_create_image_common(_screen, width, height, format, use,
> +   NULL /* modifiers */, 0 /* count */,
> +   loaderPrivate);
> +}
> +
> +static __DRIimage *
> +dri2_create_image_with_modifiers(__DRIscreen *dri_screen,
> + int width, int height, int format,
> + const uint64_t *modifiers,
> + const unsigned count,
> + void *loaderPrivate)
> +{
> +   return dri2_create_image_common(dri_screen, width, height, format,
> +