[Mesa-dev] [PATCH] radv: Fix a stupid if in gather_intrinsic_info

[Jason Ekstrand]

---
 src/amd/vulkan/radv_shader_info.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/amd/vulkan/radv_shader_info.c 
b/src/amd/vulkan/radv_shader_info.c
index f7888ec6a6a..c2e005e63dd 100644
--- a/src/amd/vulkan/radv_shader_info.c
+++ b/src/amd/vulkan/radv_shader_info.c
@@ -270,15 +270,15 @@ gather_intrinsic_info(const nir_shader *nir, const 
nir_intrinsic_instr *instr,
}
mark_sampler_desc(var, info);
 
-   if (nir_intrinsic_image_deref_store ||
-   nir_intrinsic_image_deref_atomic_add ||
-   nir_intrinsic_image_deref_atomic_min ||
-   nir_intrinsic_image_deref_atomic_max ||
-   nir_intrinsic_image_deref_atomic_and ||
-   nir_intrinsic_image_deref_atomic_or ||
-   nir_intrinsic_image_deref_atomic_xor ||
-   nir_intrinsic_image_deref_atomic_exchange ||
-   nir_intrinsic_image_deref_atomic_comp_swap) {
+   if (instr->intrinsic == nir_intrinsic_image_deref_store ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_add ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_min ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_max ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_and ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_or ||
+   instr->intrinsic == nir_intrinsic_image_deref_atomic_xor ||
+   instr->intrinsic == 
nir_intrinsic_image_deref_atomic_exchange ||
+   instr->intrinsic == 
nir_intrinsic_image_deref_atomic_comp_swap) {
if (nir->info.stage == MESA_SHADER_FRAGMENT)
info->ps.writes_memory = true;
}
-- 
2.19.2

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

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

[bugzilla-daemon]

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

--- Comment #10 from MGG  ---
Created attachment 142819
  --> https://bugs.freedesktop.org/attachment.cgi?id=142819=edit
apitrace without crash

Sorry for the delay in my answer. I'm attaching a new apitrace that shows a run
where the game is shutdown properly (i.e. closed the game before it run out of
ram). Well, as expected it seems that they call glDeleteShader on exit. I count
15433 glCreateShaderObjectARB calls and 15429 glDeleteShader, so they
definitely leaks memory on 4 shaders (or they don't care to release it on
exit). In any case, is there something wrong with these numbers?

Finally, how useful would be to create an application that compiles all the
shaders that this game is using and check the memory usage for each one of
them? I mean, if doing that test I detect a high memory usage (lets say of more
than 1GB), that would mean that there is a problem on the shader compiler on
Mesa library?

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

[Mesa-dev] [PATCH] glsl: fix block member alignment validation for vec3

[Niklas Haas]

From: Niklas Haas 

Section 7.6.2.2 (Standard Uniform Block Layout) of the GL spec says:

The base offset of the first member of a structure is taken from the
aligned offset of the structure itself. The base offset of all other
structure members is derived by taking the offset of the last basic
machine unit consumed by the previous member and adding one.

The current code does not reflect this last sentence - it effectively
instead aligns up the next offset up to the alignment of the previous
member. This causes an issue in exactly one case:

layout(std140) uniform block {
layout(offset=0) vec3 var1;
layout(offset=12) float var2;
};

As per section 7.6.2.1 (Uniform Buffer Object Storage) and elsewhere, a
vec3 consumes 3 floats, i.e. 12 basic machine units. Therefore, `var1`
in the example above consumes units 0-11, with 12 being the first
available offset afterwards. However, before this commit, mesa
incorrectly assumes `var2` must start at offset=16 when using explicit
offsets, which results in a compile-time error. Without explicit
offsets, the shaders actually work fine, indicating that mesa is already
correctly aligning these fields internally. (Just not in the code that
handles explicit buffer offset parsing)

This patch should fix piglit tests:
ssbo-explicit-offset-vec3.vert
ubo-explicit-offset-vec3.vert

Also fixes a typo in one of the error cases.

Signed-off-by: Niklas Haas 
---
 src/compiler/glsl/ast_to_hir.cpp | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 9199230a7a..5c68c7fe1e 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -7396,7 +7396,7 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
   "alignment of %s", field_type->name);
   }
   fields[i].offset = qual_offset;
-  next_offset = glsl_align(qual_offset + size, align);
+  next_offset = qual_offset + size;
} else {
   _mesa_glsl_error(, state, "offset can only be used "
"with std430 and std140 layouts");
@@ -7417,19 +7417,19 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
   if (member_align == 0 ||
   member_align & (member_align - 1)) {
  _mesa_glsl_error(, state, "align layout qualifier "
-  "in not a power of 2");
+  "is not a power of 2");
   } else {
  fields[i].offset = glsl_align(offset, member_align);
- next_offset = glsl_align(fields[i].offset + size, align);
+ next_offset = fields[i].offset + size;
   }
}
 } else {
fields[i].offset = glsl_align(offset, expl_align);
-   next_offset = glsl_align(fields[i].offset + size, align);
+   next_offset = fields[i].offset + size;
 }
  } else if (!qual->flags.q.explicit_offset) {
 if (align != 0 && size != 0)
-   next_offset = glsl_align(next_offset + size, align);
+   next_offset = glsl_align(next_offset, align) + size;
  }
 
  /* From the ARB_enhanced_layouts spec:
-- 
2.19.2

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

Re: [Mesa-dev] last call for autotools

[Matt Turner]

On Fri, Dec 14, 2018 at 11:40 AM Ilia Mirkin  wrote:
>
> On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
> >
> > On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > > I second that, I voiced my concerns in a former thread, especially that
> > > so far this upcoming change has not been officially announced in the
> > > release notes or on mesa-user, and that I don't understand why it is so
> > > urgent to drop autotools when there is still someone who offers to
> > > maintain it and some who prefer to use it.
> >
> > It's because the objective is to have as few build systems as
> > necessary. This is an obvious first step and has been a stated goal
> > for more than a year. I'm surprised that you're surprised.
> >
> > Let's just make an external contrib repo and keep all the autotools
> > files there. Then Emil and company can continue having fun maintaining
> > autotools and all you'll need to do is rsync into the Mesa repo to use
> > autotools.
>
> So ... not last call for autotools? More like "railroad notification
> that the train is in motion"?

I wouldn't say that, but I think it is pretty apparent that people
haven't attempted to switch before some of these recent discussions.
So.. not sure how better to handle it.

> This kind of talk just causes everyone to entrench into their
> positions, so I'd rather avoid it. I'm not opposed to switching build
> systems in principle, but the current proposal is, in my and seemingly
> some other people's views, inadequate. Let's make it adequate before
> dropping the thing that works for everyone.

How can we make it adequate if people never even test the thing we've
been talking about deleting autotools in favor or for 15 months?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Aaron Watry]

Thanks Jan.

Reviewed-by: Aaron Watry 

On Thu, Dec 13, 2018 at 3:17 PM Jan Vesely  wrote:
>
> CodeGenOptions were moved to Basic.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
> Signed-off-by: Jan Vesely 
> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda..b91cb95a29 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -58,9 +58,14 @@
>  #include 
>
>  #include 
> -#include 
>  #include 
>
> +#if HAVE_LLVM >= 0x0800
> +#include 
> +#else
> +#include 
> +#endif
> +
>  namespace clover {
> namespace llvm {
>namespace compat {
> --
> 2.19.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109064] temp_comp_access::get_required_live_range: enclosing_scope_first_write is NULL

[bugzilla-daemon]

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

Alex Xu (Hello71)  changed:

   What|Removed |Added

 OS|All |Linux (All)
   Hardware|Other   |x86-64 (AMD64)
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/r600|glsl-compiler
 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org

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

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

[Roland Scheidegger]

Am 15.12.18 um 22:39 schrieb Ilia Mirkin:
> On Sat, Dec 15, 2018 at 4:12 PM Kenneth Graunke  wrote:
>>
>> On Saturday, December 15, 2018 9:10:46 AM PST Ilia Mirkin wrote:
>>> On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke  
>>> wrote:
 Gallium handles pipeline statistics queries as a single query
 (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
 Sometimes it's useful to refer to each of those values individually,
 rather than as a group.  To avoid hardcoding numbers, we define a new
 enum for each value.  Here, the name and enum value correspond to the
 index in the struct pipe_query_data_pipeline_statistics result.
>>>
>>> This later-in-the-series desire to be able to get just one value back
>>> from Gallium is an API change which would break any existing d3d1x
>>> state trackers. I realize you're not changing any drivers, but in my
>>> mind, it's preferable not to have ambiguous APIs where some drivers do
>>> one thing, others do another. For NVIDIA, we have to fetch the
>>> counters individually too, but we just do them all. It's ~free to do
>>> so, and we only do one set of synchronization for all of them.
>>
>> Yes, I suppose you're right in that the existing interface is designed
>> to return all 11 counters, and I'm essesntially implementing it wrong
>> because I didn't understand it.  It seemed like more of an inconsistency
>> in get_query_results vs get_query_results_resource, where one of those
>> knew what value to fetch, and the other did not.
> 
> I implemented the direct-write-to-resource logic, and there was no
> use-case for fetching them all, and you had to support a GL API where
> you had to be able to place each value into a precise location. I
> didn't want to alter the other API at the time as I didn't feel it
> hurt too much.
> 
>>
>> While it may not be that expensive to return 11 values, it isn't free.
>> The ARB_pipeline_statistics_query extension is designed to help port
>> D3D1x apps to OpenGL, but it provides GL-style single-value queries
>> rather than a single query that returns a struct.  So, if a D3D1x
>> translator naively tries to fetch all 11 counters, it would have to
>> do 11 different GL queries...each of which would map to Gallium's
>> return-all-11 interface...resulting in 121 counter reads.
> 
> Yep. Not ideal. (Which was never my argument anyways -- having a way
> to return a single value would definitely be better.)
> 
>>
>>> Anyways, I'd rather not have this ambiguous thing of "you could return
>>> some or all" situation. We should be more definitive. I'd recommend
>>> adding a PIPE_QUERY_PIPELINE_STATISTICS_ONE to differentiate [or
>>> PIPE_QUERY_PIPELINE_STATISTIC if you want to be clever and cause lots
>>> of typos], along with a CAP for support.
>>
>> I'd like to have an interface that better serves the in-tree state
>> trackers.  st/mesa wants 1 value, but it seems st/nine wants 2.  So
>> the single interface isn't ideal for nine, either, I guess.
> 
> Historically we've tried to avoid creating breakage for VMware where
> it wasn't necessary.
> 
>>
>> If people would prefer that we add a new query type and capability bit,
>> I can do that, but I probably won't bother implementing the all-11 mode
>> in my driver, then.
> 
> I think that's fine. It's already behind some PIPE_CAP. The state
> tracker could then do like
> 
> if ONE: get_one();
> if ALL: get_all(); select one();
> 
> Cheers,
> 
>   -ilia
> 

Yes, it's unfortunate d3d returns all values and GL returns just one.
Although FWIW outside of test suites we haven't really seen much use of
pipeline statistics queries, I'd guess that's the same for GL. Maybe
they are used for development/debugging/profiling of apps, but otherwise
it appears they don't see much (if any) use - as such they probably
aren't all that performance critical.

I think being explicit in the interface (in some way) if all or one
value is requested is a good idea (and not all drivers implementing
requesting all is ok).

(Patch 1 looks fine regradless to me fwiw.)

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

Re: [Mesa-dev] [PATCH] radv: don't set surf_index for stencil-only images

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 
On Fri, Dec 14, 2018 at 7:32 PM Rhys Perry  wrote:
>
> Fixes: f8d5b377c8b ('radv: set cb base tile swizzles for MRT speedups (v4)')
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108116
> Signed-off-by: Rhys Perry 
> ---
> Unfortunately I was not able to test this patch on a Polaris due to hardware
> issues. It fixed the deqp-vk tests mentioned in the bugzilla without 
> regressions
> on Vega though.
>
>  src/amd/vulkan/radv_image.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index 2cff4d5283..2bd74e202f 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -986,7 +986,7 @@ radv_image_create(VkDevice _device,
>
> image->shareable = vk_find_struct_const(pCreateInfo->pNext,
> 
> EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR) != NULL;
> -   if (!vk_format_is_depth(pCreateInfo->format) && !create_info->scanout 
> && !image->shareable) {
> +   if (!vk_format_is_depth_or_stencil(pCreateInfo->format) && 
> !create_info->scanout && !image->shareable) {
> image->info.surf_index = >image_mrt_offset_counter;
> }
>
> --
> 2.19.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 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

[Ilia Mirkin]

On Sat, Dec 15, 2018 at 4:12 PM Kenneth Graunke  wrote:
>
> On Saturday, December 15, 2018 9:10:46 AM PST Ilia Mirkin wrote:
> > On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke  
> > wrote:
> > > Gallium handles pipeline statistics queries as a single query
> > > (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> > > Sometimes it's useful to refer to each of those values individually,
> > > rather than as a group.  To avoid hardcoding numbers, we define a new
> > > enum for each value.  Here, the name and enum value correspond to the
> > > index in the struct pipe_query_data_pipeline_statistics result.
> >
> > This later-in-the-series desire to be able to get just one value back
> > from Gallium is an API change which would break any existing d3d1x
> > state trackers. I realize you're not changing any drivers, but in my
> > mind, it's preferable not to have ambiguous APIs where some drivers do
> > one thing, others do another. For NVIDIA, we have to fetch the
> > counters individually too, but we just do them all. It's ~free to do
> > so, and we only do one set of synchronization for all of them.
>
> Yes, I suppose you're right in that the existing interface is designed
> to return all 11 counters, and I'm essesntially implementing it wrong
> because I didn't understand it.  It seemed like more of an inconsistency
> in get_query_results vs get_query_results_resource, where one of those
> knew what value to fetch, and the other did not.

I implemented the direct-write-to-resource logic, and there was no
use-case for fetching them all, and you had to support a GL API where
you had to be able to place each value into a precise location. I
didn't want to alter the other API at the time as I didn't feel it
hurt too much.

>
> While it may not be that expensive to return 11 values, it isn't free.
> The ARB_pipeline_statistics_query extension is designed to help port
> D3D1x apps to OpenGL, but it provides GL-style single-value queries
> rather than a single query that returns a struct.  So, if a D3D1x
> translator naively tries to fetch all 11 counters, it would have to
> do 11 different GL queries...each of which would map to Gallium's
> return-all-11 interface...resulting in 121 counter reads.

Yep. Not ideal. (Which was never my argument anyways -- having a way
to return a single value would definitely be better.)

>
> > Anyways, I'd rather not have this ambiguous thing of "you could return
> > some or all" situation. We should be more definitive. I'd recommend
> > adding a PIPE_QUERY_PIPELINE_STATISTICS_ONE to differentiate [or
> > PIPE_QUERY_PIPELINE_STATISTIC if you want to be clever and cause lots
> > of typos], along with a CAP for support.
>
> I'd like to have an interface that better serves the in-tree state
> trackers.  st/mesa wants 1 value, but it seems st/nine wants 2.  So
> the single interface isn't ideal for nine, either, I guess.

Historically we've tried to avoid creating breakage for VMware where
it wasn't necessary.

>
> If people would prefer that we add a new query type and capability bit,
> I can do that, but I probably won't bother implementing the all-11 mode
> in my driver, then.

I think that's fine. It's already behind some PIPE_CAP. The state
tracker could then do like

if ONE: get_one();
if ALL: get_all(); select one();

Cheers,

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

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

[Kenneth Graunke]

On Saturday, December 15, 2018 9:10:46 AM PST Ilia Mirkin wrote:
> On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke  wrote:
> > Gallium handles pipeline statistics queries as a single query
> > (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> > Sometimes it's useful to refer to each of those values individually,
> > rather than as a group.  To avoid hardcoding numbers, we define a new
> > enum for each value.  Here, the name and enum value correspond to the
> > index in the struct pipe_query_data_pipeline_statistics result.
> 
> This later-in-the-series desire to be able to get just one value back
> from Gallium is an API change which would break any existing d3d1x
> state trackers. I realize you're not changing any drivers, but in my
> mind, it's preferable not to have ambiguous APIs where some drivers do
> one thing, others do another. For NVIDIA, we have to fetch the
> counters individually too, but we just do them all. It's ~free to do
> so, and we only do one set of synchronization for all of them.

Yes, I suppose you're right in that the existing interface is designed
to return all 11 counters, and I'm essesntially implementing it wrong
because I didn't understand it.  It seemed like more of an inconsistency
in get_query_results vs get_query_results_resource, where one of those
knew what value to fetch, and the other did not.

While it may not be that expensive to return 11 values, it isn't free.
The ARB_pipeline_statistics_query extension is designed to help port
D3D1x apps to OpenGL, but it provides GL-style single-value queries
rather than a single query that returns a struct.  So, if a D3D1x
translator naively tries to fetch all 11 counters, it would have to
do 11 different GL queries...each of which would map to Gallium's
return-all-11 interface...resulting in 121 counter reads.

> Anyways, I'd rather not have this ambiguous thing of "you could return
> some or all" situation. We should be more definitive. I'd recommend
> adding a PIPE_QUERY_PIPELINE_STATISTICS_ONE to differentiate [or
> PIPE_QUERY_PIPELINE_STATISTIC if you want to be clever and cause lots
> of typos], along with a CAP for support.

I'd like to have an interface that better serves the in-tree state
trackers.  st/mesa wants 1 value, but it seems st/nine wants 2.  So
the single interface isn't ideal for nine, either, I guess.

If people would prefer that we add a new query type and capability bit,
I can do that, but I probably won't bother implementing the all-11 mode
in my driver, then.

--Ken


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

Re: [Mesa-dev] [PATCH 3/3] nv50/ir: convert slct with boolean result to set

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 6:12 PM Karol Herbst  wrote:
>
> From: Karol Herbst 
>
> helps mainly feral ported games
>
> changes in shader-db:
> total instructions in shared programs : 7565661 -> 7545812 (-0.26%)
> total gprs used in shared programs: 797213 -> 797088 (-0.02%)
> total shared used in shared programs  : 639636 -> 639636 (0.00%)
> total local used in shared programs   : 24648 -> 24648 (0.00%)
> total bytes used in shared programs   : 80806160 -> 80594056 (-0.26%)
>
> local sharedgpr   inst  bytes
> helped  0  0103   5049   5049
>   hurt  0  0 29  0  0
>
> Signed-off-by: Karol Herbst 
> ---
>  .../nouveau/codegen/nv50_ir_peephole.cpp  | 50 +++
>  1 file changed, 50 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index 37e9edc49f4..b62dee675ce 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -372,6 +372,8 @@ private:
> void expr(Instruction *, ImmediateValue&, ImmediateValue&, 
> ImmediateValue&);
> /* true if i was deleted */
> bool opnd(Instruction *i, ImmediateValue&, int s);
> +   /* 3 srcs where 1st and 2nd are immediates */
> +   void opnd(Instruction *, ImmediateValue&, ImmediateValue&);
> void opnd3(Instruction *, ImmediateValue&);
>
> void unary(Instruction *, const ImmediateValue&);
> @@ -432,6 +434,10 @@ ConstantFolding::visit(BasicBlock *bb)
>}
>if (i->srcExists(2) && i->src(2).getImmediate(src2))
>   opnd3(i, src2);
> +  else
> +  if (i->srcExists(2) &&
> +  i->src(0).getImmediate(src0) && i->src(1).getImmediate(src1))
> + opnd(i, src0, src1);
> }
> return true;
>  }
> @@ -935,6 +941,50 @@ ConstantFolding::tryCollapseChainedMULs(Instruction 
> *mul2,
> }
>  }
>
> +void
> +ConstantFolding::opnd(Instruction *i, ImmediateValue , ImmediateValue 
> )
> +{
> +   const Storage  = imm0.reg;
> +   const Storage  = imm1.reg;
> +
> +   switch (i->op) {
> +   case OP_SLCT: {
> +  CmpInstruction *slct = i->asCmp();
> +  if (a.data.u32 == 0x && b.data.u32 == 0x0) {
> + slct->setSrc(0, slct->getSrc(2));
> + slct->setSrc(2, NULL);
> + slct->dType = TYPE_U32;
> + slct->op = OP_SET;
> +  }
> +  else if (a.data.u32 == 0x3f80 && b.data.u32 == 0x0) {
> + slct->setSrc(0, slct->getSrc(2));
> + slct->setSrc(2, NULL);
> + slct->dType = TYPE_F32;
> + slct->op = OP_SET;
> +  }
> +  else if (a.data.u32 == 0x0 && b.data.u32 == 0x) {
> + slct->swapSources(0, 1);
> + slct->setSrc(0, slct->getSrc(2));
> + slct->setSrc(2, NULL);
> + slct->dType = TYPE_U32;
> + slct->setCondition(inverseCondCode(slct->getCondition()));
> + slct->op = OP_SET;
> +  }
> +  else if (a.data.u32 == 0x0 && b.data.u32 == 0x3f80) {
> + slct->swapSources(0, 1);
> + slct->setSrc(0, slct->getSrc(2));
> + slct->setSrc(2, NULL);
> + slct->dType = TYPE_F32;
> + slct->setCondition(inverseCondCode(slct->getCondition()));
> + slct->op = OP_SET;
> +  }

You could make the code a little less repetitive by doing something like:

bool swap = false;
if (a.data.u32 == 0x0) {
  std::swap(a, b);
  swap = true;
}
if (b.data.u32 != 0x0)
  break;

if (a.data.f32 == 1.0)
  slct->dType = TYPE_F32
else if (a.data.u32 == 0x)
  slct->dType = TYPE_U32;
else
  break;

if (swap)
  slct->swapSources(0, 1);
slct->setSrc(0, ...);
slct->setSrc(2, NULL);
if (swap)
  slct->setCondition(...);

slct->op = OP_SET;

Your call.

> +  break;
> +   }
> +   default:
> +  break;
> +   }
> +}
> +
>  void
>  ConstantFolding::opnd3(Instruction *i, ImmediateValue )
>  {
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] nv50/ir: optimize slct(b, c, set(a, 0)) to slct(b, c, a)

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 6:12 PM Karol Herbst  wrote:
>
> From: Karol Herbst 
>
> helps mainly feral ported games
>
> shader-db changes:
> total instructions in shared programs : 7614782 -> 7565661 (-0.65%)
> total gprs used in shared programs: 798045 -> 797213 (-0.10%)
> total shared used in shared programs  : 639636 -> 639636 (0.00%)
> total local used in shared programs   : 24648 -> 24648 (0.00%)
> total bytes used in shared programs   : 81330696 -> 80806160 (-0.64%)
>
> local sharedgpr   inst  bytes
> helped  0  0701   7940   7940
>   hurt  0  0 44  4  4
>
> Signed-off-by: Karol Herbst 
> ---
>  .../nouveau/codegen/nv50_ir_peephole.cpp  | 47 +--
>  1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index a8bd4f868bf..37e9edc49f4 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -1763,7 +1763,8 @@ private:
> bool tryADDToMADOrSAD(Instruction *, operation toOp);
> void handleMINMAX(Instruction *);
> void handleRCP(Instruction *);
> -   void handleSLCT(Instruction *);
> +   void handleSLCT(CmpInstruction *);
> +   bool tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set);

SLCT_SET or SET_SLCT. Otherwise it all runs together.

> void handleLOGOP(Instruction *);
> void handleCVT_NEG(Instruction *);
> void handleCVT_CVT(Instruction *);
> @@ -1956,8 +1957,12 @@ AlgebraicOpt::handleRCP(Instruction *rcp)
>  }
>
>  void
> -AlgebraicOpt::handleSLCT(Instruction *slct)
> +AlgebraicOpt::handleSLCT(CmpInstruction *slct)
>  {
> +   Instruction *insn = slct->getSrc(2)->getInsn();
> +   while(insn && insn->op == OP_SET && tryMergeSLCTSET(slct, insn->asCmp())) 
> {

while (

> +  insn = slct->getSrc(2)->getInsn();
> +   }
> if (slct->getSrc(2)->reg.file == FILE_IMMEDIATE) {
>if (slct->getSrc(2)->asImm()->compare(slct->asCmp()->setCond, 0.0f))
>   slct->setSrc(0, slct->getSrc(1));
> @@ -1970,6 +1975,42 @@ AlgebraicOpt::handleSLCT(Instruction *slct)
> slct->setSrc(2, NULL);
>  }
>
> +bool
> +AlgebraicOpt::tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set)
> +{
> +   assert(slct->op == OP_SLCT && set->op == OP_SET);
> +
> +   if (typeSizeof(set->sType) != 4)
> +  return false;
> +
> +   CondCode setCC = set->getCondition();
> +   CondCode slctCC = slct->getCondition();
> +   CondCode newCC = setCC;
> +
> +   if (slctCC != CC_NE && slctCC != CC_EQ)
> +  return false;
> +
> +   ImmediateValue imm0;
> +   int s;
> +
> +   if (set->src(0).getImmediate(imm0) && imm0.isInteger(0))
> +  s = 1;
> +   else if (set->src(1).getImmediate(imm0) && imm0.isInteger(0))
> +  s = 0;
> +   else
> +  return false;
> +
> +   slct->setSrc(2, set->getSrc(s));
> +   if (s)
> +  newCC = reverseCondCode(newCC);
> +   if (slctCC == CC_EQ)
> +  newCC = inverseCondCode(newCC);

While not wrong, this is all pretty confusing. I won't require it, but
I'd like to encourage you to write a paragraph about the theory about
wtf is going on here.

> +
> +   slct->sType = set->sType;
> +   slct->setCondition(newCC);
> +   return true;
> +}
> +
>  void
>  AlgebraicOpt::handleLOGOP(Instruction *logop)
>  {
> @@ -2340,7 +2381,7 @@ AlgebraicOpt::visit(BasicBlock *bb)
>   handleMINMAX(i);
>   break;
>case OP_SLCT:
> - handleSLCT(i);
> + handleSLCT(i->asCmp());
>   break;
>case OP_AND:
>case OP_OR:
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: make it possible to build etnaviv's cmdline compiler

[Christian Gmeiner]

Hi Dylan

Am Fr., 14. Dez. 2018 um 20:13 Uhr schrieb Dylan Baker :
>
> Quoting Christian Gmeiner (2018-12-13 12:07:23)
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  meson.build | 2 +-
> >  meson_options.txt   | 2 +-
> >  src/gallium/drivers/etnaviv/meson.build | 3 ++-
> >  3 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index fe647f682c..f516780115 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -57,7 +57,7 @@ with_osmesa = get_option('osmesa')
> >  with_swr_arches = get_option('swr-arches')
> >  with_tools = get_option('tools')
> >  if with_tools.contains('all')
> > -  with_tools = ['freedreno', 'glsl', 'intel', 'nir', 'nouveau', 'xvmc']
> > +  with_tools = ['etnaviv', 'freedreno', 'glsl', 'intel', 'nir', 'nouveau', 
> > 'xvmc']
> >  endif
> >
> >  dri_drivers_path = get_option('dri-drivers-path')
> > diff --git a/meson_options.txt b/meson_options.txt
> > index a1d5ab0e18..005356b14c 100644
> > --- a/meson_options.txt
> > +++ b/meson_options.txt
> > @@ -301,7 +301,7 @@ option(
> >'tools',
> >type : 'array',
> >value : [],
> > -  choices : ['freedreno', 'glsl', 'intel', 'intel-ui', 'nir', 'nouveau', 
> > 'xvmc', 'all'],
> > +  choices : ['etnaviv', 'freedreno', 'glsl', 'intel', 'intel-ui', 'nir', 
> > 'nouveau', 'xvmc', 'all'],
> >description : 'List of tools to build. (Note: `intel-ui` selects 
> > `intel`)',
> >  )
> >  option(
> > diff --git a/src/gallium/drivers/etnaviv/meson.build 
> > b/src/gallium/drivers/etnaviv/meson.build
> > index 1733024ac9..63553dec51 100644
> > --- a/src/gallium/drivers/etnaviv/meson.build
> > +++ b/src/gallium/drivers/etnaviv/meson.build
> > @@ -101,7 +101,8 @@ etnaviv_compiler = executable(
> >include_directories : [inc_include, inc_src, inc_gallium, 
> > inc_gallium_aux],
> >link_with : [libmesa_util, libgallium, libetnaviv],
> >dependencies : [dep_libdrm_etnaviv],
> > -  build_by_default : false,
> > +  build_by_default : with_tools.contains('etnaviv'),
> > +  install : with_tools.contains('etnaviv'),
> >  )
> >
> >  driver_etnaviv = declare_dependency(
> > --
> > 2.19.2
> >
>
> You technically can build it already, `ninja
> src/gallium/drivers/etnaviv/etnaviv_compiler` should do the trick. This patch 
> is
> obviously simpler and easier to use, and is in line with how other tools in 
> mesa
> work, but can we change the commit message to something like:
>
> meson: add etnaviv to the tools option
>
> Or something similar.
>

Sounds fine to me. Btw thanks for the meson trick - I was not aware of it.

> with that:
> Reviewed-by: Dylan Baker 


-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH] EGL/mesa: Initial write up fot MESA_query_driver

[Veluri Mithun]

Hi Everyone,

we can obtain DRM device file from eglQueryDeviceStringEXT fun of
EGL_EXT_device_query extension. But, how to retrieve name, configs from
that?

Can we get the name of the matched driver for a particular display from any
of the EGLDriver->API ?? (EGL API dispatch table)

And looking at x11 implementation of getDrvierConfig, I finally reached
this file
https://gitlab.freedesktop.org/mesa/mesa/blob/master/include/GL/internal/dri_interface.h#L1828
and unable to find the implementation of that getXml function. Can we use
the same function here?

Please let me know what do you think about this.

Thanks,
Veluri.

On Sat, Dec 15, 2018 at 10:25 PM Veluri Mithun 
wrote:

> Signed-off-by: Veluri Mithun 
> ---
>  docs/specs/EGL_MESA_query_driver.txt | 54 
>  1 file changed, 54 insertions(+)
>  create mode 100644 docs/specs/EGL_MESA_query_driver.txt
>
> diff --git a/docs/specs/EGL_MESA_query_driver.txt
> b/docs/specs/EGL_MESA_query_driver.txt
> new file mode 100644
> index 00..315f02920f
> --- /dev/null
> +++ b/docs/specs/EGL_MESA_query_driver.txt
> @@ -0,0 +1,54 @@
> +Name
> +
> +MESA_query_driver
> +
> +Name Strings
> +
> +EGL_MESA_query_driver
> +
> +Contact
> +
> +Rob Clark  
> +Nicolai Hähnle 
> +
> +Contibutors
> +
> +Veluri Mithun 
> +
> +Status
> +
> +XXX - Not complete yet!!! (draft)
> +
> +Version
> +
> +Version 1, 2018-11-05
> +
> +Number
> +
> +EGL Extension ###
> +
> +Dependencies
> +
> +EGL 1.4 is required.
> +
> +Overview
> +
> +When an application had to query the name of a DRI driver and for
> +obtaining driver's option list (UTF-8 encoded XML) of a DRI
> +driver the below functions are useful.
> +
> +New Procedures and Functions
> +
> +const char* eglGetDriverConfig(EGLDisplay *dpy, EGLDeviceEXT device,
> +   const char *driverName);
> +const char* eglGetDisplayDriverName(EGLDisplay *dpy, EGLDeviceEXT
> device);
> +
> +New Tokens
> +
> +
> +
> +Issues
> +
> +
> +
> +Revision History
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

[Ilia Mirkin]

On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke  wrote:
> Gallium handles pipeline statistics queries as a single query
> (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> Sometimes it's useful to refer to each of those values individually,
> rather than as a group.  To avoid hardcoding numbers, we define a new
> enum for each value.  Here, the name and enum value correspond to the
> index in the struct pipe_query_data_pipeline_statistics result.

This later-in-the-series desire to be able to get just one value back
from Gallium is an API change which would break any existing d3d1x
state trackers. I realize you're not changing any drivers, but in my
mind, it's preferable not to have ambiguous APIs where some drivers do
one thing, others do another. For NVIDIA, we have to fetch the
counters individually too, but we just do them all. It's ~free to do
so, and we only do one set of synchronization for all of them.

Anyways, I'd rather not have this ambiguous thing of "you could return
some or all" situation. We should be more definitive. I'd recommend
adding a PIPE_QUERY_PIPELINE_STATISTICS_ONE to differentiate [or
PIPE_QUERY_PIPELINE_STATISTIC if you want to be clever and cause lots
of typos], along with a CAP for support.

>
> Cc: Roland Scheidegger 
> ---
>  src/gallium/include/pipe/p_defines.h| 17 +
>  src/mesa/state_tracker/st_cb_queryobj.c | 22 +++---
>  2 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index 6d96f1ccb5b..21005955a36 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -568,6 +568,23 @@ enum pipe_query_type {
> PIPE_QUERY_DRIVER_SPECIFIC = 256,
>  };
>
> +/**
> + * Index for PIPE_QUERY_PIPELINE_STATISTICS subqueries.
> + */
> +enum pipe_statistics_query_index {
> +   PIPE_STAT_QUERY_IA_VERTICES,
> +   PIPE_STAT_QUERY_IA_PRIMITIVES,
> +   PIPE_STAT_QUERY_VS_INVOCATIONS,
> +   PIPE_STAT_QUERY_GS_INVOCATIONS,
> +   PIPE_STAT_QUERY_GS_PRIMITIVES,
> +   PIPE_STAT_QUERY_C_INVOCATIONS,
> +   PIPE_STAT_QUERY_C_PRIMITIVES,
> +   PIPE_STAT_QUERY_PS_INVOCATIONS,
> +   PIPE_STAT_QUERY_HS_INVOCATIONS,
> +   PIPE_STAT_QUERY_DS_INVOCATIONS,
> +   PIPE_STAT_QUERY_CS_INVOCATIONS,
> +};
> +
>  /**
>   * Conditional rendering modes
>   */
> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c 
> b/src/mesa/state_tracker/st_cb_queryobj.c
> index 69e6004c3f1..82f53243336 100644
> --- a/src/mesa/state_tracker/st_cb_queryobj.c
> +++ b/src/mesa/state_tracker/st_cb_queryobj.c
> @@ -386,37 +386,37 @@ st_StoreQueryResult(struct gl_context *ctx, struct 
> gl_query_object *q,
> } else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
>switch (q->Target) {
>case GL_VERTICES_SUBMITTED_ARB:
> - index = 0;
> + index = PIPE_STAT_QUERY_IA_VERTICES;
>   break;
>case GL_PRIMITIVES_SUBMITTED_ARB:
> - index = 1;
> + index = PIPE_STAT_QUERY_IA_PRIMITIVES;
>   break;
>case GL_VERTEX_SHADER_INVOCATIONS_ARB:
> - index = 2;
> + index = PIPE_STAT_QUERY_VS_INVOCATIONS;
>   break;
>case GL_GEOMETRY_SHADER_INVOCATIONS:
> - index = 3;
> + index = PIPE_STAT_QUERY_GS_INVOCATIONS;
>   break;
>case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
> - index = 4;
> + index = PIPE_STAT_QUERY_GS_PRIMITIVES;
>   break;
>case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
> - index = 5;
> + index = PIPE_STAT_QUERY_C_INVOCATIONS;
>   break;
>case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
> - index = 6;
> + index = PIPE_STAT_QUERY_C_PRIMITIVES;
>   break;
>case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
> - index = 7;
> + index = PIPE_STAT_QUERY_PS_INVOCATIONS;
>   break;
>case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
> - index = 8;
> + index = PIPE_STAT_QUERY_HS_INVOCATIONS;
>   break;
>case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
> - index = 9;
> + index = PIPE_STAT_QUERY_DS_INVOCATIONS;
>   break;
>case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
> - index = 10;
> + index = PIPE_STAT_QUERY_CS_INVOCATIONS;
>   break;
>default:
>   unreachable("Unexpected target");
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #3 from Kai  ---
I stumbled across this issue as well and didn't check the bug tracker but
immediately prepared [0]. That patch should fix this problem without leaving
older LLVM versions out in the cold.


[0] 

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

[Mesa-dev] [PATCH] EGL/mesa: Initial write up fot MESA_query_driver

[Veluri Mithun]

Signed-off-by: Veluri Mithun 
---
 docs/specs/EGL_MESA_query_driver.txt | 54 
 1 file changed, 54 insertions(+)
 create mode 100644 docs/specs/EGL_MESA_query_driver.txt

diff --git a/docs/specs/EGL_MESA_query_driver.txt 
b/docs/specs/EGL_MESA_query_driver.txt
new file mode 100644
index 00..315f02920f
--- /dev/null
+++ b/docs/specs/EGL_MESA_query_driver.txt
@@ -0,0 +1,54 @@
+Name
+
+MESA_query_driver
+
+Name Strings
+
+EGL_MESA_query_driver
+
+Contact
+
+Rob Clark  
+Nicolai H??hnle 
+
+Contibutors
+
+Veluri Mithun 
+
+Status
+
+XXX - Not complete yet!!! (draft)
+
+Version
+
+Version 1, 2018-11-05
+
+Number
+
+EGL Extension ###
+
+Dependencies
+
+EGL 1.4 is required.
+
+Overview
+
+When an application had to query the name of a DRI driver and for
+obtaining driver's option list (UTF-8 encoded XML) of a DRI
+driver the below functions are useful.
+
+New Procedures and Functions
+
+const char* eglGetDriverConfig(EGLDisplay *dpy, EGLDeviceEXT device,
+   const char *driverName);
+const char* eglGetDisplayDriverName(EGLDisplay *dpy, EGLDeviceEXT device);
+
+New Tokens
+
+
+
+Issues
+
+
+
+Revision History
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

[Kenneth Graunke]

Gallium handles pipeline statistics queries as a single query
(PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
Sometimes it's useful to refer to each of those values individually,
rather than as a group.  To avoid hardcoding numbers, we define a new
enum for each value.  Here, the name and enum value correspond to the
index in the struct pipe_query_data_pipeline_statistics result.

Cc: Roland Scheidegger 
---
 src/gallium/include/pipe/p_defines.h| 17 +
 src/mesa/state_tracker/st_cb_queryobj.c | 22 +++---
 2 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 6d96f1ccb5b..21005955a36 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -568,6 +568,23 @@ enum pipe_query_type {
PIPE_QUERY_DRIVER_SPECIFIC = 256,
 };
 
+/**
+ * Index for PIPE_QUERY_PIPELINE_STATISTICS subqueries.
+ */
+enum pipe_statistics_query_index {
+   PIPE_STAT_QUERY_IA_VERTICES,
+   PIPE_STAT_QUERY_IA_PRIMITIVES,
+   PIPE_STAT_QUERY_VS_INVOCATIONS,
+   PIPE_STAT_QUERY_GS_INVOCATIONS,
+   PIPE_STAT_QUERY_GS_PRIMITIVES,
+   PIPE_STAT_QUERY_C_INVOCATIONS,
+   PIPE_STAT_QUERY_C_PRIMITIVES,
+   PIPE_STAT_QUERY_PS_INVOCATIONS,
+   PIPE_STAT_QUERY_HS_INVOCATIONS,
+   PIPE_STAT_QUERY_DS_INVOCATIONS,
+   PIPE_STAT_QUERY_CS_INVOCATIONS,
+};
+
 /**
  * Conditional rendering modes
  */
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c 
b/src/mesa/state_tracker/st_cb_queryobj.c
index 69e6004c3f1..82f53243336 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -386,37 +386,37 @@ st_StoreQueryResult(struct gl_context *ctx, struct 
gl_query_object *q,
} else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
   switch (q->Target) {
   case GL_VERTICES_SUBMITTED_ARB:
- index = 0;
+ index = PIPE_STAT_QUERY_IA_VERTICES;
  break;
   case GL_PRIMITIVES_SUBMITTED_ARB:
- index = 1;
+ index = PIPE_STAT_QUERY_IA_PRIMITIVES;
  break;
   case GL_VERTEX_SHADER_INVOCATIONS_ARB:
- index = 2;
+ index = PIPE_STAT_QUERY_VS_INVOCATIONS;
  break;
   case GL_GEOMETRY_SHADER_INVOCATIONS:
- index = 3;
+ index = PIPE_STAT_QUERY_GS_INVOCATIONS;
  break;
   case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
- index = 4;
+ index = PIPE_STAT_QUERY_GS_PRIMITIVES;
  break;
   case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
- index = 5;
+ index = PIPE_STAT_QUERY_C_INVOCATIONS;
  break;
   case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
- index = 6;
+ index = PIPE_STAT_QUERY_C_PRIMITIVES;
  break;
   case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
- index = 7;
+ index = PIPE_STAT_QUERY_PS_INVOCATIONS;
  break;
   case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
- index = 8;
+ index = PIPE_STAT_QUERY_HS_INVOCATIONS;
  break;
   case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
- index = 9;
+ index = PIPE_STAT_QUERY_DS_INVOCATIONS;
  break;
   case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
- index = 10;
+ index = PIPE_STAT_QUERY_CS_INVOCATIONS;
  break;
   default:
  unreachable("Unexpected target");
-- 
2.19.1

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

[Mesa-dev] [PATCH 3/3] st/mesa: Support an array for pipeline statistics query results.

[Kenneth Graunke]

We can now simply index into an array of uint64_t values to read or
write the result, based on the query's index.  The structure is still
available and is interchangeable.

Cc: Roland Scheidegger 
---
 src/gallium/include/pipe/p_defines.h|  3 ++
 src/mesa/state_tracker/st_cb_queryobj.c | 55 ++---
 2 files changed, 15 insertions(+), 43 deletions(-)

This also lets me replace a 35 line switch statement in iris with

   result->pipeline_statistics_array[q->index] = q->result;

which is a bit nicer.

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 21005955a36..817d4787f06 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -1082,6 +1082,9 @@ union pipe_query_result
/* PIPE_QUERY_PIPELINE_STATISTICS */
struct pipe_query_data_pipeline_statistics pipeline_statistics;
 
+   /* PIPE_QUERY_PIPELINE_STATISTICS, but as an array of values */
+   uint64_t pipeline_statistics_array[11];
+
/* batch queries (variable length) */
union pipe_numeric_type_union batch[1];
 };
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c 
b/src/mesa/state_tracker/st_cb_queryobj.c
index a0ed309c2b3..81d63bb0401 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -259,52 +259,21 @@ get_query_result(struct pipe_context *pipe,
if (!pipe->get_query_result(pipe, stq->pq, wait, ))
   return FALSE;
 
-   switch (stq->base.Target) {
-   case GL_VERTICES_SUBMITTED_ARB:
-  stq->base.Result = data.pipeline_statistics.ia_vertices;
-  break;
-   case GL_PRIMITIVES_SUBMITTED_ARB:
-  stq->base.Result = data.pipeline_statistics.ia_primitives;
-  break;
-   case GL_VERTEX_SHADER_INVOCATIONS_ARB:
-  stq->base.Result = data.pipeline_statistics.vs_invocations;
-  break;
-   case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
-  stq->base.Result = data.pipeline_statistics.hs_invocations;
-  break;
-   case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
-  stq->base.Result = data.pipeline_statistics.ds_invocations;
-  break;
-   case GL_GEOMETRY_SHADER_INVOCATIONS:
-  stq->base.Result = data.pipeline_statistics.gs_invocations;
+   switch (stq->type) {
+   case PIPE_QUERY_PIPELINE_STATISTICS: {
+  unsigned index = target_to_index(>base);
+  assert(index < 11);
+  stq->base.Result = data.pipeline_statistics_array[index];
   break;
-   case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
-  stq->base.Result = data.pipeline_statistics.gs_primitives;
-  break;
-   case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
-  stq->base.Result = data.pipeline_statistics.ps_invocations;
-  break;
-   case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
-  stq->base.Result = data.pipeline_statistics.cs_invocations;
-  break;
-   case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
-  stq->base.Result = data.pipeline_statistics.c_invocations;
-  break;
-   case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
-  stq->base.Result = data.pipeline_statistics.c_primitives;
+   }
+   case PIPE_QUERY_OCCLUSION_PREDICATE:
+   case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
+   case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
+  stq->base.Result = !!data.b;
   break;
default:
-  switch (stq->type) {
-  case PIPE_QUERY_OCCLUSION_PREDICATE:
-  case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
-  case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
-  case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
- stq->base.Result = !!data.b;
- break;
-  default:
- stq->base.Result = data.u64;
- break;
-  }
+  stq->base.Result = data.u64;
   break;
}
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/3] st/mesa: Pass index to pipe->create_query() for statistics queries.

[Kenneth Graunke]

GL exposes separate queries for each pipeline statistics counter,
each of which return a single value.  Gallium (and D3D) treats them
as a single query, PIPE_QUERY_PIPELINE_STATISTICS, which returns 11
values.  Radeon hardware appears to query them all as a group, and
the CPU-side hook, pipe->get_query_result() simply writes them all,
so st/mesa can return whichever one GL actually desired.  The GPU-side
hook, pipe->get_query_result_resource(), takes an index so it knows
which value to write to the buffer.

On Intel hardware, each individual pipeline statistics value is handled
as a separate counter and query.  We can query each individually, and
that is more efficient than querying all 11 counters each time.  But,
we need pipe->get_query_result() to know which one to return.

To handle this, we pass the index into pipe->create_query(), which
was previously always 0 for these queries.  Drivers which return all
of the counters as a group can simply ignore it; drivers querying one
at a time can use it to distinguish between the counters.

v2: Use an enum instead of hardcoding numbers (suggested by Roland).

Cc: Roland Scheidegger 
---
 src/mesa/state_tracker/st_cb_queryobj.c | 75 -
 1 file changed, 35 insertions(+), 40 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_queryobj.c 
b/src/mesa/state_tracker/st_cb_queryobj.c
index 82f53243336..a0ed309c2b3 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -88,6 +88,39 @@ st_DeleteQuery(struct gl_context *ctx, struct 
gl_query_object *q)
free(stq);
 }
 
+static int
+target_to_index(const struct gl_query_object *q)
+{
+   switch (q->Target) {
+   case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  return q->Stream;
+   case GL_VERTICES_SUBMITTED_ARB:
+  return PIPE_STAT_QUERY_IA_VERTICES;
+   case GL_PRIMITIVES_SUBMITTED_ARB:
+  return PIPE_STAT_QUERY_IA_PRIMITIVES;
+   case GL_VERTEX_SHADER_INVOCATIONS_ARB:
+  return PIPE_STAT_QUERY_VS_INVOCATIONS;
+   case GL_GEOMETRY_SHADER_INVOCATIONS:
+  return PIPE_STAT_QUERY_GS_INVOCATIONS;
+   case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
+  return PIPE_STAT_QUERY_GS_PRIMITIVES;
+   case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
+  return PIPE_STAT_QUERY_C_INVOCATIONS;
+   case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
+  return PIPE_STAT_QUERY_C_PRIMITIVES;
+   case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
+  return PIPE_STAT_QUERY_PS_INVOCATIONS;
+   case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
+  return PIPE_STAT_QUERY_HS_INVOCATIONS;
+   case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
+  return PIPE_STAT_QUERY_DS_INVOCATIONS;
+   case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
+  return PIPE_STAT_QUERY_CS_INVOCATIONS;
+   default:
+  return 0;
+   }
+}
 
 static void
 st_BeginQuery(struct gl_context *ctx, struct gl_query_object *q)
@@ -164,7 +197,7 @@ st_BeginQuery(struct gl_context *ctx, struct 
gl_query_object *q)
  ret = pipe->end_query(pipe, stq->pq_begin);
} else {
   if (!stq->pq) {
- stq->pq = pipe->create_query(pipe, type, q->Stream);
+ stq->pq = pipe->create_query(pipe, type, target_to_index(q));
  stq->type = type;
   }
   if (stq->pq)
@@ -383,46 +416,8 @@ st_StoreQueryResult(struct gl_context *ctx, struct 
gl_query_object *q,
 
if (pname == GL_QUERY_RESULT_AVAILABLE) {
   index = -1;
-   } else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
-  switch (q->Target) {
-  case GL_VERTICES_SUBMITTED_ARB:
- index = PIPE_STAT_QUERY_IA_VERTICES;
- break;
-  case GL_PRIMITIVES_SUBMITTED_ARB:
- index = PIPE_STAT_QUERY_IA_PRIMITIVES;
- break;
-  case GL_VERTEX_SHADER_INVOCATIONS_ARB:
- index = PIPE_STAT_QUERY_VS_INVOCATIONS;
- break;
-  case GL_GEOMETRY_SHADER_INVOCATIONS:
- index = PIPE_STAT_QUERY_GS_INVOCATIONS;
- break;
-  case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
- index = PIPE_STAT_QUERY_GS_PRIMITIVES;
- break;
-  case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
- index = PIPE_STAT_QUERY_C_INVOCATIONS;
- break;
-  case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
- index = PIPE_STAT_QUERY_C_PRIMITIVES;
- break;
-  case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
- index = PIPE_STAT_QUERY_PS_INVOCATIONS;
- break;
-  case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
- index = PIPE_STAT_QUERY_HS_INVOCATIONS;
- break;
-  case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
- index = PIPE_STAT_QUERY_DS_INVOCATIONS;
- break;
-  case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
- index = PIPE_STAT_QUERY_CS_INVOCATIONS;
- break;
-  default:
- unreachable("Unexpected target");
-  }
} else {
-  index = 0;
+  index = target_to_index(q);
}
 
pipe->get_query_result_resource(pipe, stq->pq, wait, 

Re: [Mesa-dev] [PATCH] clover: Fix include of CodeGenOptions.h, upstream moved it in r348827

[Kai Wasserbäch]

Hey,
I'm just noticing, that there's also a bug report for this, so please add

 Bugzilla: https://bugs.freedesktop.org/109039

before commiting this, in case you accept it (I don't have commit access).

Cheers,
Kai


Kai Wasserbäch wrote on 14.12.18 17:26:
> Signed-off-by: Kai Wasserbäch 
> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda..9c5b9d8917 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -58,7 +58,11 @@
>  #include 
>  
>  #include 
> +#if HAVE_LLVM >= 0x0800
> +#include 
> +#else
>  #include 
> +#endif
>  #include 
>  
>  namespace clover {



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