Re: [Mesa-dev] i965: Fast color clear for mipmapped and arrayed

[Pohjolainen, Topi]

On Tue, Oct 11, 2016 at 10:26:32PM +0300, Topi Pohjolainen wrote:
> The entire series is mostly bookkeeping changes. It switches to track
> color and state per slice instead of per miptree (such as we already
> do for depth and hiz).
> 
> Patch 22 is still work in progress. We have all the details already
> in ISL and I would somehow like to utilize that instead. Current
> patch overallocates in some cases but should be safe though.
> 
> I will follow-up with some performance numbers.

On SKL i5k (lossless compression):

Manhattan 3.0: 2.43196% +/- 0.650327%
Manhattan 3.0 off: 2.70886% +/- 0.0502046%
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2.1] i965/vec4: teach register coalescing about 64-bit

[Iago Toral Quiroga]

Specifically, at least for now, we don't want to deal with the fact that
channel sizes for fp64 instructions are twice the size, so prevent
coalescing from instructions with a different type size.

Also, we should check that if we are coalescing a register from another
MOV we should be writing the same amount of data in both operations, otherwise
we end up wiring more or less than the original instruction. This can happen,
for example, when we have split fp64 MOVs with an exec size of 4 that only
write one register each and then a MOV with exec size of 8 that reads both.
We want to avoid the pass to think that it can coalesce from the first split
MOV alone. Ideally we would like the pass to see that it can coalesce from both
split MOVs instead, but for now we keep it simple.

Finally, the pass doesn't support coalescing of multiple registers but in the
case of normal SIMD4x2 double-precision instructions they naturally write two
registers (one per vertex) and there is no reason why we should not allow
coalescing in this case. Change the restriction to bail if we see instructions
that write more than 8 channels, where the channels can be 32-bit or 64-bit.

v2:
 - Make sure that scan_inst and inst write the same amount of data.
---
The previous version of this patch would abort the process if scan_inst wrote
the same or more data than inst read, which is obviously wrong. What we want to
ensure is that both scan_inst and inst write the same amount of data so that
coalescing does not produce a result that writes a different region of the
destination.

 src/mesa/drivers/dri/i965/brw_vec4.cpp | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index c728e38..6a5909b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1191,6 +1191,20 @@ vec4_visitor::opt_register_coalesce()
   scan_inst->dst.type == scan_inst->src[0].type))
break;
 
+/* Only allow coalescing between registers of the same type size.
+ * Otherwise we would need to make the pass aware of the fact that
+ * channel sizes are different for single and double precision.
+ */
+if (type_sz(inst->src[0].type) != type_sz(scan_inst->src[0].type))
+   break;
+
+/* Check that scan_inst writes the same amount of data as the
+ * instruction, otherwise coalescing would lead to writing a
+ * different (larger or smaller) region of the destination
+ */
+if (scan_inst->size_written != inst->size_written)
+   break;
+
 /* If we can't handle the swizzle, bail. */
 if (!scan_inst->can_reswizzle(devinfo, inst->dst.writemask,
   inst->src[0].swizzle,
@@ -1198,10 +1212,12 @@ vec4_visitor::opt_register_coalesce()
break;
 }
 
-/* This only handles coalescing of a single register starting at
- * the source offset of the copy instruction.
+/* This only handles coalescing writes of 8 channels (1 register
+ * for single-precision and 2 registers for double-precision)
+ * starting at the source offset of the copy instruction.
  */
-if (scan_inst->size_written > REG_SIZE ||
+if (DIV_ROUND_UP(scan_inst->size_written,
+ type_sz(scan_inst->dst.type)) > 8 ||
 scan_inst->dst.offset != inst->src[0].offset)
break;
 
-- 
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/5] st/va: Return more useful config attributes

[Christian König]

Am 13.10.2016 um 00:52 schrieb Mark Thompson:

The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.


Reviewed-by: Christian König  for the whole 
series.


Do you have commit access?

Regards,
Christian.


---
  src/gallium/state_trackers/va/config.c | 47 +++---
  1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 4052316..72f68ba 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -115,16 +115,45 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile 
profile, VAEntrypoint en

 for (i = 0; i < num_attribs; ++i) {
unsigned int value;
-  switch (attrib_list[i].type) {
-  case VAConfigAttribRTFormat:
- value = VA_RT_FORMAT_YUV420;
- break;
-  case VAConfigAttribRateControl:
- value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
- break;
-  default:
+  if (entrypoint == VAEntrypointVLD) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = VA_RT_FORMAT_YUV420;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointEncSlice) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = VA_RT_FORMAT_YUV420;
+break;
+ case VAConfigAttribRateControl:
+value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
+break;
+ case VAConfigAttribEncPackedHeaders:
+value = 0;
+break;
+ case VAConfigAttribEncMaxRefFrames:
+value = 1;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointVideoProc) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = (VA_RT_FORMAT_YUV420 |
+ VA_RT_FORMAT_RGB32);
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else {
   value = VA_ATTRIB_NOT_SUPPORTED;
- break;
}
attrib_list[i].value = value;
 }



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

Re: [Mesa-dev] [PATCH 1/2] st/mesa: Take local references for sync object fences

[Nicolai Hähnle]

On 13.10.2016 05:45, Michel Dänzer wrote:

On 12/10/16 08:52 PM, Nicolai Hähnle wrote:

On 12.10.2016 11:31, Michel Dänzer wrote:


diff --git a/src/mesa/state_tracker/st_cb_syncobj.c
b/src/mesa/state_tracker/st_cb_syncobj.c
index 123925a..de01880 100644
--- a/src/mesa/state_tracker/st_cb_syncobj.c
+++ b/src/mesa/state_tracker/st_cb_syncobj.c
@@ -81,17 +81,22 @@ static void st_check_sync(struct gl_context *ctx,
struct gl_sync_object *obj)
struct pipe_context *pipe = st_context(ctx)->pipe;
struct pipe_screen *screen = pipe->screen;
struct st_sync_object *so = (struct st_sync_object*)obj;
+   struct pipe_fence_handle *fence = NULL;
+
+   screen->fence_reference(screen, &fence, so->fence);


This should probably really use p_atomic_read (or some kind of READ_ONCE
macro if we had it) to make the intention clear, but I'm not sure
whether that would compile everywhere since so->fence is a pointer.

In practice it doesn't matter, because the function call is a sufficient
barrier. So either way,

Reviewed-by: Nicolai Hähnle 


Thanks, but unfortunately,
https://bugs.freedesktop.org/show_bug.cgi?id=98172#c5 shows that this
really isn't good enough yet. Back to the drawing board...


I expect that most of the gallium *_reference functions need a similar 
treatment in order to be able to do atomic reference changes.


Nicolai




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

Re: [Mesa-dev] [PATCH] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

[Nicolai Hähnle]

On 13.10.2016 08:34, Edward O'Callaghan wrote:

Signed-off-by: Edward O'Callaghan 


I think i965 can get the same treatment. And the mesamatrix people need 
to check their parsing code for OpenGL 4.4 ;)


Cheers,
Nicolai


---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..b15ec35 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)

-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: nvc0, radeonsi

-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+)
+  GL_ARB_clip_control   DONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (i965, nv50, 
llvmpipe, softpipe, swr)
+  GL_ARB_derivative_control DONE (i965, nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, r600)
+  GL_ARB_texture_barrierDONE (i965, nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE (i965)
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)

 These are the extensions cherry-picked to make GLES 3.1


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

Re: [Mesa-dev] Mesa (master): st/glsl_to_tgsi: simpler fixup of empty writemasks

[Nicolai Hähnle]

Hi Michel,

On 13.10.2016 08:42, Michel Dänzer wrote:

On 13/10/16 01:50 AM, Nicolai Hähnle wrote:

Module: Mesa
Branch: master
Commit: f5f3cadca3809952288e3726ed5fde22090dc61d
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f5f3cadca3809952288e3726ed5fde22090dc61d

Author: Nicolai Hähnle 
Date:   Fri Oct  7 12:49:36 2016 +0200

st/glsl_to_tgsi: simpler fixup of empty writemasks


This change broke the piglit tests
spec@glsl-110@execution@variable-indexing@vs-temp-array-mat2-index(-col)-wr
on my Kaveri. Output with R600_DEBUG=ps,vs attached as
vs-temp-array-mat2-index-wr.txt .


P.S. The newly enabled tests
spec@arb_enhanced_layouts@execution@component-layout@vs-tcs-load-output(-indirect)
also fail, output attached as vs-tcs-load-output.stderr .


Thanks, it's on my radar. As far as I can tell, Mesa is doing the right 
thing here and LLVM is the problem, and working around it in Mesa may 
not be possible or reliable. But it's on my list of things to fix properly.


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

Re: [Mesa-dev] [PATCH] mesa_glinterop: allow building without X and related headers

[Tapani Pälli]

Thanks Emil!

Reviewed-by: Tapani Pälli 

On 10/12/2016 08:49 PM, Emil Velikov wrote:

This commit effectively reverts c10dcb2ce837922c6ee4e191e6d6202098a5ee10
and fixes the typedef redefinition which inspired it.

In order to prevent requiring X packages at build time earlier commit
forward declared the required X/GLX typedefs. Since that approach
introduced typedef redefinition (a C11 feature) it was reverted.

To avoid the redefinition while _not_ mandating X and related headers
forward declare the structs and use those through the header.

As anyone uses the mesa interop header they ensure that the X (or others
in terms of EGL) headers are included, which ensures that everything is
resolved within the compilation unit.

Cc: Vinson Lee 
Cc: "12.0" 
Cc: Tapani Pälli 
Cc: Chih-Wei Huang 
Fixes: c10dcb2ce837 ("Revert "mesa_glinterop: remove inclusion of GLX
header"")
Fixes: 8472045b16b3 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Emil Velikov 
---
TL;DR; Yay typedefs, because they make things so much better ;-)

Tapani/Chih-Wei, this should fix the breakage that you are seing. Please
let me know if it sorts things on your end.

Vison, this should resolve things on your end as well. A confirmation
would be great.
---
 include/GL/mesa_glinterop.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index c6a967e..173476a 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -52,12 +52,15 @@

 #include 
 #include 
-#include 

 #ifdef __cplusplus
 extern "C" {
 #endif

+/* Forward declarations to avoid inclusion of GL/glx.h */
+struct _XDisplay;
+struct __GLXcontextRec;
+
 /* Forward declarations to avoid inclusion of EGL/egl.h */
 typedef void *EGLDisplay;
 typedef void *EGLContext;
@@ -243,7 +246,7 @@ struct mesa_glinterop_export_out {
  * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
  */
 int
-MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
+MesaGLInteropGLXQueryDeviceInfo(struct _XDisplay *dpy, struct __GLXcontextRec 
*context,
 struct mesa_glinterop_device_info *out);


@@ -268,7 +271,7 @@ MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext 
context,
  * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
  */
 int
-MesaGLInteropGLXExportObject(Display *dpy, GLXContext context,
+MesaGLInteropGLXExportObject(struct _XDisplay *dpy, struct __GLXcontextRec 
*context,
  struct mesa_glinterop_export_in *in,
  struct mesa_glinterop_export_out *out);

@@ -283,11 +286,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext 
context,
  struct mesa_glinterop_export_out *out);


-typedef int (PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy, GLXContext 
context,
+typedef int (PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(struct _XDisplay *dpy, 
struct __GLXcontextRec *context,
  struct 
mesa_glinterop_device_info *out);
 typedef int (PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay dpy, 
EGLContext context,
  struct 
mesa_glinterop_device_info *out);
-typedef int (PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy, GLXContext 
context,
+typedef int (PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(struct _XDisplay *dpy, 
struct __GLXcontextRec *context,
   struct 
mesa_glinterop_export_in *in,
   struct 
mesa_glinterop_export_out *out);
 typedef int (PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy, EGLContext 
context,


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

Re: [Mesa-dev] Mesa (master): st/glsl_to_tgsi: simpler fixup of empty writemasks

[Michel Dänzer]

On 13/10/16 04:26 PM, Nicolai Hähnle wrote:
> Hi Michel,
> 
> On 13.10.2016 08:42, Michel Dänzer wrote:
>> On 13/10/16 01:50 AM, Nicolai Hähnle wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: f5f3cadca3809952288e3726ed5fde22090dc61d
>>> URL:   
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f5f3cadca3809952288e3726ed5fde22090dc61d
>>>
>>>
>>> Author: Nicolai Hähnle 
>>> Date:   Fri Oct  7 12:49:36 2016 +0200
>>>
>>> st/glsl_to_tgsi: simpler fixup of empty writemasks
>>
>> This change broke the piglit tests
>> spec@glsl-110@execution@variable-indexing@vs-temp-array-mat2-index(-col)-wr
>>
>> on my Kaveri. Output with R600_DEBUG=ps,vs attached as
>> vs-temp-array-mat2-index-wr.txt .
>>
>>
>> P.S. The newly enabled tests
>> spec@arb_enhanced_layouts@execution@component-layout@vs-tcs-load-output(-indirect)
>>
>> also fail, output attached as vs-tcs-load-output.stderr .
> 
> Thanks, it's on my radar. As far as I can tell, Mesa is doing the right
> thing here and LLVM is the problem, and working around it in Mesa may
> not be possible or reliable. But it's on my list of things to fix properly.

Excellent, thanks.


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

Re: [Mesa-dev] [PATCH] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

[Edward O'Callaghan]

On 10/13/2016 06:24 PM, Nicolai Hähnle wrote:
> On 13.10.2016 08:34, Edward O'Callaghan wrote:
>> Signed-off-by: Edward O'Callaghan 
> 
> I think i965 can get the same treatment. And the mesamatrix people need

OK, I just was not sure about 'i965/hsw+' vs. 'i965' as I am not
familiar with all the different Intel variants. Will send a new version
in a few moments..

> to check their parsing code for OpenGL 4.4 ;)

hehe, yes they do ;)

Kind Regards,
Edward.

> 
> Cheers,
> Nicolai
> 
>> ---
>>  docs/features.txt | 18 +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/docs/features.txt b/docs/features.txt
>> index ec2634f..b15ec35 100644
>> --- a/docs/features.txt
>> +++ b/docs/features.txt
>> @@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>>GL_ARB_texture_stencil8   DONE
>> (i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
>>GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
>> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>>
>> -GL 4.5, GLSL 4.50:
>> +GL 4.5, GLSL 4.50 -- all DONE: nvc0, radeonsi
>>
>> -  GL_ARB_ES3_1_compatibilityDONE
>> (i965/hsw+, nvc0, radeonsi)
>> -  GL_ARB_clip_control   DONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_conditional_render_invertedDONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_cull_distance  DONE (i965,
>> nv50, nvc0, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_derivative_control DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+)
>> +  GL_ARB_clip_control   DONE (i965,
>> nv50, r600, llvmpipe, softpipe, swr)
>> +  GL_ARB_conditional_render_invertedDONE (i965,
>> nv50, r600, llvmpipe, softpipe, swr)
>> +  GL_ARB_cull_distance  DONE (i965,
>> nv50, llvmpipe, softpipe, swr)
>> +  GL_ARB_derivative_control DONE (i965,
>> nv50, r600)
>>GL_ARB_direct_state_accessDONE (all
>> drivers)
>>GL_ARB_get_texture_sub_image  DONE (all
>> drivers)
>> -  GL_ARB_shader_texture_image_samples   DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> -  GL_ARB_texture_barrierDONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_shader_texture_image_samples   DONE (i965,
>> nv50, r600)
>> +  GL_ARB_texture_barrierDONE (i965,
>> nv50, r600)
>>GL_KHR_context_flush_control  DONE (all -
>> but needs GLX/EGL extension to be useful)
>> -  GL_KHR_robustness DONE (i965,
>> nvc0, radeonsi)
>> +  GL_KHR_robustness DONE (i965)
>>GL_EXT_shader_integer_mix DONE (all
>> drivers that support GLSL)
>>
>>  These are the extensions cherry-picked to make GLES 3.1
>>



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

[Mesa-dev] [PATCH v2] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

[Edward O'Callaghan]

Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..a5c8750 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
 
-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi
 
-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE
+  GL_ARB_clip_control   DONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (nv50, llvmpipe, 
softpipe, swr)
+  GL_ARB_derivative_control DONE (nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
+  GL_ARB_texture_barrierDONE (nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)
 
 These are the extensions cherry-picked to make GLES 3.1
-- 
2.7.4

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

[Mesa-dev] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

[bugzilla-daemon]

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

Alejandro Piñeiro (freenode IRC: apinheiro)  changed:

   What|Removed |Added

 CC||apinhe...@igalia.com

--- Comment #4 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
(In reply to Randy from comment #2)
> (In reply to Kenneth Graunke from comment #1)
> > Unclear whether the tests or the driver are wrong.  Need to discuss
> > ARB_program_interface_query issue 16 with Khronos.
> 
> Thanks, besides ARB_program_interface_query, we also need check
> ARB_program_interface_query

FWIW, in relation with Issue 16, I opened the following public khronos bug some
time ago:

https://www.khronos.org/bugzilla/show_bug.cgi?id=1655

Don't know if there are an equivalent internal bug tracking the issue (I don't
have access to the internal tracker).

-- 
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] gallium/hud: bugfix: 68169 - Sensor extensions segfaults.

[Nicolai Hähnle]

On 12.10.2016 19:02, Steven Toth wrote:

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

Really a two part bug.

1. The recent extensions to the HUB framework were tested exclusively
with glxgears/demo/head. None of these tools exercise the
free_query_data() code path. When these codepaths were
tested, thanks to Christoph, using heaven-unigine
application, the sensors extension would segfault.

2. In a second case, same use case, extensions would
return zero values for cpufrequency, network stats etc.

On inspection, this was due to the 'unigine' application
created the HUD contexts twice (two screens?). The
extensions had never been tested in that configuration,
and the free_query_data() calls were thus trigger.


The HUD is actually created per-context. Two general points that apply 
equally to all four parts of the patch:


Instead of open-coding the users variable, I'd prefer that you use the 
pipe_reference mechanism. This mechanism has the advantage that it 
already works in a multi-threaded setting, which brings me to the second 
point, which is:


Contexts can be created and destroyed simultaneously from multiple 
threads. You need to protect at least the globals with a mutex, i.e. in 
the find_*_by_name and free_query_data.


You probably need to protect some of the query functions with a mutex as 
well. The general rule of thumb is that functions associated to a 
pipe_context can only be called from one thread at a time; i.e., the 
graph's callback function (like query_dsi_load) is only called from one 
thread at a time _for one particular graph_. However, since you're 
sharing the underlying data between graphs in multiple contexts, you 
need a mutex e.g. in query_dsi_load when accessing the dsi members.


At least you need to think through the implications of what happens here...

It may actually be cleaner and simpler to just get rid of the sharing of 
underlying structures.


Thanks for looking into this!

Cheers,
Nicolai


This patchset ensures that globally allocated
mechanisms for collecting and exposing various
disk, network, cpu frequency and sensors statistics
are retained correctly across multiple uses, and
free'd when no more callers require them.

Patchset was regression tested again with Unigine,
glxgears and glxdemo.

Tested-By: Christoph Haag 
Signed-off-by: Steven Toth 
---
 src/gallium/auxiliary/hud/hud_cpufreq.c  |  8 ++--
 src/gallium/auxiliary/hud/hud_diskstat.c | 10 +++---
 src/gallium/auxiliary/hud/hud_nic.c  |  8 ++--
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 18 +-
 4 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
index 4501bbb..39bdcb0 100644
--- a/src/gallium/auxiliary/hud/hud_cpufreq.c
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -57,6 +57,7 @@ struct cpufreq_info
char sysfs_filename[128];
uint64_t KHz;
uint64_t last_time;
+   int users;
 };

 static int gcpufreq_count = 0;
@@ -116,8 +117,10 @@ static void
 free_query_data(void *p)
 {
struct cpufreq_info *cfi = (struct cpufreq_info *)p;
-   list_del(&cfi->list);
-   FREE(cfi);
+   if (--cfi->users == 0) {
+  list_del(&cfi->list);
+  FREE(cfi);
+   }
 }

 /**
@@ -159,6 +162,7 @@ hud_cpufreq_graph_install(struct hud_pane *pane, int 
cpu_index,
   return;
}

+   cfi->users++;
gr->query_data = cfi;
gr->query_new_value = query_cfi_load;

diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
b/src/gallium/auxiliary/hud/hud_diskstat.c
index b248baf..000d6b3 100644
--- a/src/gallium/auxiliary/hud/hud_diskstat.c
+++ b/src/gallium/auxiliary/hud/hud_diskstat.c
@@ -73,6 +73,7 @@ struct diskstat_info
char sysfs_filename[128];
uint64_t last_time;
struct stat_s last_stat;
+   int users;
 };

 /* TODO: We don't handle dynamic block device / partition
@@ -165,9 +166,11 @@ query_dsi_load(struct hud_graph *gr)
 static void
 free_query_data(void *p)
 {
-   struct diskstat_info *nic = (struct diskstat_info *) p;
-   list_del(&nic->list);
-   FREE(nic);
+   struct diskstat_info *dsi = (struct diskstat_info *) p;
+   if (--dsi->users == 0) {
+  list_del(&dsi->list);
+  FREE(dsi);
+   }
 }

 /**
@@ -205,6 +208,7 @@ hud_diskstat_graph_install(struct hud_pane *pane, const 
char *dev_name,
else
   return;

+   dsi->users++;
gr->query_data = dsi;
gr->query_new_value = query_dsi_load;

diff --git a/src/gallium/auxiliary/hud/hud_nic.c 
b/src/gallium/auxiliary/hud/hud_nic.c
index fb6b8c0..e3f5910 100644
--- a/src/gallium/auxiliary/hud/hud_nic.c
+++ b/src/gallium/auxiliary/hud/hud_nic.c
@@ -59,6 +59,7 @@ struct nic_info
char throughput_filename[128];
uint64_t last_time;
uint64_t last_nic_bytes;
+   int users;
 };

 /* TODO: We don't handle dynamic NIC arrival or removal.
@@ -238,8 +239,10 @@ static void
 free_query_data(void *p)
 {
struct nic_info *nic = (struct nic_info *) p;
-   list_del(&nic->list);
- 

[Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

[Andreas Boll]

Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.

So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".

Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the cap on")
Signed-off-by: Andreas Boll 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..9cc9111 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0, radeonsi
   GL_ARB_vertex_attrib_binding  DONE (all drivers)
 
 
-GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
+GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
 
   GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all drivers)
-  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_enhanced_layouts   DONE (i965, llvmpipe, 
softpipe)
+  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_enhanced_layouts   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - compile-time constant expressions   DONE
   - explicit byte offsets for blocksDONE
   - forced alignment within blocks  DONE
-  - specified vec4-slot component numbers   DONE (i965, llvmpipe, 
softpipe)
+  - specified vec4-slot component numbers   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - specified transform/feedback layout DONE
   - input/output block locationsDONE
   GL_ARB_multi_bind DONE (all drivers)
-  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0)
-  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
+  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0, 
radeonsi)
+  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
 
 GL 4.5, GLSL 4.50:
 
-- 
2.1.4

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

Re: [Mesa-dev] [PATCH v2] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

[Andreas Boll]

nak, neither radeonsi nor i965 advertise GLSL 4.50.
Nicolai hasn't pushed the patch to enable GLSL 4.50 [1].
I'm not sure what's the plan for nouveau is [2].

See also https://patchwork.freedesktop.org/patch/115441/

Thanks,
Andreas

[1] https://patchwork.freedesktop.org/patch/114577/
[2] https://patchwork.freedesktop.org/patch/114522/

2016-10-13 9:40 GMT+02:00 Edward O'Callaghan :
> Signed-off-by: Edward O'Callaghan 
> ---
>  docs/features.txt | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index ec2634f..a5c8750 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>GL_ARB_texture_stencil8   DONE (i965/hsw+, 
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
> nvc0, r600, llvmpipe, softpipe, swr)
>
> -GL 4.5, GLSL 4.50:
> +GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi
>
> -  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, 
> nvc0, radeonsi)
> -  GL_ARB_clip_control   DONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_cull_distance  DONE (i965, nv50, 
> nvc0, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_derivative_control DONE (i965, nv50, 
> nvc0, r600, radeonsi)
> +  GL_ARB_ES3_1_compatibilityDONE
> +  GL_ARB_clip_control   DONE (nv50, r600, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_cull_distance  DONE (nv50, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_derivative_control DONE (nv50, r600)
>GL_ARB_direct_state_accessDONE (all drivers)
>GL_ARB_get_texture_sub_image  DONE (all drivers)
> -  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
> nvc0, r600, radeonsi)
> -  GL_ARB_texture_barrierDONE (i965, nv50, 
> nvc0, r600, radeonsi)
> +  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
> +  GL_ARB_texture_barrierDONE (nv50, r600)
>GL_KHR_context_flush_control  DONE (all - but 
> needs GLX/EGL extension to be useful)
> -  GL_KHR_robustness DONE (i965, nvc0, 
> radeonsi)
> +  GL_KHR_robustness DONE
>GL_EXT_shader_integer_mix DONE (all drivers 
> that support GLSL)
>
>  These are the extensions cherry-picked to make GLES 3.1
> --
> 2.7.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

[Mesa-dev] [PATCH 1/7] nir: move nir_shader_info to a common compiler header

[Timothy Arceri]

This will allow use to stop copying values between structs and
will also simplify handling handling these values in the shader cache.
---
 src/compiler/nir/nir.h  |  98 +---
 src/compiler/shader_info.h  | 123 
 src/mesa/drivers/dri/i965/brw_nir.c |   2 +-
 3 files changed, 126 insertions(+), 97 deletions(-)
 create mode 100644 src/compiler/shader_info.h

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d6c8efa..04b0301 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -37,6 +37,7 @@
 #include "util/macros.h"
 #include "compiler/nir_types.h"
 #include "compiler/shader_enums.h"
+#include "compiler/shader_info.h"
 #include 
 
 #include "nir_opcodes.h"
@@ -1783,101 +1784,6 @@ typedef struct nir_shader_compiler_options {
bool use_interpolated_input_intrinsics;
 } nir_shader_compiler_options;
 
-typedef struct nir_shader_info {
-   const char *name;
-
-   /* Descriptive name provided by the client; may be NULL */
-   const char *label;
-
-   /* Number of textures used by this shader */
-   unsigned num_textures;
-   /* Number of uniform buffers used by this shader */
-   unsigned num_ubos;
-   /* Number of atomic buffers used by this shader */
-   unsigned num_abos;
-   /* Number of shader storage buffers used by this shader */
-   unsigned num_ssbos;
-   /* Number of images used by this shader */
-   unsigned num_images;
-
-   /* Which inputs are actually read */
-   uint64_t inputs_read;
-   /* Which inputs are actually read and are double */
-   uint64_t double_inputs_read;
-   /* Which outputs are actually written */
-   uint64_t outputs_written;
-   /* Which outputs are actually read */
-   uint64_t outputs_read;
-   /* Which system values are actually read */
-   uint64_t system_values_read;
-
-   /* Which patch inputs are actually read */
-   uint32_t patch_inputs_read;
-   /* Which patch outputs are actually written */
-   uint32_t patch_outputs_written;
-
-   /* Whether or not this shader ever uses textureGather() */
-   bool uses_texture_gather;
-
-   /* Whether or not this shader uses the gl_ClipDistance output */
-   bool uses_clip_distance_out;
-
-   /* Whether or not separate shader objects were used */
-   bool separate_shader;
-
-   /** Was this shader linked with any transform feedback varyings? */
-   bool has_transform_feedback_varyings;
-
-   union {
-  struct {
- /** The number of vertices recieves per input primitive */
- unsigned vertices_in;
-
- /** The output primitive type (GL enum value) */
- unsigned output_primitive;
-
- /** The maximum number of vertices the geometry shader might write. */
- unsigned vertices_out;
-
- /** 1 .. MAX_GEOMETRY_SHADER_INVOCATIONS */
- unsigned invocations;
-
- /** Whether or not this shader uses EndPrimitive */
- bool uses_end_primitive;
-
- /** Whether or not this shader uses non-zero streams */
- bool uses_streams;
-  } gs;
-
-  struct {
- bool uses_discard;
-
- /**
-  * Whether any inputs are declared with the "sample" qualifier.
-  */
- bool uses_sample_qualifier;
-
- /**
-  * Whether early fragment tests are enabled as defined by
-  * ARB_shader_image_load_store.
-  */
- bool early_fragment_tests;
-
- /** gl_FragDepth layout for ARB_conservative_depth. */
- enum gl_frag_depth_layout depth_layout;
-  } fs;
-
-  struct {
- unsigned local_size[3];
-  } cs;
-
-  struct {
- /** The number of vertices in the TCS output patch. */
- unsigned vertices_out;
-  } tcs;
-   };
-} nir_shader_info;
-
 typedef struct nir_shader {
/** list of uniforms (nir_variable) */
struct exec_list uniforms;
@@ -1899,7 +1805,7 @@ typedef struct nir_shader {
const struct nir_shader_compiler_options *options;
 
/** Various bits of compile-time information about a given shader */
-   struct nir_shader_info info;
+   struct shader_info info;
 
/** list of global variables in the shader (nir_variable) */
struct exec_list globals;
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
new file mode 100644
index 000..68800a1
--- /dev/null
+++ b/src/compiler/shader_info.h
@@ -0,0 +1,123 @@
+/*
+ * Copyright © 2016 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
+ * 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

[Mesa-dev] RFC - shared shader info (Part 1)

[Timothy Arceri]

Having these fields directly in nir_shader makes things difficult for
the shader cache. This series creates a shared shader info and makes a
start at the large amount of clean-ups this will enable.

I decided to send this before getting too carried away to make sure
people are happy with this change. If everyones happy I'll start work
on part 2.

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

[Mesa-dev] [PATCH 7/7] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
 src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
 src/mesa/drivers/dri/i965/brw_tcs.c   | 32 ++-
 src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
 src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
 src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
 src/mesa/main/context.c   |  2 +-
 src/mesa/main/mtypes.h| 12 +
 src/mesa/main/shaderapi.c |  4 +--
 src/mesa/main/state.c |  9 +++
 src/mesa/program/prog_statevars.c |  2 +-
 src/mesa/program/program.c|  4 +--
 src/mesa/program/program.h| 23 
 src/mesa/state_tracker/st_atom.c  |  2 +-
 src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 src/mesa/state_tracker/st_atom_shader.c   |  2 +-
 src/mesa/state_tracker/st_atom_texture.c  |  2 +-
 src/mesa/state_tracker/st_cb_program.c| 10 +++
 src/mesa/state_tracker/st_program.c   |  6 ++---
 src/mesa/state_tracker/st_program.h   |  6 ++---
 22 files changed, 57 insertions(+), 99 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c92bb9f..9b7e184 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -337,7 +337,7 @@ struct brw_vertex_program {
 
 /** Subclass of Mesa tessellation control program */
 struct brw_tess_ctrl_program {
-   struct gl_tess_ctrl_program program;
+   struct gl_program program;
unsigned id;  /**< serial no. to identify tess ctrl progs, never re-used */
 };
 
@@ -1008,7 +1008,7 @@ struct brw_context
 */
const struct gl_vertex_program *vertex_program;
const struct gl_geometry_program *geometry_program;
-   const struct gl_tess_ctrl_program *tess_ctrl_program;
+   const struct gl_program *tess_ctrl_program;
const struct gl_tess_eval_program *tess_eval_program;
const struct gl_fragment_program *fragment_program;
const struct gl_compute_program *compute_program;
@@ -1730,7 +1730,7 @@ brw_vertex_program_const(const struct gl_vertex_program 
*p)
 }
 
 static inline struct brw_tess_ctrl_program *
-brw_tess_ctrl_program(struct gl_tess_ctrl_program *p)
+brw_tess_ctrl_program(struct gl_program *p)
 {
return (struct brw_tess_ctrl_program *) p;
 }
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 5d176ef..5485de3 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -458,7 +458,7 @@ brw_try_draw_prims(struct gl_context *ctx,
brw->tes.base.sampler_count = ctx->TessEvalProgram._Current ?
   util_last_bit(ctx->TessEvalProgram._Current->Base.SamplersUsed) : 0;
brw->tcs.base.sampler_count = ctx->TessCtrlProgram._Current ?
-  util_last_bit(ctx->TessCtrlProgram._Current->Base.SamplersUsed) : 0;
+  util_last_bit(ctx->TessCtrlProgram._Current->SamplersUsed) : 0;
brw->vs.base.sampler_count =
   util_last_bit(ctx->VertexProgram._Current->Base.SamplersUsed);
 
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index a41f36e..4e0df5a 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -168,7 +168,7 @@ static struct gl_program *brwNewProgram( struct gl_context 
*ctx,
   if (prog) {
  prog->id = get_new_program_id(brw->screen);
 
- return _mesa_init_gl_program(&prog->program.Base, target, id);
+ return _mesa_init_gl_program(&prog->program, target, id);
   } else {
  return NULL;
   }
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 0f03fab..08cf413 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -178,7 +178,7 @@ brw_codegen_tcs_prog(struct brw_context *brw,
double start_time = 0;
 
if (tcp) {
-  nir = tcp->program.Base.nir;
+  nir = tcp->program.nir;
} else {
   /* Create a dummy nir_shader.  We won't actually use NIR code to
* generate assembly (it's easier to generate assembly directly),
@@ -211,14 +211,14 @@ brw_codegen_tcs_prog(struct brw_context *brw,
 
if (tcs) {
   brw_assign_common_binding_table_offsets(MESA_SHADER_TESS_CTRL, devinfo,
-  shader_prog, &tcp->program.Base,
+  shader_prog, &tcp->program,
   &prog_data.base.base, 0);
 
   prog_data.base.base.image_param =
  rzalloc_array(NULL, struct brw_image_param, tcs->NumImages

[Mesa-dev] [PATCH 3/7] compiler: add fields for tes metadata to shader info

[Timothy Arceri]

---
 src/compiler/shader_info.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 68800a1..8266fc3 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -117,6 +117,13 @@ typedef struct shader_info {
  /** The number of vertices in the TCS output patch. */
  unsigned vertices_out;
   } tcs;
+
+  struct {
+ uint32_t primitive_mode; /* GL_TRIANGLES, GL_QUADS or GL_ISOLINES */
+ uint32_t spacing;/* GL_EQUAL, GL_FRACTIONAL_EVEN, 
GL_FRACTIONAL_ODD */
+ uint32_t vertex_order;   /* GL_CW or GL_CCW */
+ bool point_mode;
+  } tes;
};
 } shader_info;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/7] compiler: add input primative field for gs in shader info

[Timothy Arceri]

---
 src/compiler/shader_info.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 8266fc3..502c7c8 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -78,6 +78,9 @@ typedef struct shader_info {
  /** The output primitive type (GL enum value) */
  unsigned output_primitive;
 
+ /** The input primitive type (GL enum value) */
+ unsigned input_primitive;
+
  /** The maximum number of vertices the geometry shader might write. */
  unsigned vertices_out;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/7] compiler: add additional cs metadata fields to shader info

[Timothy Arceri]

---
 src/compiler/shader_info.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 502c7c8..66e06ad 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -114,6 +114,16 @@ typedef struct shader_info {
 
   struct {
  unsigned local_size[3];
+
+ /**
+  * Size of shared variables accessed by the compute shader.
+  */
+ unsigned shared_size;
+
+ /**
+  * Whether a variable work group size has been specified.
+  */
+ bool local_size_variable;
   } cs;
 
   struct {
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/7] glsl: add a shader info field to the gl_program type

[Timothy Arceri]

And use this field as the source for shader info in the nir_shader
this will allow us to set some of these fields from GLSL directly.

It will also simplify restoring from shader cache and allow the
removal of duplicate fields from GLSL.
---
 src/compiler/glsl/glsl_to_nir.cpp | 3 ++-
 src/mesa/main/mtypes.h| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index b531892..934c9d1 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -136,7 +136,8 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
 {
struct gl_linked_shader *sh = shader_prog->_LinkedShaders[stage];
 
-   nir_shader *shader = nir_shader_create(NULL, stage, options, NULL);
+   nir_shader *shader = nir_shader_create(NULL, stage, options,
+  &sh->Program->info);
 
nir_visitor v1(shader);
nir_function_visitor v2(&v1);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ab9839c..c025040 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -43,6 +43,7 @@
 #include "glapi/glapi.h"
 #include "math/m_matrix.h" /* GLmatrix */
 #include "compiler/shader_enums.h"
+#include "compiler/shader_info.h"
 #include "main/formats.h"   /* MESA_FORMAT_COUNT */
 #include "compiler/glsl/list.h"
 #include "util/bitscan.h"
@@ -1919,6 +1920,8 @@ struct gl_program
 
struct nir_shader *nir;
 
+   struct shader_info info;
+
GLbitfield64 InputsRead; /**< Bitmask of which input regs are read */
GLbitfield64 DoubleInputsRead; /**< Bitmask of which input regs are 
read  and are doubles */
GLbitfield64 OutputsWritten; /**< Bitmask of which output regs are written 
*/
-- 
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/5] intel: automake: replace direct basename $@ invokation with $(@F)

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 12/10/16 19:05, Emil Velikov wrote:

From: Emil Velikov 

Use the shorthand make variable(s) as elsewhere in the build.

Signed-off-by: Emil Velikov 
---
  src/intel/Makefile.genxml.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index f8b0363..519f30e 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -37,7 +37,7 @@ $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
  %_xml.h:  %.xml Makefile
$(MKDIR_GEN)
$(AM_V_GEN) echo -n "static const uint8_t " > $@; \
-   echo "`basename $@`_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
+   echo "$(@F)_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
cat $< | $(XXD) -i >> $@; \
echo "};" >> $@
  



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

Re: [Mesa-dev] [PATCH v2] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

[Samuel Pitoiset]

On 10/13/2016 10:31 AM, Andreas Boll wrote:

nak, neither radeonsi nor i965 advertise GLSL 4.50.
Nicolai hasn't pushed the patch to enable GLSL 4.50 [1].
I'm not sure what's the plan for nouveau is [2].


The plan is to not change docs/features.txt for nvc0 (not yet). :)



See also https://patchwork.freedesktop.org/patch/115441/

Thanks,
Andreas

[1] https://patchwork.freedesktop.org/patch/114577/
[2] https://patchwork.freedesktop.org/patch/114522/

2016-10-13 9:40 GMT+02:00 Edward O'Callaghan :

Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..a5c8750 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)

-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi

-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE
+  GL_ARB_clip_control   DONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (nv50, llvmpipe, 
softpipe, swr)
+  GL_ARB_derivative_control DONE (nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
+  GL_ARB_texture_barrierDONE (nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)

 These are the extensions cherry-picked to make GLES 3.1
--
2.7.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



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

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

[Mark Thompson]

On 13/10/16 08:20, Christian König wrote:
> Am 13.10.2016 um 00:52 schrieb Mark Thompson:
>> The encoder attributes are needed for a user of the encoder to be
>> able to configure it sensibly without internal knowledge.
> 
> Reviewed-by: Christian König  for the whole series.
> 
> Do you have commit access?

I do not.  Please do push this for me once all appropriate people are happy 
with it.

Thanks,

- Mark

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #127237|0   |1
is obsolete||

--- Comment #7 from Michel Dänzer  ---
Created attachment 127267
  --> https://bugs.freedesktop.org/attachment.cgi?id=127267&action=edit
Lock the shared state mutex and work with a local reference of so->fence

Does this patch fix the problem completely?

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #127204|0   |1
is obsolete||

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

Re: [Mesa-dev] [PATCH] gallium/hud: bugfix: 68169 - Sensor extensions segfaults.

[Emil Velikov]

Hi Steven,

On 12 October 2016 at 18:02, Steven Toth  wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=98169
>
Just a general comment/suggestion:

Don't include bug# in the commit summary. Having it as Bugzilla:
https... towards the end of the description. Aside: if you know the
commit that is getting fixed, you can also add a kernel-like Fixes:
tag.

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

Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

[Marek Olšák]

On Thu, Oct 13, 2016 at 2:09 AM, Roland Scheidegger  wrote:
> Am 12.10.2016 um 15:29 schrieb Marek Olšák:
>> From: Marek Olšák 
>>
>> For performance tuning in drivers. It filters out window system
>> framebuffers and OpenGL renderbuffers.
>>
>> radeonsi will use this to guess whether a depth buffer will be read
>> by a shader. There is no guarantee about what will actually happen.
>>
>> This is a departure from PIPE_BIND flags which are defined to be strict
>> but they are useless in practice.
>> ---
>>  src/gallium/include/pipe/p_defines.h | 1 +
>>  src/mesa/state_tracker/st_texture.c  | 3 ++-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/include/pipe/p_defines.h 
>> b/src/gallium/include/pipe/p_defines.h
>> index db96c51..037ed92 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -443,20 +443,21 @@ enum pipe_flush_flags
>>  #define PIPE_BIND_SCANOUT (1 << 19) /*  */
>>  #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
>>  #define PIPE_BIND_LINEAR  (1 << 21)
>>
>>
>>  /**
>>   * Flags for the driver about resource behaviour:
>>   */
>>  #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
>>  #define PIPE_RESOURCE_FLAG_MAP_COHERENT   (1 << 1)
>> +#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
>>  #define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
>>  #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys 
>> private */
>>
>>  /**
>>   * Hint about the expected lifecycle of a resource.
>>   * Sorted according to GPU vs CPU access.
>>   */
>>  enum pipe_resource_usage {
>> PIPE_USAGE_DEFAULT,/* fast GPU access */
>> PIPE_USAGE_IMMUTABLE,  /* fast GPU access, immutable */
>> diff --git a/src/mesa/state_tracker/st_texture.c 
>> b/src/mesa/state_tracker/st_texture.c
>> index a2c36ac..7b72ffd 100644
>> --- a/src/mesa/state_tracker/st_texture.c
>> +++ b/src/mesa/state_tracker/st_texture.c
>> @@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
>> memset(&pt, 0, sizeof(pt));
>> pt.target = target;
>> pt.format = format;
>> pt.last_level = last_level;
>> pt.width0 = width0;
>> pt.height0 = height0;
>> pt.depth0 = depth0;
>> pt.array_size = layers;
>> pt.usage = PIPE_USAGE_DEFAULT;
>> pt.bind = bind;
>> -   pt.flags = 0;
>> +   /* only set this for OpenGL textures, not renderbuffers */
>> +   pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
>> pt.nr_samples = nr_samples;
>>
>> newtex = screen->resource_create(screen, &pt);
>>
>> assert(!newtex || pipe_is_referenced(&newtex->reference));
>>
>> return newtex;
>>  }
>>
>>
>>
>
> I guess, why not... I bet though there are apps which create everything
> as a texture, regardless if they actually use it for sampling or not. So
> you still need to try to not perform too bad if you got the hint wrong :-).
> It's really GL which is useless there, not the PIPE_BIND flags ;-).

But you have to admit that the new flag is very accurate - it
represents OpenGL texture objects. That can't be said about most of
the bind flags.

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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Emil Velikov]

On 13 October 2016 at 04:07, Michel Dänzer  wrote:
> On 13/10/16 03:37 AM, Tobias Droste wrote:
>> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:

 +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
 +LLVM_VERSION_REQUIRED_R600=3.6.0
 +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>>>
>>> There's a small related gotcha: as-is at build time we get the
>>> different codepaths thus, as people build against shared LLVM (hello
>>> Archlinux, I'm looking at you) and update their LLVM without
>>> rebuilding mesa (Arch I'm looking at you again) things go funny.
>
> What exactly happened there? LLVM upstream generates shared libraries
> named libLLVM-..so*, so it shouldn't be possible for a
> simple LLVM package update to break Mesa, unless Arch did something
> really stupid.
>
The issue is not specific to Arch, but anyone who links against shared LLVM.

Here is another take on it:
At least swr and r600/radeonsi depend at _build_ time on the _patch_
version of LLVM. The latter of which is not part of the DSO name. Thus
at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
"3.9.x" codepath even though you are be using "3.9.y" LLVM. If
anything I'm calling it a LLVM bug, since shared/static library users
should not need to know patch version, let alone have different
codepaths based on it. Runtime ones might be ok, compile time
definitely not.

On our end, we could a) bump the requirement such that there's no
compile time patch version check, b) suggest static linking or c)
pretend the {mis,ab,}use isn't there ;-)

>
>>> Tl;Dr; We really want to enable static linking by default and prod
>>> distros to use it.
>>
>> I'm all in favor of statically linking LLVM (that's the way I'm doing this on
>> my pc).
>> I think the only reason this is not done is because people (also here on the
>> list) don't want any static linkg of external libraries because of size or
>> whatever.
>> So changing the default to static is easy, but I doubt it will make everyone
>> happy ;-)
>
> Indeed, it'd probably make many distro packagers unhappy, because
> they'll just have to re-enable shared linking, because packaging
> policies generally strongly discourage if not outright forbid static
> linking.
>
The toggle is there and is not going away, afaict. If people are going
to get upset that the default does not meet their policy... just
toggle and get on with other things ;-)

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

Re: [Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

[Nicolai Hähnle]

On 13.10.2016 10:20, Andreas Boll wrote:

Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.

So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".

Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the cap on")
Signed-off-by: Andreas Boll 


The only place where this could possibly matter is mesamatrix, and 
frankly, it should be fixed there. There's clearly something wrong 
there, since it didn't update the display at all.


Nicolai


---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..9cc9111 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0, radeonsi
   GL_ARB_vertex_attrib_binding  DONE (all drivers)


-GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
+GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+

   GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all drivers)
-  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_enhanced_layouts   DONE (i965, llvmpipe, 
softpipe)
+  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_enhanced_layouts   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - compile-time constant expressions   DONE
   - explicit byte offsets for blocksDONE
   - forced alignment within blocks  DONE
-  - specified vec4-slot component numbers   DONE (i965, llvmpipe, 
softpipe)
+  - specified vec4-slot component numbers   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - specified transform/feedback layout DONE
   - input/output block locationsDONE
   GL_ARB_multi_bind DONE (all drivers)
-  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0)
-  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
+  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0, 
radeonsi)
+  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)

 GL 4.5, GLSL 4.50:



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

Re: [Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

[Mike Lothian]

Alternatively you could expose GLSL 440 until the bugs are squished for 450

On Thu, 13 Oct 2016 at 12:39 Nicolai Hähnle  wrote:

> On 13.10.2016 10:20, Andreas Boll wrote:
> > Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
> > all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.
> >
> > So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".
> >
> > Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the cap
> on")
> > Signed-off-by: Andreas Boll 
>
> The only place where this could possibly matter is mesamatrix, and
> frankly, it should be fixed there. There's clearly something wrong
> there, since it didn't update the display at all.
>
> Nicolai
>
> > ---
> >  docs/features.txt | 18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index ec2634f..9cc9111 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0,
> radeonsi
> >GL_ARB_vertex_attrib_binding  DONE (all
> drivers)
> >
> >
> > -GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
> > +GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
> >
> >GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all
> drivers)
> > -  GL_ARB_buffer_storage DONE (i965,
> nv50, nvc0, r600)
> > -  GL_ARB_clear_texture  DONE (i965,
> nv50, nvc0, r600)
> > -  GL_ARB_enhanced_layouts   DONE (i965,
> llvmpipe, softpipe)
> > +  GL_ARB_buffer_storage DONE (i965,
> nv50, nvc0, r600, radeonsi)
> > +  GL_ARB_clear_texture  DONE (i965,
> nv50, nvc0, r600, radeonsi)
> > +  GL_ARB_enhanced_layouts   DONE (i965,
> radeonsi, llvmpipe, softpipe)
> >- compile-time constant expressions   DONE
> >- explicit byte offsets for blocksDONE
> >- forced alignment within blocks  DONE
> > -  - specified vec4-slot component numbers   DONE (i965,
> llvmpipe, softpipe)
> > +  - specified vec4-slot component numbers   DONE (i965,
> radeonsi, llvmpipe, softpipe)
> >- specified transform/feedback layout DONE
> >- input/output block locationsDONE
> >GL_ARB_multi_bind DONE (all
> drivers)
> > -  GL_ARB_query_buffer_objectDONE
> (i965/hsw+, nvc0)
> > -  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > -  GL_ARB_texture_stencil8   DONE
> (i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > -  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
> > +  GL_ARB_query_buffer_objectDONE
> (i965/hsw+, nvc0, radeonsi)
> > +  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> > +  GL_ARB_texture_stencil8   DONE
> (i965/hsw+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> > +  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> >
> >  GL 4.5, GLSL 4.50:
> >
> >
> ___
> 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/15] GLSL memory allocation rework for faster compilation

[Juha-Pekka Heikkila]

I forgot to reply here on the list, I've just been talking about this 
with Tapani face to face.


My series rebased and fixed on top of mesa master branch from yesterday 
is here

https://github.com/juhapekka/juha_mesaexperimentals/tree/jenkins

Tapani was already taking rebased patches from above branch.

I originally stopped working on this set because I felt there was too 
much uncertainty if all places needed to be fixed could be found easily. 
Anyway, if you skip my patch for changes in glsl please check you have 
all places somehow handled which I had patched. All those patched places 
I dug up with Valgrind so they're 'real deal' where will get segfaults.


/Juha-Pekka

On 10.10.2016 14:52, Marek Olšák wrote:

I prefer some of my GLSL fixes in 1-4 over JP's changes, because they
seem cleaner to me.

Marek


On Oct 10, 2016 1:38 PM, "Tapani Pälli" mailto:tapani.pa...@intel.com>> wrote:



On 10/10/2016 02:27 PM, Marek Olšák wrote:

On Mon, Oct 10, 2016 at 1:25 PM, Tapani Pälli
mailto:tapani.pa...@intel.com>> wrote:



On 10/10/2016 01:38 PM, Marek Olšák wrote:


On Mon, Oct 10, 2016 at 12:33 PM, Marek Olšák
mailto:mar...@gmail.com>> wrote:


On Mon, Oct 10, 2016 at 7:58 AM, Tapani Pälli
mailto:tapani.pa...@intel.com>>
wrote:




On 10/08/2016 06:58 PM, Jason Ekstrand wrote:



FYI, we use ralloc for a lot more than just
the glsl compiler so the
first few changes make me a bit nervous.
There was someone working on
making our driver more I
undefined-memory-friendly but I don't know
what
happened to those patches.




There's bunch of patches like that in this series:

https://lists.freedesktop.org/archives/mesa-dev/2016-June/120445.html



it looks like it just never landed as would have
required more testing
on
misc drivers?



We can land at least some of the patches from that
series. We still
have to replace all non-GLSL uses of
DECLARE_RALLOC.. with
DECLARE_RZALLOC.



BTW, people can still give Rbs on all patches except 5.
This rzalloc
thing isn't an issue and can be dealt with in a separate
series (it
can be done after this series lands).



I agree these issues do not block review of the series. We
just need to make
sure it is absolutely safe before landing.

As concrete example I got following segfault when I applied
this series
which is directly related to rzalloc issues. This was with
'shader_freeze'
program, description in bug #94477 has link and build
instructions for this
if you want to try. When I applied JP's patches 4,5,6 (nir,
i965_vec4,
i965_fs changes) this segfault disappears.


I meant that this series is safe to land without patch 5. Did
you test
it without patch 5?


Ah sorry I managed to miss that. Now I did test and when reverting
patch 5 this test passes fine. Makes sense to do patch 5 as a
separate step when JP's changes land.

// Tapani



___
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 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

[Emil Velikov]

On 12 October 2016 at 18:59, Axel Davy  wrote:
> On 12/10/2016 19:15, Emil Velikov wrote:
>>
>> On 11 October 2016 at 19:54, Axel Davy  wrote:
>>>
>>> On 11/10/2016 20:31, Emil Velikov wrote:

-   udev = udev_new();
 -   if (!udev)
 -  goto prime_clean;
 +   if (drmGetDevice(default_fd, &device) != 0)
 +  goto err;
-   default_device_id_path_tag = get_id_path_tag_from_fd(udev,
 default_fd);
 -   if (!default_device_id_path_tag)
 -  goto udev_clean;
 -
 -   is_different_device = 1;
   /* two format are supported:
* "1": choose any other card than the card used by default.
* id_path_tag: (for example "pci-_02_00_0") choose the card
* with this id_path_tag.
*/
   if (!strcmp(prime,"1")) {
 -  free(prime);
 -  prime = strdup(default_device_id_path_tag);
 -  /* request a card with a different card than the default card */
 -  another_tag = 1;
 -   } else if (!strcmp(default_device_id_path_tag, prime))
 -  /* we are to get a new fd (render-node) of the same device */
 -  is_different_device = 0;
 +  /* Hmm... detection for 2-7 seems to be broken. Nicely done. */
>>>
>>> For DRI2, DRI_PRIME takes a number corresponding to the device number as
>>> configured in xorg (and you have xrandr commands to configure the
>>> behaviour). This doesn't work with the DRI3 scheme. However for
>>> retrocompatibility, after several discussions, we decided to let DRI2's
>>> most
>>> used command 'DRI_PRIME=1' to still sorta work on DRI3, but the meaning
>>> changed: DRI_PRIME=1 => 'give me any device that is not the
>>> compositor/xorg
>>> device'
>>
>> No argument/objection against DRI_PRIME with DRI3, yet the current
>> hard coded DRI_PRIME=1 _only_ check is iffy. As per the spec there can
>> be 8 devices (0-8) with 0 always being the xorg/compositor one and 1-7
>> as 'other' devices. Yet here we only consider 1 and ignore everything
>> else :-\
>
> Do you suggest to have DRI_PRIME=2 (up to 8) be the same than DRI_PRIME=1 ?
>
Where/how did you read that ? It sounds like you've not read through
the spec, have you ?

I'm saying that the DRI2(DriverPrime) spec allows for 8 devices in
total. The 0 one is always the xserver one and you have 7 "others".
Atm things are completely bonkers, since you have this half a**ed
broken heuristics which ignores anything but 1. Admittedly there
aren't many users with 3 or more GPUs but if they were things just
won't work :-\

Furthermore atm you get a walk over the renderD* (missing D in the
libudev pattern ;-) devices which does not relate to what you get as
the 1 device in any other DRI_PRIME use case.

Or in other words, if you use DRI_PRIME=1 with libGL/EGL/gbm you can
get different result than when doing the same with the
vdpau/xvmc/omx/vaapi drivers.

Even within libGL (DRI2) things are quite magical , fortunately you
get the same device if the loader fails.

>>
 +  is_different_device = 1;
 +   } else {
 +  default_tag = drm_construct_id_path_tag(device);
 +  if (default_tag == NULL)
 + goto err;
-   device_name = get_render_node_from_id_path_tag(udev,
 -  prime,
 -  another_tag);
 -   if (device_name == NULL) {
 +  if (strcmp(default_tag, prime) != 0) {
 + free(default_tag);
 + goto err;
 +  }
 +
 +  free(default_tag);
 +  /* we are to get a new fd (render-node) of the same device */
  is_different_device = 0;
 -  goto default_device_clean;
 +  // XXX: WTF ^^ so one uses the new model only to point to the
 exact
 same
 +  // device and not the other more/less powerful GPU ?
>>>
>>> This case if when one has in his configuration file that the app should
>>> run
>>> on device XXX, which happens to be the one in use by the compositor.
>>> This case needed to be handled, and while it may not very seem useful
>>> now,
>>> it could be in the future an interesting case (On wayland, you could have
>>> the compositor use a card on some screens, and another card on the other,
>>> etc. In this case it makes sense for the user to specify the card, and it
>>> may or may not be the card used for the given screen).
>>>
>> There's something lost in the translation here:
>>
>> Currently in case of non DRI_PRIME (i.e. path tag) we dive into
>> get_render_node_from_id_path_tag(), loop and trigger on !another_tag
>> && !strcmp(id_path_tag, id_path_tag_tmp) (another_tag is zero here).
>>
>> Or in other words the function returns the render node, of the exact
>> _same_ device. Which makes the whole new method of using pci-...
>> dubious since one cannot select the 'other' device :-\
>>
>> That is unless I'm missing something ?
>>
>> -Emil
>>
>
> I'm not sure to un

Re: [Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

[Marek Olšák]

On Oct 13, 2016 2:10 PM, "Mike Lothian"  wrote:
>
> Alternatively you could expose GLSL 440 until the bugs are squished for
450

We can't expose GL 4.4 and 4.5 without approval from Khronos. I don't know
if that also applies to GLSL, but I'm assuming that it does. Until then,
we're stuck with GL 4.3 + extensions.

Marek

>
> On Thu, 13 Oct 2016 at 12:39 Nicolai Hähnle  wrote:
>>
>> On 13.10.2016 10:20, Andreas Boll wrote:
>> > Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40
--
>> > all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.
>> >
>> > So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".
>> >
>> > Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the
cap on")
>> > Signed-off-by: Andreas Boll 
>>
>> The only place where this could possibly matter is mesamatrix, and
>> frankly, it should be fixed there. There's clearly something wrong
>> there, since it didn't update the display at all.
>>
>> Nicolai
>>
>> > ---
>> >  docs/features.txt | 18 +-
>> >  1 file changed, 9 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/docs/features.txt b/docs/features.txt
>> > index ec2634f..9cc9111 100644
>> > --- a/docs/features.txt
>> > +++ b/docs/features.txt
>> > @@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0,
radeonsi
>> >GL_ARB_vertex_attrib_binding  DONE (all
drivers)
>> >
>> >
>> > -GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>> > +GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
>> >
>> >GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all
drivers)
>> > -  GL_ARB_buffer_storage DONE (i965,
nv50, nvc0, r600)
>> > -  GL_ARB_clear_texture  DONE (i965,
nv50, nvc0, r600)
>> > -  GL_ARB_enhanced_layouts   DONE (i965,
llvmpipe, softpipe)
>> > +  GL_ARB_buffer_storage DONE (i965,
nv50, nvc0, r600, radeonsi)
>> > +  GL_ARB_clear_texture  DONE (i965,
nv50, nvc0, r600, radeonsi)
>> > +  GL_ARB_enhanced_layouts   DONE (i965,
radeonsi, llvmpipe, softpipe)
>> >- compile-time constant expressions   DONE
>> >- explicit byte offsets for blocksDONE
>> >- forced alignment within blocks  DONE
>> > -  - specified vec4-slot component numbers   DONE (i965,
llvmpipe, softpipe)
>> > +  - specified vec4-slot component numbers   DONE (i965,
radeonsi, llvmpipe, softpipe)
>> >- specified transform/feedback layout DONE
>> >- input/output block locationsDONE
>> >GL_ARB_multi_bind DONE (all
drivers)
>> > -  GL_ARB_query_buffer_objectDONE
(i965/hsw+, nvc0)
>> > -  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> > -  GL_ARB_texture_stencil8   DONE
(i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> > -  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> > +  GL_ARB_query_buffer_objectDONE
(i965/hsw+, nvc0, radeonsi)
>> > +  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> > +  GL_ARB_texture_stencil8   DONE
(i965/hsw+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> > +  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> >
>> >  GL 4.5, GLSL 4.50:
>> >
>> >
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] radeonsi: fix indirect loads of 64 bit constants

[Nicolai Hähnle]

From: Nicolai Hähnle 

This fixes GL45-CTS.compute_shader.fp64-case3.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 25146e8..15432b2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1907,25 +1907,25 @@ static LLVMValueRef fetch_constant(
addr = lp_build_mul_imm(&bld_base->uint_bld, addr, 16);
addr = lp_build_add(&bld_base->uint_bld, addr,
lp_build_const_int32(base->gallivm, idx * 4));
 
result = buffer_load_const(ctx, bufp, addr);
 
if (!tgsi_type_is_64bit(type))
result = bitcast(bld_base, type, result);
else {
LLVMValueRef addr2, result2;
-   addr2 = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle + 
1];
+   addr2 = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
addr2 = LLVMBuildLoad(base->gallivm->builder, addr2, "load addr 
reg2");
addr2 = lp_build_mul_imm(&bld_base->uint_bld, addr2, 16);
addr2 = lp_build_add(&bld_base->uint_bld, addr2,
-lp_build_const_int32(base->gallivm, idx * 
4));
+lp_build_const_int32(base->gallivm, (idx + 
1) * 4));
 
result2 = buffer_load_const(ctx, bufp, addr2);
 
result = radeon_llvm_emit_fetch_64bit(bld_base, type,
  result, result2);
}
return result;
 }
 
 /* Upper 16 bits must be zero. */
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] radeonsi: unify the constant load paths

[Nicolai Hähnle]

From: Nicolai Hähnle 

Remove the split between direct and indirect.
---
 src/gallium/drivers/radeonsi/si_shader.c | 39 +---
 1 file changed, 11 insertions(+), 28 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 15432b2..34c6eb1 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1867,66 +1867,49 @@ static LLVMValueRef fetch_constant(
LLVMValueRef values[4];
for (chan = 0; chan < TGSI_NUM_CHANNELS; ++chan)
values[chan] = fetch_constant(bld_base, reg, type, 
chan);
 
return lp_build_gather_values(bld_base->base.gallivm, values, 
4);
}
 
buf = reg->Register.Dimension ? reg->Dimension.Index : 0;
idx = reg->Register.Index * 4 + swizzle;
 
-   if (!reg->Register.Indirect && !reg->Dimension.Indirect) {
-   LLVMValueRef c0, c1, desc;
-
-   desc = load_const_buffer_desc(ctx, buf);
-   c0 = buffer_load_const(ctx, desc,
-  LLVMConstInt(ctx->i32, idx * 4, 0));
-
-   if (!tgsi_type_is_64bit(type))
-   return bitcast(bld_base, type, c0);
-   else {
-   c1 = buffer_load_const(ctx, desc,
-  LLVMConstInt(ctx->i32,
-   (idx + 1) * 4, 0));
-   return radeon_llvm_emit_fetch_64bit(bld_base, type,
-   c0, c1);
-   }
-   }
-
if (reg->Register.Dimension && reg->Dimension.Indirect) {
LLVMValueRef ptr = LLVMGetParam(ctx->radeon_bld.main_fn, 
SI_PARAM_CONST_BUFFERS);
LLVMValueRef index;
index = get_bounded_indirect_index(ctx, ®->DimIndirect,
   reg->Dimension.Index,
   SI_NUM_CONST_BUFFERS);
bufp = build_indexed_load_const(ctx, ptr, index);
} else
bufp = load_const_buffer_desc(ctx, buf);
 
-   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
-   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr reg");
-   addr = lp_build_mul_imm(&bld_base->uint_bld, addr, 16);
-   addr = lp_build_add(&bld_base->uint_bld, addr,
-   lp_build_const_int32(base->gallivm, idx * 4));
+   if (reg->Register.Indirect) {
+   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
+   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr 
reg");
+   addr = lp_build_mul_imm(&bld_base->uint_bld, addr, 16);
+   addr = lp_build_add(&bld_base->uint_bld, addr,
+   lp_build_const_int32(base->gallivm, idx * 
4));
+   } else {
+   addr = LLVMConstInt(ctx->i32, idx * 4, 0);
+   }
 
result = buffer_load_const(ctx, bufp, addr);
 
if (!tgsi_type_is_64bit(type))
result = bitcast(bld_base, type, result);
else {
LLVMValueRef addr2, result2;
-   addr2 = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
-   addr2 = LLVMBuildLoad(base->gallivm->builder, addr2, "load addr 
reg2");
-   addr2 = lp_build_mul_imm(&bld_base->uint_bld, addr2, 16);
-   addr2 = lp_build_add(&bld_base->uint_bld, addr2,
-lp_build_const_int32(base->gallivm, (idx + 
1) * 4));
 
+   addr2 = lp_build_add(&bld_base->uint_bld, addr,
+LLVMConstInt(ctx->i32, 4, 0));
result2 = buffer_load_const(ctx, bufp, addr2);
 
result = radeon_llvm_emit_fetch_64bit(bld_base, type,
  result, result2);
}
return result;
 }
 
 /* Upper 16 bits must be zero. */
 static LLVMValueRef si_llvm_pack_two_int16(struct gallivm_state *gallivm,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] gallium/hud: bugfix: 68169 - Sensor extensions segfaults.

[Steven Toth]

Hello Nicolai

>> On inspection, this was due to the 'unigine' application
>> created the HUD contexts twice (two screens?). The
>> extensions had never been tested in that configuration,
>> and the free_query_data() calls were thus trigger.
>
>
> The HUD is actually created per-context. Two general points that apply
> equally to all four parts of the patch:

Yeah. I didn;t realize this as none of the default use cases ever
exercised this approach.
Now that we have one, I'm happy to adjust it.

>
> Instead of open-coding the users variable, I'd prefer that you use the
> pipe_reference mechanism.

Agreed, done.

It would have been nice if a macro was global created for
pip_reference_inc/dec(obj), instead
of having to call (NULL, obj) and (obj, NULL), and read the code for
the implementation,
but this does not matter at this point.

>
> Contexts can be created and destroyed simultaneously from multiple threads.

In which case yes, we need some exclusivity, I've implemented this
with pipe_mutexes.

> You probably need to protect some of the query functions with a mutex as
> well. The general rule of thumb is that functions associated to a

Yep. Done.

> Thanks for looking into this!

Thank you for the review. I should have a patch available shortly.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] nvc0/ir: be more careful about preserving modifiers in SHLADD creation

[Samuel Pitoiset]

On 10/12/2016 08:42 PM, Ilia Mirkin wrote:

src2 was being given the wrong modifier, and we were not properly
managing the modifier on the SHL source either.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index d88bb34..737bda3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2163,7 +2163,6 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
Value *src1 = add->getSrc(1);
ImmediateValue imm;
Instruction *shl;
-   Modifier mod[2];
Value *src;
int s;

@@ -2182,20 +2181,19 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
src = add->getSrc(s);
shl = src->getUniqueInsn();

-   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp)
+   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp || shl->src(0).mod)


SHL can't have any modifiers, why do you check it here? I would say it's 
just for safety, but if the compiler adds modifiers to SHL something is 
really wrong...


Looks good now.

Reviewed-by: Samuel Pitoiset 


   return false;

if (!shl->src(1).getImmediate(imm))
   return false;

-   mod[0] = add->src(0).mod;
-   mod[1] = add->src(1).mod;
-
add->op = OP_SHLADD;
add->setSrc(2, add->src(!s));
-   add->src(2).mod = mod[s];
-
+   // SHL can't have any modifiers, but the ADD source may have had
+   // one. Preserve it.
add->setSrc(0, shl->getSrc(0));
+   if (s == 1)
+  add->src(0).mod = add->src(1).mod;
add->setSrc(1, new_ImmediateValue(shl->bb->getProgram(), imm.reg.data.u32));
add->src(1).mod = Modifier(0);




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

Re: [Mesa-dev] [PATCH v2] nvc0/ir: be more careful about preserving modifiers in SHLADD creation

[Ilia Mirkin]

On Thu, Oct 13, 2016 at 9:53 AM, Samuel Pitoiset
 wrote:
>
>
> On 10/12/2016 08:42 PM, Ilia Mirkin wrote:
>>
>> src2 was being given the wrong modifier, and we were not properly
>> managing the modifier on the SHL source either.
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 12
>> +---
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> index d88bb34..737bda3 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> @@ -2163,7 +2163,6 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
>> Value *src1 = add->getSrc(1);
>> ImmediateValue imm;
>> Instruction *shl;
>> -   Modifier mod[2];
>> Value *src;
>> int s;
>>
>> @@ -2182,20 +2181,19 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
>> src = add->getSrc(s);
>> shl = src->getUniqueInsn();
>>
>> -   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp)
>> +   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp ||
>> shl->src(0).mod)
>
>
> SHL can't have any modifiers, why do you check it here? I would say it's
> just for safety, but if the compiler adds modifiers to SHL something is
> really wrong...

That's a target-specific property. There could be some future
hypothetical target that allows modifiers on shl. The check is cheap,
so may as well :) If it were a more expensive check, I'd do it in a
#if debug thing maybe.

>
> Looks good now.
>
> Reviewed-by: Samuel Pitoiset 

Thanks!

>
>
>>return false;
>>
>> if (!shl->src(1).getImmediate(imm))
>>return false;
>>
>> -   mod[0] = add->src(0).mod;
>> -   mod[1] = add->src(1).mod;
>> -
>> add->op = OP_SHLADD;
>> add->setSrc(2, add->src(!s));
>> -   add->src(2).mod = mod[s];
>> -
>> +   // SHL can't have any modifiers, but the ADD source may have had
>> +   // one. Preserve it.
>> add->setSrc(0, shl->getSrc(0));
>> +   if (s == 1)
>> +  add->src(0).mod = add->src(1).mod;
>> add->setSrc(1, new_ImmediateValue(shl->bb->getProgram(),
>> imm.reg.data.u32));
>> add->src(1).mod = Modifier(0);
>>
>>
>
> --
> -Samuel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] nvc0/ir: be more careful about preserving modifiers in SHLADD creation

[Samuel Pitoiset]

On 10/13/2016 03:56 PM, Ilia Mirkin wrote:

On Thu, Oct 13, 2016 at 9:53 AM, Samuel Pitoiset
 wrote:



On 10/12/2016 08:42 PM, Ilia Mirkin wrote:


src2 was being given the wrong modifier, and we were not properly
managing the modifier on the SHL source either.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 12
+---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index d88bb34..737bda3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2163,7 +2163,6 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
Value *src1 = add->getSrc(1);
ImmediateValue imm;
Instruction *shl;
-   Modifier mod[2];
Value *src;
int s;

@@ -2182,20 +2181,19 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
src = add->getSrc(s);
shl = src->getUniqueInsn();

-   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp)
+   if (shl->bb != add->bb || shl->usesFlags() || shl->subOp ||
shl->src(0).mod)



SHL can't have any modifiers, why do you check it here? I would say it's
just for safety, but if the compiler adds modifiers to SHL something is
really wrong...


That's a target-specific property. There could be some future
hypothetical target that allows modifiers on shl. The check is cheap,
so may as well :) If it were a more expensive check, I'd do it in a
#if debug thing maybe.


Yeah, hypothetical :)





Looks good now.

Reviewed-by: Samuel Pitoiset 


Thanks!





   return false;

if (!shl->src(1).getImmediate(imm))
   return false;

-   mod[0] = add->src(0).mod;
-   mod[1] = add->src(1).mod;
-
add->op = OP_SHLADD;
add->setSrc(2, add->src(!s));
-   add->src(2).mod = mod[s];
-
+   // SHL can't have any modifiers, but the ADD source may have had
+   // one. Preserve it.
add->setSrc(0, shl->getSrc(0));
+   if (s == 1)
+  add->src(0).mod = add->src(1).mod;
add->setSrc(1, new_ImmediateValue(shl->bb->getProgram(),
imm.reg.data.u32));
add->src(1).mod = Modifier(0);




--
-Samuel


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

Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

[Roland Scheidegger]

Am 13.10.2016 um 11:33 schrieb Marek Olšák:
> On Thu, Oct 13, 2016 at 2:09 AM, Roland Scheidegger  
> wrote:
>> Am 12.10.2016 um 15:29 schrieb Marek Olšák:
>>> From: Marek Olšák 
>>>
>>> For performance tuning in drivers. It filters out window system
>>> framebuffers and OpenGL renderbuffers.
>>>
>>> radeonsi will use this to guess whether a depth buffer will be read
>>> by a shader. There is no guarantee about what will actually happen.
>>>
>>> This is a departure from PIPE_BIND flags which are defined to be strict
>>> but they are useless in practice.
>>> ---
>>>  src/gallium/include/pipe/p_defines.h | 1 +
>>>  src/mesa/state_tracker/st_texture.c  | 3 ++-
>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/include/pipe/p_defines.h 
>>> b/src/gallium/include/pipe/p_defines.h
>>> index db96c51..037ed92 100644
>>> --- a/src/gallium/include/pipe/p_defines.h
>>> +++ b/src/gallium/include/pipe/p_defines.h
>>> @@ -443,20 +443,21 @@ enum pipe_flush_flags
>>>  #define PIPE_BIND_SCANOUT (1 << 19) /*  */
>>>  #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
>>>  #define PIPE_BIND_LINEAR  (1 << 21)
>>>
>>>
>>>  /**
>>>   * Flags for the driver about resource behaviour:
>>>   */
>>>  #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
>>>  #define PIPE_RESOURCE_FLAG_MAP_COHERENT   (1 << 1)
>>> +#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
>>>  #define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private 
>>> */
>>>  #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys 
>>> private */
>>>
>>>  /**
>>>   * Hint about the expected lifecycle of a resource.
>>>   * Sorted according to GPU vs CPU access.
>>>   */
>>>  enum pipe_resource_usage {
>>> PIPE_USAGE_DEFAULT,/* fast GPU access */
>>> PIPE_USAGE_IMMUTABLE,  /* fast GPU access, immutable */
>>> diff --git a/src/mesa/state_tracker/st_texture.c 
>>> b/src/mesa/state_tracker/st_texture.c
>>> index a2c36ac..7b72ffd 100644
>>> --- a/src/mesa/state_tracker/st_texture.c
>>> +++ b/src/mesa/state_tracker/st_texture.c
>>> @@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
>>> memset(&pt, 0, sizeof(pt));
>>> pt.target = target;
>>> pt.format = format;
>>> pt.last_level = last_level;
>>> pt.width0 = width0;
>>> pt.height0 = height0;
>>> pt.depth0 = depth0;
>>> pt.array_size = layers;
>>> pt.usage = PIPE_USAGE_DEFAULT;
>>> pt.bind = bind;
>>> -   pt.flags = 0;
>>> +   /* only set this for OpenGL textures, not renderbuffers */
>>> +   pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
>>> pt.nr_samples = nr_samples;
>>>
>>> newtex = screen->resource_create(screen, &pt);
>>>
>>> assert(!newtex || pipe_is_referenced(&newtex->reference));
>>>
>>> return newtex;
>>>  }
>>>
>>>
>>>
>>
>> I guess, why not... I bet though there are apps which create everything
>> as a texture, regardless if they actually use it for sampling or not. So
>> you still need to try to not perform too bad if you got the hint wrong :-).
>> It's really GL which is useless there, not the PIPE_BIND flags ;-).
> 
> But you have to admit that the new flag is very accurate - it
> represents OpenGL texture objects. That can't be said about most of
> the bind flags.
Yes, for GL that's true. Albeit being a GL texture object doesn't really
tell you anything about its usage. Which is why you have all the
guesswork in the driver in the first place.
The bind flags accurately represent what a resource can be used for.
This is all explicit, no guesswork required - but it requires a api
where this actually is known. And GL isn't that API... Obviously, this
was inspired by d3d10 because the model is so much cleaner. With the
hope that maybe some day GL would have something similar (though in all
fairness, it was probably impossible to change anyway while maintaining
backwards compatibility in a sane way).

Roland


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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Mike Lothian]

If you recompile llvm and mesa each time, are there any downsides of using
the shared libs?

I think there were some issues with some programs / games that had clashing
symbols but I'm not sure if that's still an issue

On Thu, 13 Oct 2016 at 11:15 Emil Velikov  wrote:

> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
> > On 13/10/16 03:37 AM, Tobias Droste wrote:
> >> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
> 
>  +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>  +LLVM_VERSION_REQUIRED_R600=3.6.0
>  +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
> >>>
> >>> There's a small related gotcha: as-is at build time we get the
> >>> different codepaths thus, as people build against shared LLVM (hello
> >>> Archlinux, I'm looking at you) and update their LLVM without
> >>> rebuilding mesa (Arch I'm looking at you again) things go funny.
> >
> > What exactly happened there? LLVM upstream generates shared libraries
> > named libLLVM-..so*, so it shouldn't be possible for a
> > simple LLVM package update to break Mesa, unless Arch did something
> > really stupid.
> >
> The issue is not specific to Arch, but anyone who links against shared
> LLVM.
>
> Here is another take on it:
> At least swr and r600/radeonsi depend at _build_ time on the _patch_
> version of LLVM. The latter of which is not part of the DSO name. Thus
> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
> "3.9.x" codepath even though you are be using "3.9.y" LLVM. If
> anything I'm calling it a LLVM bug, since shared/static library users
> should not need to know patch version, let alone have different
> codepaths based on it. Runtime ones might be ok, compile time
> definitely not.
>
> On our end, we could a) bump the requirement such that there's no
> compile time patch version check, b) suggest static linking or c)
> pretend the {mis,ab,}use isn't there ;-)
>
> >
> >>> Tl;Dr; We really want to enable static linking by default and prod
> >>> distros to use it.
> >>
> >> I'm all in favor of statically linking LLVM (that's the way I'm doing
> this on
> >> my pc).
> >> I think the only reason this is not done is because people (also here
> on the
> >> list) don't want any static linkg of external libraries because of size
> or
> >> whatever.
> >> So changing the default to static is easy, but I doubt it will make
> everyone
> >> happy ;-)
> >
> > Indeed, it'd probably make many distro packagers unhappy, because
> > they'll just have to re-enable shared linking, because packaging
> > policies generally strongly discourage if not outright forbid static
> > linking.
> >
> The toggle is there and is not going away, afaict. If people are going
> to get upset that the default does not meet their policy... just
> toggle and get on with other things ;-)
>
> Thanks
> Emil
> ___
> 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] docs: Fix GL status of radeonsi

[Edward O'Callaghan]

On 10/13/2016 10:39 PM, Nicolai Hähnle wrote:
> On 13.10.2016 10:20, Andreas Boll wrote:
>> Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
>> all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.
>>
>> So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".
>>
>> Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the
>> cap on")
>> Signed-off-by: Andreas Boll 
> 
> The only place where this could possibly matter is mesamatrix, and
> frankly, it should be fixed there. There's clearly something wrong
> there, since it didn't update the display at all.

Just FYI, That is also my position too.

Kind Regards,
Edward.

> 
> Nicolai
> 
>> ---
>>  docs/features.txt | 18 +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/docs/features.txt b/docs/features.txt
>> index ec2634f..9cc9111 100644
>> --- a/docs/features.txt
>> +++ b/docs/features.txt
>> @@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0,
>> radeonsi
>>GL_ARB_vertex_attrib_binding  DONE (all
>> drivers)
>>
>>
>> -GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>> +GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
>>
>>GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all
>> drivers)
>> -  GL_ARB_buffer_storage DONE (i965,
>> nv50, nvc0, r600)
>> -  GL_ARB_clear_texture  DONE (i965,
>> nv50, nvc0, r600)
>> -  GL_ARB_enhanced_layouts   DONE (i965,
>> llvmpipe, softpipe)
>> +  GL_ARB_buffer_storage DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_clear_texture  DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_enhanced_layouts   DONE (i965,
>> radeonsi, llvmpipe, softpipe)
>>- compile-time constant expressions   DONE
>>- explicit byte offsets for blocksDONE
>>- forced alignment within blocks  DONE
>> -  - specified vec4-slot component numbers   DONE (i965,
>> llvmpipe, softpipe)
>> +  - specified vec4-slot component numbers   DONE (i965,
>> radeonsi, llvmpipe, softpipe)
>>- specified transform/feedback layout DONE
>>- input/output block locationsDONE
>>GL_ARB_multi_bind DONE (all
>> drivers)
>> -  GL_ARB_query_buffer_objectDONE
>> (i965/hsw+, nvc0)
>> -  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
>> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> -  GL_ARB_texture_stencil8   DONE
>> (i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> -  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
>> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>> +  GL_ARB_query_buffer_objectDONE
>> (i965/hsw+, nvc0, radeonsi)
>> +  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> +  GL_ARB_texture_stencil8   DONE
>> (i965/hsw+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> +  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>>
>>  GL 4.5, GLSL 4.50:
>>
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



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

[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven

[bugzilla-daemon]

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

Steven Toth  changed:

   What|Removed |Added

 Attachment #127222|0   |1
is obsolete||
 Attachment #127246|0   |1
is obsolete||

--- Comment #29 from Steven Toth  ---
Created attachment 127271
  --> https://bugs.freedesktop.org/attachment.cgi?id=127271&action=edit
Switch to internal reference counting and mutexing.

Replacement, add mutex locking on the lists and using the internal reference
counting implementation.

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

[Mesa-dev] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

[bugzilla-daemon]

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

--- Comment #5 from Randy  ---
We can use the patch (in
https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to
workaround the name issue, while some cases still fail due to wrong property,
like ARRAY_SIZE  

in TargetInterface
{
highp vec4 target[3];
} targetInstance[2];

the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual
return value is 2.

-- 
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 00/15] GLSL memory allocation rework for faster compilation

[Tapani Pälli]

On 10/13/2016 04:20 PM, Juha-Pekka Heikkila wrote:
I forgot to reply here on the list, I've just been talking about this 
with Tapani face to face.


My series rebased and fixed on top of mesa master branch from 
yesterday is here

https://github.com/juhapekka/juha_mesaexperimentals/tree/jenkins

Tapani was already taking rebased patches from above branch.

I originally stopped working on this set because I felt there was too 
much uncertainty if all places needed to be fixed could be found 
easily. Anyway, if you skip my patch for changes in glsl please check 
you have all places somehow handled which I had patched. All those 
patched places I dug up with Valgrind so they're 'real deal' where 
will get segfaults.




I have now all CI regressions (there were 26 in total) passing with this 
set:


https://cgit.freedesktop.org/~tpalli/mesa/log/?h=jenkins

but I'm planning still todo some validation with apps too, as you 
mentioned today as example Manhattan used to trigger some issues.



/Juha-Pekka

On 10.10.2016 14:52, Marek Olšák wrote:

I prefer some of my GLSL fixes in 1-4 over JP's changes, because they
seem cleaner to me.

Marek


On Oct 10, 2016 1:38 PM, "Tapani Pälli" mailto:tapani.pa...@intel.com>> wrote:



On 10/10/2016 02:27 PM, Marek Olšák wrote:

On Mon, Oct 10, 2016 at 1:25 PM, Tapani Pälli
mailto:tapani.pa...@intel.com>> wrote:



On 10/10/2016 01:38 PM, Marek Olšák wrote:


On Mon, Oct 10, 2016 at 12:33 PM, Marek Olšák
mailto:mar...@gmail.com>> wrote:


On Mon, Oct 10, 2016 at 7:58 AM, Tapani Pälli
>

wrote:




On 10/08/2016 06:58 PM, Jason Ekstrand wrote:



FYI, we use ralloc for a lot more than just
the glsl compiler so the
first few changes make me a bit nervous.
There was someone working on
making our driver more I
undefined-memory-friendly but I don't know
what
happened to those patches.




There's bunch of patches like that in this 
series:

https://lists.freedesktop.org/archives/mesa-dev/2016-June/120445.html


it looks like it just never landed as would have
required more testing
on
misc drivers?



We can land at least some of the patches from that
series. We still
have to replace all non-GLSL uses of
DECLARE_RALLOC.. with
DECLARE_RZALLOC.



BTW, people can still give Rbs on all patches except 5.
This rzalloc
thing isn't an issue and can be dealt with in a separate
series (it
can be done after this series lands).



I agree these issues do not block review of the series. We
just need to make
sure it is absolutely safe before landing.

As concrete example I got following segfault when I applied
this series
which is directly related to rzalloc issues. This was with
'shader_freeze'
program, description in bug #94477 has link and build
instructions for this
if you want to try. When I applied JP's patches 4,5,6 (nir,
i965_vec4,
i965_fs changes) this segfault disappears.


I meant that this series is safe to land without patch 5. Did
you test
it without patch 5?


Ah sorry I managed to miss that. Now I did test and when reverting
patch 5 this test passes fine. Makes sense to do patch 5 as a
separate step when JP's changes land.

// Tapani



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



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



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

[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven

[bugzilla-daemon]

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

--- Comment #30 from Steven Toth  ---
Christoph, based on feedback from the mailing list, I made some changes to use
the MESA internal reference counting mechanisms which makes sensor and other
cleanup a little more robust.

The patch tests fine for me with glxgears, but due to some hardware issues I no
longer have access to a working unigine environment.

If you have a moment, can you please remove all of my earlier patches and apply
the mutex-reference.patch and check that it's still working for with unigine?

Specifically, that you still have values in all graphs and that you no longer
see the sensor_cleanup() crash?

Many thanks.

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

Re: [Mesa-dev] [PATCH mesa] swr: [rasterizer common] fix assert index

[Rowley, Timothy O]

Reviewed-by: Tim Rowley 
mailto:timothy.o.row...@intel.com>>

On Oct 12, 2016, at 4:13 PM, Eric Engestrom 
mailto:e...@engestrom.ch>> wrote:

Fixes: b3bd8bb611bb465d2e5e ("swr: [rasterizer core] add support
  for "RAW" surface format")
CovID: 1373647
Signed-off-by: Eric Engestrom mailto:e...@engestrom.ch>>
---
src/gallium/drivers/swr/rasterizer/common/formats.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/rasterizer/common/formats.h 
b/src/gallium/drivers/swr/rasterizer/common/formats.h
index 539e37a..dd5b499 100644
--- a/src/gallium/drivers/swr/rasterizer/common/formats.h
+++ b/src/gallium/drivers/swr/rasterizer/common/formats.h
@@ -248,7 +248,7 @@ extern const SWR_FORMAT_INFO gFormatInfo[NUM_SWR_FORMATS];
/// @param format - SWR format
INLINE const SWR_FORMAT_INFO& GetFormatInfo(SWR_FORMAT format)
{
-SWR_ASSERT(format <= NUM_SWR_FORMATS, "Invalid Surface Format: %d", 
format);
+SWR_ASSERT(format < NUM_SWR_FORMATS, "Invalid Surface Format: %d", format);
SWR_ASSERT(gFormatInfo[format].name != nullptr, "Invalid Surface Format: 
%d", format);
return gFormatInfo[format];
}
--
Cheers,
 Eric


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

[Mesa-dev] [PATCH 2/5] st/mesa: fix fragment shader output mapping

[Nicolai Hähnle]

From: Nicolai Hähnle 

Properly handle the case where there is a gap in the assigned output locations,
e.g. a fragment shader writes to color buffer 2 but not to color buffers 0 & 1.

Fixes 
GL45-CTS.gtf33.GL3Tests.explicit_attrib_location.explicit_attrib_location_pipeline.
---
 src/mesa/state_tracker/st_program.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 91887dc..7cc36b4 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -775,21 +775,20 @@ st_translate_fragment_program(struct st_context *st,
   }
   else {
  inputMapping[attr] = -1;
   }
}
 
/*
 * Semantics and mapping for outputs
 */
{
-  uint numColors = 0;
   GLbitfield64 outputsWritten = stfp->Base.Base.OutputsWritten;
 
   /* if z is written, emit that first */
   if (outputsWritten & BITFIELD64_BIT(FRAG_RESULT_DEPTH)) {
  fs_output_semantic_name[fs_num_outputs] = TGSI_SEMANTIC_POSITION;
  fs_output_semantic_index[fs_num_outputs] = 0;
  outputMapping[FRAG_RESULT_DEPTH] = fs_num_outputs;
  fs_num_outputs++;
  outputsWritten &= ~(1 << FRAG_RESULT_DEPTH);
   }
@@ -819,29 +818,39 @@ st_translate_fragment_program(struct st_context *st,
  if (written & BITFIELD64_BIT(loc)) {
 switch (loc) {
 case FRAG_RESULT_DEPTH:
 case FRAG_RESULT_STENCIL:
 case FRAG_RESULT_SAMPLE_MASK:
/* handled above */
assert(0);
break;
 case FRAG_RESULT_COLOR:
write_all = GL_TRUE; /* fallthrough */
-default:
+default: {
+   int index;
assert(loc == FRAG_RESULT_COLOR ||
   (FRAG_RESULT_DATA0 <= loc && loc < FRAG_RESULT_MAX));
+
+   index = (loc == FRAG_RESULT_COLOR) ? 0 : (loc - 
FRAG_RESULT_DATA0);
+
+   if (attr >= FRAG_RESULT_MAX) {
+  /* Secondary color for dual source blending. */
+  assert(index == 0);
+  index++;
+   }
+
fs_output_semantic_name[fs_num_outputs] = TGSI_SEMANTIC_COLOR;
-   fs_output_semantic_index[fs_num_outputs] = numColors;
+   fs_output_semantic_index[fs_num_outputs] = index;
outputMapping[attr] = fs_num_outputs;
-   numColors++;
break;
 }
+}
 
 fs_num_outputs++;
  }
   }
}
 
if (stfp->shader_program) {
   nir_shader *nir = st_glsl_to_nir(st, &stfp->Base.Base,
stfp->shader_program,
MESA_SHADER_FRAGMENT);
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/5] st/glsl_to_tgsi: fix atomic counter addressing

[Nicolai Hähnle]

From: Nicolai Hähnle 

When more than one atomic counter buffer is in use, UniformStorage[n].opaque
is set up to contain indices that are contiguous across all used buffers.

This appears to be used by i965 via NIR, but for TGSI we do not treat atomic
counter buffers as opaque, so using the data in the opaque array is incorrect.

Fixes GL45-CTS.compute_shader.resource-atomic-counter.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index a7ea19f..682c034 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -545,21 +545,22 @@ public:
 
void emit_scalar(ir_instruction *ir, unsigned op,
 st_dst_reg dst, st_src_reg src0, st_src_reg src1);
 
void emit_arl(ir_instruction *ir, st_dst_reg dst, st_src_reg src0);
 
void get_deref_offsets(ir_dereference *ir,
   unsigned *array_size,
   unsigned *base,
   unsigned *index,
-  st_src_reg *reladdr);
+  st_src_reg *reladdr,
+  bool opaque);
   void calc_deref_offsets(ir_dereference *head,
   ir_dereference *tail,
   unsigned *array_elements,
   unsigned *base,
   unsigned *index,
   st_src_reg *indirect,
   unsigned *location);
st_src_reg canonicalize_gather_offset(st_src_reg offset);
 
bool try_emit_mad(ir_expression *ir,
@@ -3247,21 +3248,21 @@ 
glsl_to_tgsi_visitor::visit_atomic_counter_intrinsic(ir_call *ir)
ir_dereference *deref = static_cast(param);
ir_variable *location = deref->variable_referenced();
 
st_src_reg buffer(
  PROGRAM_BUFFER, location->data.binding, GLSL_TYPE_ATOMIC_UINT);
 
/* Calculate the surface offset */
st_src_reg offset;
unsigned array_size = 0, base = 0, index = 0;
 
-   get_deref_offsets(deref, &array_size, &base, &index, &offset);
+   get_deref_offsets(deref, &array_size, &base, &index, &offset, false);
 
if (offset.file != PROGRAM_UNDEFINED) {
   emit_asm(ir, TGSI_OPCODE_MUL, st_dst_reg(offset),
offset, st_src_reg_for_int(ATOMIC_COUNTER_SIZE));
   emit_asm(ir, TGSI_OPCODE_ADD, st_dst_reg(offset),
offset, st_src_reg_for_int(location->data.offset + index * 
ATOMIC_COUNTER_SIZE));
} else {
   offset = st_src_reg_for_int(location->data.offset + index * 
ATOMIC_COUNTER_SIZE);
}
 
@@ -3578,21 +3579,21 @@ glsl_to_tgsi_visitor::visit_image_intrinsic(ir_call *ir)
 
ir_dereference *img = (ir_dereference *)param;
const ir_variable *imgvar = img->variable_referenced();
const glsl_type *type = imgvar->type->without_array();
unsigned sampler_array_size = 1, sampler_base = 0;
 
st_src_reg reladdr;
st_src_reg image(PROGRAM_IMAGE, 0, GLSL_TYPE_UINT);
 
get_deref_offsets(img, &sampler_array_size, &sampler_base,
- (unsigned int *)&image.index, &reladdr);
+ (unsigned int *)&image.index, &reladdr, true);
if (reladdr.file != PROGRAM_UNDEFINED) {
   image.reladdr = ralloc(mem_ctx, st_src_reg);
   *image.reladdr = reladdr;
   emit_arl(ir, sampler_reladdr, reladdr);
}
 
st_dst_reg dst = undef_dst;
if (ir->return_deref) {
   ir->return_deref->accept(this);
   dst = st_dst_reg(this->result);
@@ -3960,21 +3961,22 @@ glsl_to_tgsi_visitor::calc_deref_offsets(ir_dereference 
*head,
default:
   break;
}
 }
 
 void
 glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference *ir,
 unsigned *array_size,
 unsigned *base,
 unsigned *index,
-st_src_reg *reladdr)
+st_src_reg *reladdr,
+bool opaque)
 {
GLuint shader = _mesa_program_enum_to_shader_stage(this->prog->Target);
unsigned location = 0;
ir_variable *var = ir->variable_referenced();
 
memset(reladdr, 0, sizeof(*reladdr));
reladdr->file = PROGRAM_UNDEFINED;
 
*base = 0;
*array_size = 1;
@@ -3985,21 +3987,22 @@ glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference 
*ir,
 
/*
 * If we end up with no indirect then adjust the base to the index,
 * and set the array size to 1.
 */
if (reladdr->file == PROGRAM_UNDEFINED) {
   *base = *index;
   *array_size = 1;
}
 
-   if (location != 0x) {
+   if (opaque) {
+  assert(location != 0x);
   *base += 
this->shader_program->UniformStorage[location].opaque[shader].index;
   *index +=

[Mesa-dev] [PATCH 5/5] st/glsl_to_tgsi: fix [ui]vec[34] conversion to double

[Nicolai Hähnle]

From: Nicolai Hähnle 

The corresponding opcodes for integers need to be treated the same as F2D.

Fixes GL45-CTS.gpu_shader_fp64.conversions.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 682c034..f49a873 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -862,22 +862,23 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
unsigned op,
   dinst->src[j].index++;
   }
 
if (swz & 1)
   dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_Z, SWIZZLE_W, 
SWIZZLE_Z, SWIZZLE_W);
else
   dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, 
SWIZZLE_X, SWIZZLE_Y);
 
 } else {
/* some opcodes are special case in what they use as sources
-  - F2D is a float src0, DLDEXP is integer src1 */
-   if (op == TGSI_OPCODE_F2D ||
+  - [FUI]2D/[UI]2I64 is a float/[u]int src0, DLDEXP is integer 
src1 */
+   if (op == TGSI_OPCODE_F2D || op == TGSI_OPCODE_U2D || op == 
TGSI_OPCODE_I2D ||
+   op == TGSI_OPCODE_I2I64 || op == TGSI_OPCODE_U2I64 ||
op == TGSI_OPCODE_DLDEXP ||
(op == TGSI_OPCODE_UCMP && dst_is_64bit[0])) {
   dinst->src[j].swizzle = MAKE_SWIZZLE4(swz, swz, swz, swz);
}
 }
  }
   }
   inst = dinst;
} else {
   this->instructions.push_tail(inst);
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/5] st/glsl_to_tgsi: fix a corner case of std140 layout in uniform buffers

[Nicolai Hähnle]

From: Nicolai Hähnle 

See the comment in the code for an explanation. This fixes
GL45-CTS.buffer_storage.map_persistent_draw.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index fd2485d..a7ea19f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2103,22 +2103,49 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* 
ir, st_src_reg *op)
   cbuf.negate = 0;
 
   assert(ir->type->is_vector() || ir->type->is_scalar());
 
   if (const_offset_ir) {
  /* Constant index into constant buffer */
  cbuf.reladdr = NULL;
  cbuf.index = const_offset / 16;
   }
   else {
+ ir_expression *offset_expr = ir->operands[1]->as_expression();
+ st_src_reg offset = op[1];
+
+ /* The OpenGL spec is written in such a way that accesses with
+  * non-constant offset are almost always vec4-aligned. The only
+  * exception to this are members of structs in arrays of structs:
+  * each struct in an array of structs is at least vec4-aligned,
+  * but single-element and [ui]vec2 members of the struct may be at
+  * an offset that is not a multiple of 16 bytes.
+  *
+  * Here, we extract that offset, relying on previous passes to always
+  * generate offset expressions of the form (+ expr constant_offset).
+  *
+  * Note that the std430 layout, which allows more cases of alignment
+  * less than vec4 in arrays, is not supported for uniform blocks, so
+  * we do not have to deal with it here.
+  */
+ if (offset_expr && offset_expr->operation == ir_binop_add) {
+const_offset_ir = offset_expr->operands[1]->as_constant();
+if (const_offset_ir) {
+   const_offset = const_offset_ir->value.u[0];
+   cbuf.index = const_offset / 16;
+   offset_expr->operands[0]->accept(this);
+   offset = this->result;
+}
+ }
+
  /* Relative/variable index into constant buffer */
- emit_asm(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
+ emit_asm(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), offset,
   st_src_reg_for_int(4));
  cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
  memcpy(cbuf.reladdr, &index_reg, sizeof(index_reg));
   }
 
   if (const_uniform_block) {
  /* Constant constant buffer */
  cbuf.reladdr2 = NULL;
  cbuf.index2D = const_block;
  cbuf.has_index2 = true;
-- 
2.7.4

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

Re: [Mesa-dev] Required-for-rendering internal formats

[Ilia Mirkin]

Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal for a
format to be not renderable when used as a texture vs renderbuffer?

On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin  wrote:
> Right, but it'd break st/nine which doesn't (didn't?) support
> fallbacks like st/mesa does.
>
> I'm trying to better understand what the required logic is based on
> the spec, not how to fix this particular application's rendering with
> nouveau (which I'm much less concerned about, tbh).
>
>   -ilia
>
> On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák  wrote:
>> Dropping texturing support for RGBA4 would resolve that issue.
>>
>> Marek
>>
>> On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin  wrote:
>>> Hello,
>>>
>>> Is there a concept in OpenGL that certain internal formats *must* be
>>> supported for rendering? An issue we're running into is that NVIDIA
>>> hardware supports sampling from RGBA4 textures, but does not support
>>> that as a render format. So if you create a tex image with GL_RGBA4,
>>> we use that as the TexFormat, since we can sample from it. However
>>> then attaching the image to a fbo makes that fbo incomplete.
>>>
>>> At least one application isn't ready to handle that situation. Is the
>>> application wrong, or must we support GL_RGBA4 as a renderable texture
>>> attachment format, thus meaning that we should never actually make use
>>> of the hw's RGBA4 sampling capabilities (since we never know if a
>>> texture will later be used for rendering)?
>>>
>>> The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core
>>> spec marks GL_RGBA4 as "required renderable", but I think that only
>>> affects renderbuffers (which st/mesa handles properly by falling back
>>> to RGBA8 when the requested format is not renderable).
>>>
>>> Any advice welcome.
>>>
>>> Cheers,
>>>
>>>   -ilia
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/5] glsl: print non-zero bindings of variables

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/compiler/glsl/ir_print_visitor.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
b/src/compiler/glsl/ir_print_visitor.cpp
index c238c16..efb728b 100644
--- a/src/compiler/glsl/ir_print_visitor.cpp
+++ b/src/compiler/glsl/ir_print_visitor.cpp
@@ -158,20 +158,24 @@ print_type(FILE *f, const glsl_type *t)
 
 void ir_print_visitor::visit(ir_rvalue *)
 {
fprintf(f, "error");
 }
 
 void ir_print_visitor::visit(ir_variable *ir)
 {
fprintf(f, "(declare ");
 
+   char binding[32] = {0};
+   if (ir->data.binding)
+  snprintf(binding, sizeof(binding), "binding=%i ", ir->data.binding);
+
char loc[32] = {0};
if (ir->data.location != -1)
   snprintf(loc, sizeof(loc), "location=%i ", ir->data.location);
 
char component[32] = {0};
if (ir->data.explicit_component)
   snprintf(component, sizeof(component), "component=%i ", 
ir->data.location_frac);
 
const char *const cent = (ir->data.centroid) ? "centroid " : "";
const char *const samp = (ir->data.sample) ? "sample " : "";
@@ -180,22 +184,22 @@ void ir_print_visitor::visit(ir_variable *ir)
const char *const prec = (ir->data.precise) ? "precise " : "";
const char *const mode[] = { "", "uniform ", "shader_storage ",
 "shader_shared ", "shader_in ", "shader_out ",
 "in ", "out ", "inout ",
"const_in ", "sys ", "temporary " };
STATIC_ASSERT(ARRAY_SIZE(mode) == ir_var_mode_count);
const char *const stream [] = {"", "stream1 ", "stream2 ", "stream3 "};
const char *const interp[] = { "", "smooth", "flat", "noperspective" };
STATIC_ASSERT(ARRAY_SIZE(interp) == INTERP_MODE_COUNT);
 
-   fprintf(f, "(%s%s%s%s%s%s%s%s%s%s) ",
-   loc, component, cent, samp, patc, inv, prec, mode[ir->data.mode],
+   fprintf(f, "(%s%s%s%s%s%s%s%s%s%s%s) ",
+   binding, loc, component, cent, samp, patc, inv, prec, 
mode[ir->data.mode],
stream[ir->data.stream],
interp[ir->data.interpolation]);
 
print_type(f, ir->type);
fprintf(f, " %s)", unique_name(ir));
 }
 
 
 void ir_print_visitor::visit(ir_function_signature *ir)
 {
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] radv: Fix incorrect comment

[Tom Stellard]

---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e6ff7c8..9c764c7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2373,8 +2373,8 @@ static void visit_image_store(struct nir_to_llvm_context 
*ctx,
bool da = glsl_sampler_type_is_array(type) ||
  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
 
-   params[0] = get_src(ctx, instr->src[2]); /* coords */
-   params[1] = get_image_coords(ctx, instr, false);
+   params[0] = get_src(ctx, instr->src[2]);
+   params[1] = get_image_coords(ctx, instr, false); /* coords */
params[2] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[3] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
params[4] = i1false;  /* r128 */
-- 
2.7.4

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #8 from shinji.suz...@gmail.com ---
Comment on attachment 127267
  --> https://bugs.freedesktop.org/attachment.cgi?id=127267
Lock the shared state mutex and work with a local reference of so->fence

Review of attachment 127267:
-

I'm afraid execution of st_fence_sync() can still race.
Thread-A can run upto
  success = screen->fence_finish(screen, pipe, fence, 0);
and then get prempted and Thread-B can run upto the same location.
And then
  screen->fence_reference(screen, &so->fence, NULL);
can still be executed in arbitrary order. If screen->fence_refrence()
is thread-safe and return true only for the first invocation then all is fine
but likely it is not true as otherwise we will not be struggling with this
issue.
I think the gist of it is that checking of so->fence and nullifying of it
should be executed atomically. If "if (success)" is replaced with "if (success
&& so->fence)" then the program may behave correctly but I'm not confortable
about sreen->fence_ference() being called concurrently.
I'm also concerned that mutual exclusion on ctx->Shared->Mutex may introduce
unnecessarily strict serialization. 
Can't we introduce per sync-object mutex so that excution of checking of
so->fence and nullyfying of it happen atomically?
Is that modification too intrusive? (At least it is unnecessary overhead when
st_fence_sync() is not executed concurrently on the same sync object.)

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #9 from shinji.suz...@gmail.com ---
oops. I'm getting confused. Concurrent programmingis hard.
> screen->fence_reference(screen, &so->fence, NULL);
will not be executed in arbitrary order but serially due to the mutex locking.
Still the out come should be a segfault in the thread that comes late.

-- 
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 2/2] radv: Use new image load/store intrinsic signatures

[Tom Stellard]

These were changed in LLVM r284024.
---
 src/amd/common/ac_nir_to_llvm.c | 131 
 1 file changed, 107 insertions(+), 24 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 9c764c7..4fba7d3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
nir_to_llvm_context *ctx,
return res;
 }
 
+static void build_type_name_for_intr(
+LLVMTypeRef type,
+char *buf, unsigned bufsize)
+{
+LLVMTypeRef elem_type = type;
+
+assert(bufsize >= 8);
+
+if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
+int ret = snprintf(buf, bufsize, "v%u",
+LLVMGetVectorSize(type));
+if (ret < 0) {
+char *type_name = LLVMPrintTypeToString(type);
+fprintf(stderr, "Error building type name for: %s\n",
+type_name);
+return;
+}
+elem_type = LLVMGetElementType(type);
+buf += ret;
+bufsize -= ret;
+}
+switch (LLVMGetTypeKind(elem_type)) {
+default: break;
+case LLVMIntegerTypeKind:
+snprintf(buf, bufsize, "i%d", LLVMGetIntTypeWidth(elem_type));
+break;
+case LLVMFloatTypeKind:
+snprintf(buf, bufsize, "f32");
+break;
+case LLVMDoubleTypeKind:
+snprintf(buf, bufsize, "f64");
+break;
+}
+}
+
+static void get_image_intr_name(const char *base_name,
+LLVMTypeRef data_type,
+LLVMTypeRef coords_type,
+LLVMTypeRef rsrc_type,
+char *out_name, unsigned out_len)
+{
+char coords_type_name[8];
+
+build_type_name_for_intr(coords_type, coords_type_name,
+sizeof(coords_type_name));
+
+if (HAVE_LLVM <= 0x0309) {
+snprintf(out_name, out_len, "%s.%s", base_name, 
coords_type_name);
+} else {
+char data_type_name[8];
+char rsrc_type_name[8];
+
+build_type_name_for_intr(data_type, data_type_name,
+sizeof(data_type_name));
+build_type_name_for_intr(rsrc_type, rsrc_type_name,
+sizeof(rsrc_type_name));
+snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
+ data_type_name, coords_type_name, rsrc_type_name);
+}
+}
+
 static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
 nir_intrinsic_instr *instr)
 {
LLVMValueRef params[7];
LLVMValueRef res;
-   char intrinsic_name[32];
-   char coords_type[8];
+   char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = var->type;
if(instr->variables[0]->deref.child)
@@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
nir_to_llvm_context *ctx,
res = trim_vector(ctx, res, instr->dest.ssa.num_components);
res = to_integer(ctx, res);
} else {
-   bool da = glsl_sampler_type_is_array(type) ||
- glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
+   bool is_da = glsl_sampler_type_is_array(type) ||
+glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
bool add_frag_pos = glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS;
+   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
+   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
+   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
 
params[0] = get_image_coords(ctx, instr, add_frag_pos);
params[1] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
-   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
-   params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
-   params[5] = LLVMConstInt(ctx->i1, 0, false);  /* glc */
-   params[6] = LLVMConstInt(ctx->i1, 0, false);  /* slc */
+   if (HAVE_LLVM <= 0x0309) {
+   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
+   params[4] = da;
+   params[5] = glc;
+   params[6] = slc;
+   } else {
+   LLVMValueRef lwe = LLVMConstInt(ctx->i1, 0, false);
+   params[3] = glc;
+   

Re: [Mesa-dev] Required-for-rendering internal formats

[Nicolai Hähnle]

On 13.10.2016 17:15, Ilia Mirkin wrote:

Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal for a
format to be not renderable when used as a texture vs renderbuffer?


I think the spec is pretty clear that the "req.rend." column of that 
table is only for renderbuffers.


It's a lot less clear about what really matters for this question. In 
section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:


Each color attachment may be in any of the color-renderable
formats described in section 9.4 (although implementations
are not required to support creation of attachments in all
color-renderable formats).

Color-renderable formats are those which have a checkmark in the CR 
column according to section 9.4. That means pretty much _all_ 
non-compressed formats (except for the shared exponents one). I doubt 
that the intention is to force stuff like R3_G3_B2 to be renderable.


It's kind of funny that the sentence says that the attachments may be in 
any of these formats, but you may not be able to create the attachments?


I think what that's trying to say is that the implementation MUST reject 
color attachments that are not CR according to table 8.12, and it MAY 
reject color attachments of any format it likes.


So I tend to side with the interpretation that exposing RGBA4 as texture 
format but not allowing to render to it is okay by the spec, and the 
application has a bug. It's pretty ridiculous though that apparently the 
spec doesn't even mandate that RGBA8 must be renderable.


Cheers,
Nicolai




On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin  wrote:

Right, but it'd break st/nine which doesn't (didn't?) support
fallbacks like st/mesa does.

I'm trying to better understand what the required logic is based on
the spec, not how to fix this particular application's rendering with
nouveau (which I'm much less concerned about, tbh).

  -ilia

On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák  wrote:

Dropping texturing support for RGBA4 would resolve that issue.

Marek

On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin  wrote:

Hello,

Is there a concept in OpenGL that certain internal formats *must* be
supported for rendering? An issue we're running into is that NVIDIA
hardware supports sampling from RGBA4 textures, but does not support
that as a render format. So if you create a tex image with GL_RGBA4,
we use that as the TexFormat, since we can sample from it. However
then attaching the image to a fbo makes that fbo incomplete.

At least one application isn't ready to handle that situation. Is the
application wrong, or must we support GL_RGBA4 as a renderable texture
attachment format, thus meaning that we should never actually make use
of the hw's RGBA4 sampling capabilities (since we never know if a
texture will later be used for rendering)?

The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core
spec marks GL_RGBA4 as "required renderable", but I think that only
affects renderbuffers (which st/mesa handles properly by falling back
to RGBA8 when the requested format is not renderable).

Any advice welcome.

Cheers,

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

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


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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #10 from shinji.suz...@gmail.com ---
>I'm not confortable about sreen->fence_ference() being called concurrently.

I'm not comfortable about sreen->fence_finish() being called concurrently.

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

[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven

[bugzilla-daemon]

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

--- Comment #31 from Christoph Haag  ---
Yes, your new patch works. No crashing, all panes are visible and show the
correct values.

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #11 from shinji.suz...@gmail.com ---
Sorry I've made too many mistake in writing. (Should have gone to bed before
writing.) I'll rewrite whole post below.

I'm afraid execution of st_fence_sync() can still race.
Thread-A can run upto
  success = screen->fence_finish(screen, pipe, fence, 0);
and then get preempted and Thread-B can run upto the same location.
And then
  screen->fence_reference(screen, &so->fence, NULL);
will be executed serially by both threads. If screen->fence_finish()
is thread-safe and return true only for the first invocation then all is fine
but likely it is not true as otherwise we will not be struggling with this
issue.
I think the gist of it is that checking of so->fence and nullifying of it
should be executed atomically. If "if (success)" is replaced with "if (success
&& so->fence)" then the program may behave correctly but I'm still not
comfortable about sreen->fence_finish() being called concurrently.
I'm also concerned that mutual exclusion on ctx->Shared->Mutex may introduce
unnecessarily strict serialization. 
Can't we introduce per sync-object mutex so that excution of checking of
so->fence and nullyfying of it happen atomically?
Is that modification too intrusive? (At least it is unnecessary overhead when
st_fence_sync() is not executed concurrently on the same sync object.)

-- 
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] radeonsi: implement TC-compatible HTILE

[Nicolai Hähnle]

On 12.10.2016 15:54, Marek Olšák wrote:

From: Marek Olšák 

so that decompress blits aren't needed and depth texturing needs less
memory bandwidth.

Z16 and Z24 are promoted to Z32_FLOAT by the driver, because TC-compatible
HTILE only supports Z32_FLOAT. This doubles memory footprint for Z16.
The format promotion is not visible to state trackers.

This is part of TC-compatible renderbuffer compression, which has 3 parts:
DCC, HTILE, FMASK. Only TC-compatible FMASK compression is missing now.

I don't see a measurable increase in performance though.

(I tested Talos Principle and DiRT: Showdown, the latter is improved by
 0.5%, which is almost noise, and it originally used layered Z16,
 so at least we know that Z16 promoted to Z32F isn't slower now)


Reviewed-by: Nicolai Hähnle 


---
 src/gallium/drivers/radeon/r600_pipe_common.h  |  3 ++
 src/gallium/drivers/radeon/r600_texture.c  | 67 ++
 src/gallium/drivers/radeon/radeon_winsys.h |  4 ++
 src/gallium/drivers/radeonsi/si_blit.c | 11 -
 src/gallium/drivers/radeonsi/si_descriptors.c  |  7 ++-
 src/gallium/drivers/radeonsi/si_shader.c   | 18 ++-
 src/gallium/drivers/radeonsi/si_state.c| 39 +--
 src/gallium/drivers/radeonsi/si_state_draw.c   |  3 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 57 --
 9 files changed, 185 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 290b228..5cfcad6 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -238,27 +238,29 @@ struct r600_cmask_info {
unsigned yalign;
unsigned slice_tile_max;
unsigned base_address_reg;
 };

 struct r600_htile_info {
unsigned pitch;
unsigned height;
unsigned xalign;
unsigned yalign;
+   unsigned alignment;
 };

 struct r600_texture {
struct r600_resourceresource;

uint64_tsize;
unsignednum_level0_transfers;
+   enum pipe_formatdb_render_format;
boolis_depth;
booldb_compatible;
boolcan_sample_z;
boolcan_sample_s;
unsigneddirty_level_mask; /* each bit says if 
that mipmap is compressed */
unsignedstencil_dirty_level_mask; /* each bit 
says if that mipmap is compressed */
struct r600_texture *flushed_depth_texture;
struct radeon_surf  surface;

/* Colorbuffer compression and fast clear. */
@@ -266,20 +268,21 @@ struct r600_texture {
struct r600_cmask_info  cmask;
struct r600_resource*cmask_buffer;
uint64_tdcc_offset; /* 0 = disabled */
unsignedcb_color_info; /* fast clear enable bit 
*/
unsignedcolor_clear_value[2];
unsignedlast_msaa_resolve_target_micro_mode;

/* Depth buffer compression and fast clear. */
struct r600_htile_info  htile;
struct r600_resource*htile_buffer;
+   booltc_compatible_htile;
booldepth_cleared; /* if it was cleared at 
least once */
float   depth_clear_value;
boolstencil_cleared; /* if it was cleared 
at least once */
uint8_t stencil_clear_value;

boolnon_disp_tiling; /* R600-Cayman only */

/* Whether the texture is a displayable back buffer and needs DCC
 * decompression, which is expensive. Therefore, it's enabled only
 * if statistics suggest that it will pay off and it's allocated
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 57cdbcf..625d091 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -185,21 +185,22 @@ static unsigned r600_texture_get_offset(struct 
r600_texture *rtex, unsigned leve
return rtex->surface.level[level].offset +
   box->z * rtex->surface.level[level].slice_size +
   box->y / util_format_get_blockheight(format) * 
rtex->surface.level[level].pitch_bytes +
   box->x / util_format_get_blockwidth(format) * 
util_format_get_blocksize(format);
 }

 static int r600_init_surface(struct r600_common_screen *rscreen,
 struct radeon_surf *surface,
 const struct pipe_resource *ptex,
 unsigned array_mode,
-  

Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle 

On 12.10.2016 15:29, Marek Olšák wrote:

From: Marek Olšák 

For performance tuning in drivers. It filters out window system
framebuffers and OpenGL renderbuffers.

radeonsi will use this to guess whether a depth buffer will be read
by a shader. There is no guarantee about what will actually happen.

This is a departure from PIPE_BIND flags which are defined to be strict
but they are useless in practice.
---
 src/gallium/include/pipe/p_defines.h | 1 +
 src/mesa/state_tracker/st_texture.c  | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index db96c51..037ed92 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -443,20 +443,21 @@ enum pipe_flush_flags
 #define PIPE_BIND_SCANOUT (1 << 19) /*  */
 #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
 #define PIPE_BIND_LINEAR  (1 << 21)


 /**
  * Flags for the driver about resource behaviour:
  */
 #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
 #define PIPE_RESOURCE_FLAG_MAP_COHERENT   (1 << 1)
+#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
 #define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
 #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys 
private */

 /**
  * Hint about the expected lifecycle of a resource.
  * Sorted according to GPU vs CPU access.
  */
 enum pipe_resource_usage {
PIPE_USAGE_DEFAULT,/* fast GPU access */
PIPE_USAGE_IMMUTABLE,  /* fast GPU access, immutable */
diff --git a/src/mesa/state_tracker/st_texture.c 
b/src/mesa/state_tracker/st_texture.c
index a2c36ac..7b72ffd 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
memset(&pt, 0, sizeof(pt));
pt.target = target;
pt.format = format;
pt.last_level = last_level;
pt.width0 = width0;
pt.height0 = height0;
pt.depth0 = depth0;
pt.array_size = layers;
pt.usage = PIPE_USAGE_DEFAULT;
pt.bind = bind;
-   pt.flags = 0;
+   /* only set this for OpenGL textures, not renderbuffers */
+   pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
pt.nr_samples = nr_samples;

newtex = screen->resource_create(screen, &pt);

assert(!newtex || pipe_is_referenced(&newtex->reference));

return newtex;
 }




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

[Mesa-dev] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

[bugzilla-daemon]

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

--- Comment #6 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
(In reply to Randy from comment #5)
> We can use the patch (in
> https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to
> workaround the name issue, while some cases still fail due to wrong
> property, like ARRAY_SIZE  

The problem is that the spec is contradictory. The patch on that link (that
btw, the author is Kenneth, that wrote comment 1) fixes some deqp and CTS
tests. But it causes some regressions on others, like you mention below.

So at this point, I really think that it would be better to wait for a
resolution from Khronos on relation to the text of the spec, issue 16 in
particular, and then fix the tests.

> 
> in TargetInterface
> {
> highp vec4 target[3];
> } targetInstance[2];
> 
> the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual
> return value is 2.

-- 
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 2/2] radeonsi: adjust and clean up Z_ORDER and EXEC_ON_x settings

[Nicolai Hähnle]

The series is

Reviewed-by: Nicolai Hähnle 

On 12.10.2016 23:19, Marek Olšák wrote:

From: Marek Olšák 

The table was copied from the Vulkan driver. The comment lines are as long
as the table for cosmetic reasons.
---
 src/gallium/drivers/radeonsi/si_shader.h|  1 -
 src/gallium/drivers/radeonsi/si_state_shaders.c | 53 +++--
 2 files changed, 32 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index f2618ac..b07210c 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -432,21 +432,20 @@ struct si_shader {

struct si_shader_part   *prolog;
struct si_shader_part   *epilog;

struct si_shader*gs_copy_shader;
struct si_pm4_state *pm4;
struct r600_resource*bo;
struct r600_resource*scratch_bo;
union si_shader_key key;
boolis_binary_shared;
-   unsignedz_order;

/* The following data is all that's needed for binary shaders. */
struct radeon_shader_binary binary;
struct si_shader_config config;
struct si_shader_info   info;

/* Shader key + LLVM IR + disassembly + statistics.
 * Generated for debug contexts only.
 */
char*shader_log;
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index be5c659..d339b84 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -800,34 +800,20 @@ static void si_shader_ps(struct si_shader *shader)

si_pm4_set_reg(pm4, R_00B028_SPI_SHADER_PGM_RSRC1_PS,
   S_00B028_VGPRS((shader->config.num_vgprs - 1) / 4) |
   S_00B028_SGPRS((shader->config.num_sgprs - 1) / 8) |
   S_00B028_DX10_CLAMP(1) |
   S_00B028_FLOAT_MODE(shader->config.float_mode));
si_pm4_set_reg(pm4, R_00B02C_SPI_SHADER_PGM_RSRC2_PS,
   S_00B02C_EXTRA_LDS_SIZE(shader->config.lds_size) |
   S_00B02C_USER_SGPR(SI_PS_NUM_USER_SGPR) |
   S_00B32C_SCRATCH_EN(shader->config.scratch_bytes_per_wave 
> 0));
-
-   /* DON'T USE EARLY_Z_THEN_RE_Z !!!
-*
-* It decreases performance by 15% in DiRT: Showdown on Ultra settings.
-* And it has pretty complex shaders.
-*
-* Shaders with side effects that must execute independently of the
-* depth test require LATE_Z.
-*/
-   if (info->writes_memory &&
-   !info->properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL])
-   shader->z_order = V_02880C_LATE_Z;
-   else
-   shader->z_order = V_02880C_EARLY_Z_THEN_LATE_Z;
 }

 static void si_shader_init_pm4_state(struct si_screen *sscreen,
  struct si_shader *shader)
 {
switch (shader->selector->type) {
case PIPE_SHADER_VERTEX:
if (shader->key.vs.as_ls)
si_shader_ls(shader);
else if (shader->key.vs.as_es)
@@ -1364,26 +1350,52 @@ static void *si_create_shader_selector(struct 
pipe_context *ctx,
case TGSI_FS_DEPTH_LAYOUT_GREATER:
sel->db_shader_control |=

S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_GREATER_THAN_Z);
break;
case TGSI_FS_DEPTH_LAYOUT_LESS:
sel->db_shader_control |=

S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_LESS_THAN_Z);
break;
}

-   if (sel->info.properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL])
-   sel->db_shader_control |= S_02880C_DEPTH_BEFORE_SHADER(1);
+   /* Z_ORDER, EXEC_ON_HIER_FAIL and EXEC_ON_NOOP should be set as 
following:
+*
+*   | early Z/S | writes_mem | allow_ReZ? |  Z_ORDER   | 
EXEC_ON_HIER_FAIL | EXEC_ON_NOOP
+* 
--|---||||---|-
+* 1a|   false   |   false|   true | EarlyZ_Then_ReZ|   
  0 | 0
+* 1b|   false   |   false|   false| EarlyZ_Then_LateZ  |   
  0 | 0
+* 2 |   false   |   true |   n/a  |   LateZ|   
  1 | 0
+* 3 |   true|   false|   n/a  | EarlyZ_Then_LateZ  |   
  0 | 0
+* 4 |   true|   true |   n/a  | EarlyZ_Then_LateZ  |   
  0 | 1
+*
+* In cases 3 and 4, HW will force Z_ORDER to EarlyZ regardless of 
what's set in the register.
+* In case 2, NOOP_CULL is a don't care field. In case 2, 3 and 

Re: [Mesa-dev] Required-for-rendering internal formats

[Erik Faye-Lund]

On Thu, Oct 13, 2016 at 5:35 PM, Nicolai Hähnle  wrote:
> On 13.10.2016 17:15, Ilia Mirkin wrote:
>>
>> Anyone else have opinions on this? Should st/mesa be adding
>> PIPE_BIND_RENDER_TARGET for all textures of the internal formats
>> listed in table 8.12? (Which would, in this case, force RGBA8 to be
>> used since RGBA4 is non-renderable.) Or is it perfectly legal for a
>> format to be not renderable when used as a texture vs renderbuffer?

I have some old patches laying around that I've been intending to
upstream for a while in this area:

https://github.com/kusma/mesa/commits/color_renderable_fix

IIRC, some work has landed since that made some of the patches
obsolete, so take things with a grain of salt ;)

>
> I think the spec is pretty clear that the "req.rend." column of that table
> is only for renderbuffers.
>
> It's a lot less clear about what really matters for this question. In
> section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:
>
> Each color attachment may be in any of the color-renderable
> formats described in section 9.4 (although implementations
> are not required to support creation of attachments in all
> color-renderable formats).
>
> Color-renderable formats are those which have a checkmark in the CR column
> according to section 9.4. That means pretty much _all_ non-compressed
> formats (except for the shared exponents one). I doubt that the intention is
> to force stuff like R3_G3_B2 to be renderable.
>
> It's kind of funny that the sentence says that the attachments may be in any
> of these formats, but you may not be able to create the attachments?

You can create any attachments as long as you can create the texture
or renderbuffer for them. And all formats are marked as either req.ren
or req.tex. So any format might be attached. But that doesn't mean it
can be *rendered* to.

> I think what that's trying to say is that the implementation MUST reject
> color attachments that are not CR according to table 8.12, and it MAY reject
> color attachments of any format it likes.
>

In essence, yes. But the details are of course a bit more complicated.

Everything marked as CR is "color renderable" according to OpenGL.
However, being "color renderable" isn't *enough* to guarantee that it
can be rendered to, because of framebuffer completeness:

Section 9.4.2 ("Whole Framebuffer Completeness") of the OpenGL 4.5
core spec says:

"Although the GL defines a wide variety of internal formats for
framebufferattachable images, such as texture images and renderbuffer
images, some implementations may not support rendering to particular
combinations of internal formats. If the combination of formats of the
images attached to a framebuffer object are not supported by the
implementation, then the framebuffer is not complete under the clause
labeled FRAMEBUFFER_UNSUPPORTED."

So, using a non-CR format produces
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT, and using a non-supported CR
format produces FRAMEBUFFER_UNSUPPORTED.

> So I tend to side with the interpretation that exposing RGBA4 as texture
> format but not allowing to render to it is okay by the spec, and the
> application has a bug.

This is my interpretation as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] EGL_MESA_platform_surfaceless

[Chad Versace]

On Fri 23 Sep 2016, Chad Versace wrote:

> diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
> b/docs/specs/EGL_MESA_platform_surfaceless.txt
> new file mode 100644
> index 000..b700370
> --- /dev/null
> +++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
> @@ -0,0 +1,108 @@

> +Name Strings
> +
> +EGL_MESA_platform_surfaceless

> +New Tokens
> +
> +Accepted as the  argument of eglGetPlatformDisplay:
> +
> +EGL_PLATFORM_SURFACELESS_MESA   0xTODO

I plan to reserve 0x3DD from the EGL registry for this enum. Speak up if
this causes any problem.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

[Andy Furniss]

Mark Thompson wrote:

On 13/10/16 08:20, Christian König wrote:

Am 13.10.2016 um 00:52 schrieb Mark Thompson:

The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.


Reviewed-by: Christian König  for the whole series.

Do you have commit access?


I do not.  Please do push this for me once all appropriate people are happy 
with it.


Seems not to regress anything, but there are still differences vs gstreamer.

I guess the poc fix now allows JM decoder not to bail, but that allows
me to see some other issue around I frames. I haven't had time too look
properly why, but guessing it could be that avconv sends 
desc.h264enc.gop_size

every I frame, but gst just once.

I don't know if you'll even see this on bonaire as my tonga possibly
hits different code - I mean in src/gallium/drivers/radeon/ there is
radeon_vce_40_2_2.c
radeon_vce_50.c
radeon_vce_52.c
and maybe these are used depending on vce firmware version and do
different things for different h/w.

The issue I see with JM is shown below - the file seems to play OK.
There may be another (I guess pre-existing) issue around 1080/1088
affecting transcoding with both avconv and gst, but one thing at a
time.

This is with -g 30 and doesn't happen with gstreamer.

--
  Frame  POC  Pic#   QPSnrY SnrU SnrV   Y:U:V Time(ms)
--
0(IDR)0 033 4:2:0  90
0( P )1 129 4:2:0  57
1( P )2 229 4:2:0  55
1( P )3 328 4:2:0  57
2( P )4 428 4:2:0  59
2( P )5 528 4:2:0  57

snip

00014( P )   292923 4:2:0  70
00015( P )   303024 4:2:0  66
0(IDR)   -1 023 4:2:0 129
0( P )0 124 4:2:0  59
0( P )1 225 4:2:0  56
1( P )2 325 4:2:0  58
1( P )3 425 4:2:0  57

snip
00014( P )   282926 4:2:0  59
00014( P )   293024 4:2:0  65
-0001(IDR)   -2 024 4:2:0 129
0( P )   -1 125 4:2:0  59
0( P )0 225 4:2:0  58
0( P )1 325 4:2:0  59

snip
00013( P )   272924 4:2:0  65
00014( P )   283024 4:2:0  67
-0001(IDR)   -3 024 4:2:0 130
-0001( P )   -2 125 4:2:0  59
0( P )   -1 225 4:2:0  58
0( P )0 325 4:2:0  58
0( P )1 425 4:2:0  57




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

Re: [Mesa-dev] [RFC] EGL_MESA_platform_surfaceless

[Chad Versace]

On Thu 13 Oct 2016, Chad Versace wrote:
> On Fri 23 Sep 2016, Chad Versace wrote:
> 
> > diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
> > b/docs/specs/EGL_MESA_platform_surfaceless.txt
> > new file mode 100644
> > index 000..b700370
> > --- /dev/null
> > +++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
> > @@ -0,0 +1,108 @@
> 
> > +Name Strings
> > +
> > +EGL_MESA_platform_surfaceless
> 
> > +New Tokens
> > +
> > +Accepted as the  argument of eglGetPlatformDisplay:
> > +
> > +EGL_PLATFORM_SURFACELESS_MESA   0xTODO
> 
> I plan to reserve 0x3DD from the EGL registry for this enum. Speak up if
> this causes any problem.

Typo. I meant 0x31DD.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: clear DB_RENDER_OVERRIDE

[Marek Olšák]

From: Marek Olšák 

Vulkan doesn't set these fields even though it doesn't use HiS.
HiS is disabled by programming DB_SRESULTS_COMPARE_STATEn to 0.
---
 src/gallium/drivers/radeonsi/si_state.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index b23749c..732f9e9 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3918,23 +3918,21 @@ static void si_init_config(struct si_context *sctx)
   S_028230_ER_LINE_LR(0x1A) |
   S_028230_ER_LINE_RL(0x26) |
   S_028230_ER_LINE_TB(0xA) |
   S_028230_ER_LINE_BT(0xA));
/* PA_SU_HARDWARE_SCREEN_OFFSET must be 0 due to hw bug on SI */
si_pm4_set_reg(pm4, R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0);
si_pm4_set_reg(pm4, R_028820_PA_CL_NANINF_CNTL, 0);
si_pm4_set_reg(pm4, R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0x0);
si_pm4_set_reg(pm4, R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0x0);
si_pm4_set_reg(pm4, R_028AC8_DB_PRELOAD_CONTROL, 0x0);
-   si_pm4_set_reg(pm4, R_02800C_DB_RENDER_OVERRIDE,
-  S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
-  S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE));
+   si_pm4_set_reg(pm4, R_02800C_DB_RENDER_OVERRIDE, 0);
 
si_pm4_set_reg(pm4, R_028400_VGT_MAX_VTX_INDX, ~0);
si_pm4_set_reg(pm4, R_028404_VGT_MIN_VTX_INDX, 0);
si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);
 
if (sctx->b.chip_class >= CIK) {
si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS, 
S_00B21C_CU_EN(0x));
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: unify the constant load paths

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 13, 2016 at 3:44 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Remove the split between direct and indirect.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 39 
> +---
>  1 file changed, 11 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 15432b2..34c6eb1 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1867,66 +1867,49 @@ static LLVMValueRef fetch_constant(
> LLVMValueRef values[4];
> for (chan = 0; chan < TGSI_NUM_CHANNELS; ++chan)
> values[chan] = fetch_constant(bld_base, reg, type, 
> chan);
>
> return lp_build_gather_values(bld_base->base.gallivm, values, 
> 4);
> }
>
> buf = reg->Register.Dimension ? reg->Dimension.Index : 0;
> idx = reg->Register.Index * 4 + swizzle;
>
> -   if (!reg->Register.Indirect && !reg->Dimension.Indirect) {
> -   LLVMValueRef c0, c1, desc;
> -
> -   desc = load_const_buffer_desc(ctx, buf);
> -   c0 = buffer_load_const(ctx, desc,
> -  LLVMConstInt(ctx->i32, idx * 4, 0));
> -
> -   if (!tgsi_type_is_64bit(type))
> -   return bitcast(bld_base, type, c0);
> -   else {
> -   c1 = buffer_load_const(ctx, desc,
> -  LLVMConstInt(ctx->i32,
> -   (idx + 1) * 4, 
> 0));
> -   return radeon_llvm_emit_fetch_64bit(bld_base, type,
> -   c0, c1);
> -   }
> -   }
> -
> if (reg->Register.Dimension && reg->Dimension.Indirect) {
> LLVMValueRef ptr = LLVMGetParam(ctx->radeon_bld.main_fn, 
> SI_PARAM_CONST_BUFFERS);
> LLVMValueRef index;
> index = get_bounded_indirect_index(ctx, ®->DimIndirect,
>reg->Dimension.Index,
>SI_NUM_CONST_BUFFERS);
> bufp = build_indexed_load_const(ctx, ptr, index);
> } else
> bufp = load_const_buffer_desc(ctx, buf);
>
> -   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> -   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr reg");
> -   addr = lp_build_mul_imm(&bld_base->uint_bld, addr, 16);
> -   addr = lp_build_add(&bld_base->uint_bld, addr,
> -   lp_build_const_int32(base->gallivm, idx * 4));
> +   if (reg->Register.Indirect) {
> +   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> +   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr 
> reg");
> +   addr = lp_build_mul_imm(&bld_base->uint_bld, addr, 16);
> +   addr = lp_build_add(&bld_base->uint_bld, addr,
> +   lp_build_const_int32(base->gallivm, idx * 
> 4));
> +   } else {
> +   addr = LLVMConstInt(ctx->i32, idx * 4, 0);
> +   }
>
> result = buffer_load_const(ctx, bufp, addr);
>
> if (!tgsi_type_is_64bit(type))
> result = bitcast(bld_base, type, result);
> else {
> LLVMValueRef addr2, result2;
> -   addr2 = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> -   addr2 = LLVMBuildLoad(base->gallivm->builder, addr2, "load 
> addr reg2");
> -   addr2 = lp_build_mul_imm(&bld_base->uint_bld, addr2, 16);
> -   addr2 = lp_build_add(&bld_base->uint_bld, addr2,
> -lp_build_const_int32(base->gallivm, (idx 
> + 1) * 4));
>
> +   addr2 = lp_build_add(&bld_base->uint_bld, addr,
> +LLVMConstInt(ctx->i32, 4, 0));
> result2 = buffer_load_const(ctx, bufp, addr2);
>
> result = radeon_llvm_emit_fetch_64bit(bld_base, type,
>   result, result2);
> }
> return result;
>  }
>
>  /* Upper 16 bits must be zero. */
>  static LLVMValueRef si_llvm_pack_two_int16(struct gallivm_state *gallivm,
> --
> 2.7.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

[Mesa-dev] [PATCH] radeonsi: shorten "shader->selector" to "sel" in si_shader_create

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index b2d7699..e6edd90 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -7850,35 +7850,36 @@ static void si_fix_num_sgprs(struct si_shader *shader)
 {
unsigned min_sgprs = shader->info.num_input_sgprs + 2; /* VCC */
 
shader->config.num_sgprs = MAX2(shader->config.num_sgprs, min_sgprs);
 }
 
 int si_shader_create(struct si_screen *sscreen, LLVMTargetMachineRef tm,
 struct si_shader *shader,
 struct pipe_debug_callback *debug)
 {
-   struct si_shader *mainp = shader->selector->main_shader_part;
+   struct si_shader_selector *sel = shader->selector;
+   struct si_shader *mainp = sel->main_shader_part;
int r;
 
/* LS, ES, VS are compiled on demand if the main part hasn't been
 * compiled for that stage.
 */
if (!mainp ||
-   (shader->selector->type == PIPE_SHADER_VERTEX &&
+   (sel->type == PIPE_SHADER_VERTEX &&
 (shader->key.vs.as_es != mainp->key.vs.as_es ||
  shader->key.vs.as_ls != mainp->key.vs.as_ls)) ||
-   (shader->selector->type == PIPE_SHADER_TESS_EVAL &&
+   (sel->type == PIPE_SHADER_TESS_EVAL &&
 shader->key.tes.as_es != mainp->key.tes.as_es) ||
-   (shader->selector->type == PIPE_SHADER_TESS_CTRL &&
+   (sel->type == PIPE_SHADER_TESS_CTRL &&
 shader->key.tcs.epilog.inputs_to_copy) ||
-   shader->selector->type == PIPE_SHADER_COMPUTE) {
+   sel->type == PIPE_SHADER_COMPUTE) {
/* Monolithic shader (compiled as a whole, has many variants,
 * may take a long time to compile).
 */
r = si_compile_tgsi_shader(sscreen, tm, shader, true, debug);
if (r)
return r;
} else {
/* The shader consists of 2-3 parts:
 *
 * - the middle part is the user shader, it has 1 variant only
@@ -7898,21 +7899,21 @@ int si_shader_create(struct si_screen *sscreen, 
LLVMTargetMachineRef tm,
shader->info.num_input_vgprs = mainp->info.num_input_vgprs;
shader->info.face_vgpr_index = mainp->info.face_vgpr_index;
memcpy(shader->info.vs_output_param_offset,
   mainp->info.vs_output_param_offset,
   sizeof(mainp->info.vs_output_param_offset));
shader->info.uses_instanceid = mainp->info.uses_instanceid;
shader->info.nr_pos_exports = mainp->info.nr_pos_exports;
shader->info.nr_param_exports = mainp->info.nr_param_exports;
 
/* Select prologs and/or epilogs. */
-   switch (shader->selector->type) {
+   switch (sel->type) {
case PIPE_SHADER_VERTEX:
if (!si_shader_select_vs_parts(sscreen, tm, shader, 
debug))
return -1;
break;
case PIPE_SHADER_TESS_CTRL:
if (!si_shader_select_tcs_parts(sscreen, tm, shader, 
debug))
return -1;
break;
case PIPE_SHADER_TESS_EVAL:
if (!si_shader_select_tes_parts(sscreen, tm, shader, 
debug))
@@ -7939,21 +7940,21 @@ int si_shader_create(struct si_screen *sscreen, 
LLVMTargetMachineRef tm,
}
if (shader->epilog) {
shader->config.num_sgprs = 
MAX2(shader->config.num_sgprs,

shader->epilog->config.num_sgprs);
shader->config.num_vgprs = 
MAX2(shader->config.num_vgprs,

shader->epilog->config.num_vgprs);
}
}
 
si_fix_num_sgprs(shader);
-   si_shader_dump(sscreen, shader, debug, shader->selector->info.processor,
+   si_shader_dump(sscreen, shader, debug, sel->info.processor,
   stderr);
 
/* Upload. */
r = si_shader_binary_upload(sscreen, shader);
if (r) {
fprintf(stderr, "LLVM failed to upload shader\n");
return r;
}
 
return 0;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

[Kai Wasserbäch]

Dear Tom,
just FYI: this fails to apply on top of master
(761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
visit_image_store() hunk for me. Attached is a "refreshed" version, which
applies for me. I hope I didn't butcher anything inadvertently.

Cheers,
Kai


Tom Stellard wrote on 13.10.2016 17:21:
> These were changed in LLVM r284024.
> ---
>  src/amd/common/ac_nir_to_llvm.c | 131 
> 
>  1 file changed, 107 insertions(+), 24 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 9c764c7..4fba7d3 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
> nir_to_llvm_context *ctx,
>   return res;
>  }
>  
> +static void build_type_name_for_intr(
> +LLVMTypeRef type,
> +char *buf, unsigned bufsize)
> +{
> +LLVMTypeRef elem_type = type;
> +
> +assert(bufsize >= 8);
> +
> +if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
> +int ret = snprintf(buf, bufsize, "v%u",
> +LLVMGetVectorSize(type));
> +if (ret < 0) {
> +char *type_name = LLVMPrintTypeToString(type);
> +fprintf(stderr, "Error building type name for: %s\n",
> +type_name);
> +return;
> +}
> +elem_type = LLVMGetElementType(type);
> +buf += ret;
> +bufsize -= ret;
> +}
> +switch (LLVMGetTypeKind(elem_type)) {
> +default: break;
> +case LLVMIntegerTypeKind:
> +snprintf(buf, bufsize, "i%d", 
> LLVMGetIntTypeWidth(elem_type));
> +break;
> +case LLVMFloatTypeKind:
> +snprintf(buf, bufsize, "f32");
> +break;
> +case LLVMDoubleTypeKind:
> +snprintf(buf, bufsize, "f64");
> +break;
> +}
> +}
> +
> +static void get_image_intr_name(const char *base_name,
> +LLVMTypeRef data_type,
> +LLVMTypeRef coords_type,
> +LLVMTypeRef rsrc_type,
> +char *out_name, unsigned out_len)
> +{
> +char coords_type_name[8];
> +
> +build_type_name_for_intr(coords_type, coords_type_name,
> +sizeof(coords_type_name));
> +
> +if (HAVE_LLVM <= 0x0309) {
> +snprintf(out_name, out_len, "%s.%s", base_name, 
> coords_type_name);
> +} else {
> +char data_type_name[8];
> +char rsrc_type_name[8];
> +
> +build_type_name_for_intr(data_type, data_type_name,
> +sizeof(data_type_name));
> +build_type_name_for_intr(rsrc_type, rsrc_type_name,
> +sizeof(rsrc_type_name));
> +snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
> + data_type_name, coords_type_name, rsrc_type_name);
> +}
> +}
> +
>  static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
>nir_intrinsic_instr *instr)
>  {
>   LLVMValueRef params[7];
>   LLVMValueRef res;
> - char intrinsic_name[32];
> - char coords_type[8];
> + char intrinsic_name[64];
>   const nir_variable *var = instr->variables[0]->var;
>   const struct glsl_type *type = var->type;
>   if(instr->variables[0]->deref.child)
> @@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
> nir_to_llvm_context *ctx,
>   res = trim_vector(ctx, res, instr->dest.ssa.num_components);
>   res = to_integer(ctx, res);
>   } else {
> - bool da = glsl_sampler_type_is_array(type) ||
> -   glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> + bool is_da = glsl_sampler_type_is_array(type) ||
> +  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_CUBE;
>   bool add_frag_pos = glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_SUBPASS;
> + LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
> + LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
> + LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
>  
>   params[0] = get_image_coords(ctx, instr, add_frag_pos);
>   params[1] = get_sampler_desc(ctx, instr->variables[0], 
> DESC_IMAGE);
>   params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
> - params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
> - params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
> - params[5] = LLVMConstInt(ctx->i1, 0, false);  /* 

[Mesa-dev] [PATCH 1/2] radv: Fix incorrect comment

[Tom Stellard]

---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e6ff7c8..9c764c7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2373,8 +2373,8 @@ static void visit_image_store(struct nir_to_llvm_context 
*ctx,
bool da = glsl_sampler_type_is_array(type) ||
  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
 
-   params[0] = get_src(ctx, instr->src[2]); /* coords */
-   params[1] = get_image_coords(ctx, instr, false);
+   params[0] = get_src(ctx, instr->src[2]);
+   params[1] = get_image_coords(ctx, instr, false); /* coords */
params[2] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[3] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
params[4] = i1false;  /* r128 */
-- 
2.7.4

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

[Mesa-dev] [PATCH] gallium/hud: Sensor extension is segfaulting.

[Steven Toth]

Round two of the patchset, incorporating feedback
from nhaeh...@gmail.com

The fixes in this set address bugfix #68169, HUD crashing
when testing with unigine (heaven).

The bug also manifested itself as a lack of data in
HUD charts when multiple instanced were created and
destroyed in a specific order, a use case not witnessed
with glxgears.

These patches:
1. mutex protect the internal object lists.
2. reference count object access for destruction purposes.

Patchset tested with glxgears/demo and unigine.

Signed-off-by: Steven Toth 
---
 src/gallium/auxiliary/hud/hud_cpufreq.c  | 33 ++
 src/gallium/auxiliary/hud/hud_diskstat.c | 39 ++
 src/gallium/auxiliary/hud/hud_nic.c  | 37 +
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 41 ++--
 4 files changed, 125 insertions(+), 25 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
index 4501bbb..e193568 100644
--- a/src/gallium/auxiliary/hud/hud_cpufreq.c
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -37,6 +37,8 @@
 #include "util/list.h"
 #include "os/os_time.h"
 #include "util/u_memory.h"
+#include "util/u_inlines.h"
+#include "os/os_thread.h"
 #include 
 #include 
 #include 
@@ -57,21 +59,28 @@ struct cpufreq_info
char sysfs_filename[128];
uint64_t KHz;
uint64_t last_time;
+   struct pipe_reference refcnt;
 };
 
 static int gcpufreq_count = 0;
 static struct list_head gcpufreq_list;
+static pipe_mutex gcpufreq_mutex;
 
 static struct cpufreq_info *
 find_cfi_by_index(int cpu_index, int mode)
 {
+   struct cpufreq_info *ret = 0;
+   pipe_mutex_lock(gcpufreq_mutex);
list_for_each_entry(struct cpufreq_info, cfi, &gcpufreq_list, list) {
   if (cfi->mode != mode)
  continue;
-  if (cfi->cpu_index == cpu_index)
- return cfi;
+  if (cfi->cpu_index == cpu_index) {
+ ret = cfi;
+ break;
+  }
}
-   return 0;
+   pipe_mutex_unlock(gcpufreq_mutex);
+   return ret;
 }
 
 static int
@@ -116,8 +125,14 @@ static void
 free_query_data(void *p)
 {
struct cpufreq_info *cfi = (struct cpufreq_info *)p;
-   list_del(&cfi->list);
-   FREE(cfi);
+   /* atomic dec */
+   if (pipe_reference(&cfi->refcnt, NULL)) {
+  pipe_mutex_lock(gcpufreq_mutex);
+  list_del(&cfi->list);
+  gcpufreq_count--;
+  pipe_mutex_unlock(gcpufreq_mutex);
+  FREE(cfi);
+   }
 }
 
 /**
@@ -159,6 +174,7 @@ hud_cpufreq_graph_install(struct hud_pane *pane, int 
cpu_index,
   return;
}
 
+   pipe_reference(NULL, &cfi->refcnt); /* atomic inc */
gr->query_data = cfi;
gr->query_new_value = query_cfi_load;
 
@@ -180,8 +196,12 @@ add_object(const char *name, const char *fn, int objmode, 
int cpu_index)
strcpy(cfi->sysfs_filename, fn);
cfi->mode = objmode;
cfi->cpu_index = cpu_index;
+   pipe_reference_init(&cfi->refcnt, 1);
+
+   pipe_mutex_lock(gcpufreq_mutex);
list_addtail(&cfi->list, &gcpufreq_list);
gcpufreq_count++;
+   pipe_mutex_unlock(gcpufreq_mutex);
 }
 
 /**
@@ -205,6 +225,7 @@ hud_get_num_cpufreq(bool displayhelp)
/* Scan /sys/devices.../cpu, for every object type we support, create
 * and persist an object to represent its different metrics.
 */
+   pipe_mutex_init(gcpufreq_mutex);
list_inithead(&gcpufreq_list);
DIR *dir = opendir("/sys/devices/system/cpu");
if (!dir)
@@ -240,6 +261,7 @@ hud_get_num_cpufreq(bool displayhelp)
}
 
if (displayhelp) {
+  pipe_mutex_lock(gcpufreq_mutex);
   list_for_each_entry(struct cpufreq_info, cfi, &gcpufreq_list, list) {
  char line[128];
  snprintf(line, sizeof(line), "cpufreq-%s-%s",
@@ -249,6 +271,7 @@ hud_get_num_cpufreq(bool displayhelp)
 
  puts(line);
   }
+  pipe_mutex_unlock(gcpufreq_mutex);
}
 
return gcpufreq_count;
diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
b/src/gallium/auxiliary/hud/hud_diskstat.c
index b248baf..e1748c5 100644
--- a/src/gallium/auxiliary/hud/hud_diskstat.c
+++ b/src/gallium/auxiliary/hud/hud_diskstat.c
@@ -35,7 +35,9 @@
 #include "hud/hud_private.h"
 #include "util/list.h"
 #include "os/os_time.h"
+#include "os/os_thread.h"
 #include "util/u_memory.h"
+#include "util/u_inlines.h"
 #include 
 #include 
 #include 
@@ -73,6 +75,7 @@ struct diskstat_info
char sysfs_filename[128];
uint64_t last_time;
struct stat_s last_stat;
+   struct pipe_reference refcnt;
 };
 
 /* TODO: We don't handle dynamic block device / partition
@@ -81,17 +84,23 @@ struct diskstat_info
  */
 static int gdiskstat_count = 0;
 static struct list_head gdiskstat_list;
+static pipe_mutex gdiskstat_mutex;
 
 static struct diskstat_info *
 find_dsi_by_name(const char *n, int mode)
 {
+   struct diskstat_info *ret = 0;
+   pipe_mutex_lock(gdiskstat_mutex);
list_for_each_entry(struct diskstat_info, dsi, &gdiskstat_list, list) {
   if (dsi->mode != mode)
  continue;

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

[Tom Stellard]

On Thu, Oct 13, 2016 at 07:20:30PM +0200, Kai Wasserbäch wrote:
> Dear Tom,
> just FYI: this fails to apply on top of master
> (761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
> visit_image_store() hunk for me. Attached is a "refreshed" version, which
> applies for me. I hope I didn't butcher anything inadvertently.
> 

Hi,

I just sent rebased patches.  Can you try those.

-Tom

> Cheers,
> Kai
> 
> 
> Tom Stellard wrote on 13.10.2016 17:21:
> > These were changed in LLVM r284024.
> > ---
> >  src/amd/common/ac_nir_to_llvm.c | 131 
> > 
> >  1 file changed, 107 insertions(+), 24 deletions(-)
> > 
> > diff --git a/src/amd/common/ac_nir_to_llvm.c 
> > b/src/amd/common/ac_nir_to_llvm.c
> > index 9c764c7..4fba7d3 100644
> > --- a/src/amd/common/ac_nir_to_llvm.c
> > +++ b/src/amd/common/ac_nir_to_llvm.c
> > @@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
> > nir_to_llvm_context *ctx,
> > return res;
> >  }
> >  
> > +static void build_type_name_for_intr(
> > +LLVMTypeRef type,
> > +char *buf, unsigned bufsize)
> > +{
> > +LLVMTypeRef elem_type = type;
> > +
> > +assert(bufsize >= 8);
> > +
> > +if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
> > +int ret = snprintf(buf, bufsize, "v%u",
> > +LLVMGetVectorSize(type));
> > +if (ret < 0) {
> > +char *type_name = LLVMPrintTypeToString(type);
> > +fprintf(stderr, "Error building type name for: 
> > %s\n",
> > +type_name);
> > +return;
> > +}
> > +elem_type = LLVMGetElementType(type);
> > +buf += ret;
> > +bufsize -= ret;
> > +}
> > +switch (LLVMGetTypeKind(elem_type)) {
> > +default: break;
> > +case LLVMIntegerTypeKind:
> > +snprintf(buf, bufsize, "i%d", 
> > LLVMGetIntTypeWidth(elem_type));
> > +break;
> > +case LLVMFloatTypeKind:
> > +snprintf(buf, bufsize, "f32");
> > +break;
> > +case LLVMDoubleTypeKind:
> > +snprintf(buf, bufsize, "f64");
> > +break;
> > +}
> > +}
> > +
> > +static void get_image_intr_name(const char *base_name,
> > +LLVMTypeRef data_type,
> > +LLVMTypeRef coords_type,
> > +LLVMTypeRef rsrc_type,
> > +char *out_name, unsigned out_len)
> > +{
> > +char coords_type_name[8];
> > +
> > +build_type_name_for_intr(coords_type, coords_type_name,
> > +sizeof(coords_type_name));
> > +
> > +if (HAVE_LLVM <= 0x0309) {
> > +snprintf(out_name, out_len, "%s.%s", base_name, 
> > coords_type_name);
> > +} else {
> > +char data_type_name[8];
> > +char rsrc_type_name[8];
> > +
> > +build_type_name_for_intr(data_type, data_type_name,
> > +sizeof(data_type_name));
> > +build_type_name_for_intr(rsrc_type, rsrc_type_name,
> > +sizeof(rsrc_type_name));
> > +snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
> > + data_type_name, coords_type_name, rsrc_type_name);
> > +}
> > +}
> > +
> >  static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
> >  nir_intrinsic_instr *instr)
> >  {
> > LLVMValueRef params[7];
> > LLVMValueRef res;
> > -   char intrinsic_name[32];
> > -   char coords_type[8];
> > +   char intrinsic_name[64];
> > const nir_variable *var = instr->variables[0]->var;
> > const struct glsl_type *type = var->type;
> > if(instr->variables[0]->deref.child)
> > @@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
> > nir_to_llvm_context *ctx,
> > res = trim_vector(ctx, res, instr->dest.ssa.num_components);
> > res = to_integer(ctx, res);
> > } else {
> > -   bool da = glsl_sampler_type_is_array(type) ||
> > - glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> > +   bool is_da = glsl_sampler_type_is_array(type) ||
> > +glsl_get_sampler_dim(type) == 
> > GLSL_SAMPLER_DIM_CUBE;
> > bool add_frag_pos = glsl_get_sampler_dim(type) == 
> > GLSL_SAMPLER_DIM_SUBPASS;
> > +   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
> > +   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
> > +   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
> >  
> > params[0] = get_image_coords(ctx, instr, add_frag_pos);
> > params[1] = get_sampler_desc

[Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures v2

[Tom Stellard]

These were changed in LLVM r284024.

v2:
  - Only use float types for vdata of llvm.amdgcn.image.store.  LLVM doesn't
support integer types for this intrinsic.
---
 src/amd/common/ac_nir_to_llvm.c | 133 
 1 file changed, 108 insertions(+), 25 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 9c764c7..56814ec 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
nir_to_llvm_context *ctx,
return res;
 }
 
+static void build_type_name_for_intr(
+LLVMTypeRef type,
+char *buf, unsigned bufsize)
+{
+LLVMTypeRef elem_type = type;
+
+assert(bufsize >= 8);
+
+if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
+int ret = snprintf(buf, bufsize, "v%u",
+LLVMGetVectorSize(type));
+if (ret < 0) {
+char *type_name = LLVMPrintTypeToString(type);
+fprintf(stderr, "Error building type name for: %s\n",
+type_name);
+return;
+}
+elem_type = LLVMGetElementType(type);
+buf += ret;
+bufsize -= ret;
+}
+switch (LLVMGetTypeKind(elem_type)) {
+default: break;
+case LLVMIntegerTypeKind:
+snprintf(buf, bufsize, "i%d", LLVMGetIntTypeWidth(elem_type));
+break;
+case LLVMFloatTypeKind:
+snprintf(buf, bufsize, "f32");
+break;
+case LLVMDoubleTypeKind:
+snprintf(buf, bufsize, "f64");
+break;
+}
+}
+
+static void get_image_intr_name(const char *base_name,
+LLVMTypeRef data_type,
+LLVMTypeRef coords_type,
+LLVMTypeRef rsrc_type,
+char *out_name, unsigned out_len)
+{
+char coords_type_name[8];
+
+build_type_name_for_intr(coords_type, coords_type_name,
+sizeof(coords_type_name));
+
+if (HAVE_LLVM <= 0x0309) {
+snprintf(out_name, out_len, "%s.%s", base_name, 
coords_type_name);
+} else {
+char data_type_name[8];
+char rsrc_type_name[8];
+
+build_type_name_for_intr(data_type, data_type_name,
+sizeof(data_type_name));
+build_type_name_for_intr(rsrc_type, rsrc_type_name,
+sizeof(rsrc_type_name));
+snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
+ data_type_name, coords_type_name, rsrc_type_name);
+}
+}
+
 static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
 nir_intrinsic_instr *instr)
 {
LLVMValueRef params[7];
LLVMValueRef res;
-   char intrinsic_name[32];
-   char coords_type[8];
+   char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = var->type;
if(instr->variables[0]->deref.child)
@@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
nir_to_llvm_context *ctx,
res = trim_vector(ctx, res, instr->dest.ssa.num_components);
res = to_integer(ctx, res);
} else {
-   bool da = glsl_sampler_type_is_array(type) ||
- glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
+   bool is_da = glsl_sampler_type_is_array(type) ||
+glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
bool add_frag_pos = glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS;
+   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
+   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
+   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
 
params[0] = get_image_coords(ctx, instr, add_frag_pos);
params[1] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
-   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
-   params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
-   params[5] = LLVMConstInt(ctx->i1, 0, false);  /* glc */
-   params[6] = LLVMConstInt(ctx->i1, 0, false);  /* slc */
+   if (HAVE_LLVM <= 0x0309) {
+   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
+   params[4] = da;
+   params[5] = glc;
+   params[6] = slc;
+   } else {
+

Re: [Mesa-dev] [PATCH] clover: Allow OpenCL version override

[Vedran Miletić]

On 10/07/2016 12:05 PM, Serge Martin wrote:
> On Thursday 06 October 2016 16:26:21 Vedran Miletić wrote:
>> CLOVER_CL_VERSION_OVERRIDE allows overriding default OpenCL version
>> supported by Clover, analogous to MESA_GL_VERSION_OVERRIDE for OpenGL.
>> CLOVER_CL_C_VERSION_OVERRIDE allows overridng default OpenCL C version.
> 
> Thanks.
> I've made some comments bellow
> 
>> ---
>>  docs/envvars.html | 12 
>>  src/gallium/state_trackers/clover/api/device.cpp  |  4 ++--
>>  src/gallium/state_trackers/clover/api/platform.cpp|  4 ++--
>>  src/gallium/state_trackers/clover/core/device.cpp | 19
>> +++ src/gallium/state_trackers/clover/core/device.hpp |
>>  4 
>>  src/gallium/state_trackers/clover/core/platform.cpp   |  9 +
>>  src/gallium/state_trackers/clover/core/platform.hpp   |  3 +++
>>  src/gallium/state_trackers/clover/core/program.cpp|  4 +++-
>>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 18
>> ++ src/gallium/state_trackers/clover/llvm/invocation.hpp | 
>> 1 +
>>  src/gallium/state_trackers/clover/llvm/util.hpp   |  4 ++--
>>  11 files changed, 71 insertions(+), 11 deletions(-)
>>
>> diff --git a/docs/envvars.html b/docs/envvars.html
>> index cf57ca5..f76827b 100644
>> --- a/docs/envvars.html
>> +++ b/docs/envvars.html
>> @@ -235,6 +235,18 @@ Setting to "tgsi", for example, will print all the TGSI
>> shaders. See src/mesa/state_tracker/st_debug.c for other options.
>>  
>>
>> +Clover state tracker environment variables
>> +
>> +
>> +CLOVER_CL_VERSION_OVERRIDE - allows overriding OpenCL version returned
>> by +clGetPlatformInfo(CL_PLATFORM_VERSION) and
>> +clGetDeviceInfo(CL_DEVICE_VERSION). Note that the setting sets the
>> version +of the platform and all the devices to the same value.
>> +CLOVER_CL_C_VERSION_OVERRIDE - allows overriding OpenCL C version
>> reported +by clGetDeviceInfo(CL_DEVICE_OPENCL_C_VERSION) and the value
>> of the +__OPENCL_VERSION__ macro in the OpenCL compiler.
> 
> I don't think we need CLOVER_CL_C_VERSION_OVERRIDE. 
> CLOVER_CL_VERSION_OVERRIDE 
> should be enough.
> 

I believe we do because with OpenCL 2.1+ the version of OpenCL C is
still 2.0.

>> +
>> +
>>  Softpipe driver environment variables
>>  
>>  SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment
>> shaders diff --git a/src/gallium/state_trackers/clover/api/device.cpp
>> b/src/gallium/state_trackers/clover/api/device.cpp index f7bd61b..e23de7a
>> 100644
>> --- a/src/gallium/state_trackers/clover/api/device.cpp
>> +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> @@ -301,7 +301,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> param, break;
>>
>> case CL_DEVICE_VERSION:
>> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
>> +  buf.as_string() = "OpenCL " + dev.opencl_version() + " Mesa "
>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>  " (" MESA_GIT_SHA1 ")"
>>  #endif
>> @@ -355,7 +355,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> param, break;
>>
>> case CL_DEVICE_OPENCL_C_VERSION:
>> -  buf.as_string() = "OpenCL C 1.1 ";
>> +  buf.as_string() = "OpenCL C " + dev.opencl_c_version() + " ";
>>break;
>>
>> case CL_DEVICE_PARENT_DEVICE:
>> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
>> b/src/gallium/state_trackers/clover/api/platform.cpp index b1b1fdf..f344ec8
>> 100644
>> --- a/src/gallium/state_trackers/clover/api/platform.cpp
>> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
>> @@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
>> cl_platform_info param, size_t size, void *r_buf, size_t *r_size) try {
>> property_buffer buf { r_buf, size, r_size };
>>
>> -   obj(d_platform);
>> +   auto &platform = obj(d_platform);
>>
>> switch (param) {
>> case CL_PLATFORM_PROFILE:
>> @@ -58,7 +58,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
>> cl_platform_info param, break;
>>
>> case CL_PLATFORM_VERSION:
>> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
>> +  buf.as_string() = "OpenCL " + platform.opencl_version() + " Mesa "
> 
> 
> you don't need to add an opencl_version() func to core/plateform,
> it won't be used except here.
> I prefer if we have an util function that would be used here, in device.cpp 
> and invocation.cpp because for the moment this is still a global value.
> 
> 
>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>  " (" MESA_GIT_SHA1 ")"
>>  #endif
>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>> b/src/gallium/state_trackers/clover/core/device.cpp index 8825f99..fce6fb3
>> 100644
>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> @@ -24,6 +24,7 @@
>>  #include "core/platform.hpp"
>>  #include "pipe/p_screen.h"
>>  #include "pipe/p_state.h"
>> +#include "util/u_debug

Re: [Mesa-dev] [PATCH] clover: Allow OpenCL version override

[Vedran Miletić]

On 10/13/2016 07:45 PM, Vedran Miletić wrote:
> On 10/07/2016 12:05 PM, Serge Martin wrote:
>> On Thursday 06 October 2016 16:26:21 Vedran Miletić wrote:
>>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>>  " (" MESA_GIT_SHA1 ")"
>>>  #endif
>>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>>> b/src/gallium/state_trackers/clover/core/device.cpp index 8825f99..fce6fb3
>>> 100644
>>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>>> @@ -24,6 +24,7 @@
>>>  #include "core/platform.hpp"
>>>  #include "pipe/p_screen.h"
>>>  #include "pipe/p_state.h"
>>> +#include "util/u_debug.h"
>>>
>>>  using namespace clover;
>>>
>>> @@ -48,6 +49,14 @@ device::device(clover::platform &platform,
>>> pipe_loader_device *ldev) : pipe->destroy(pipe);
>>>throw error(CL_INVALID_DEVICE);
>>> }
>>> +
>>> +   const std::string cl_version_override =
>>> + debug_get_option("CLOVER_CL_VERSION_OVERRIDE",
>>> ""); +   ocl_version = !cl_version_override.empty() ? cl_version_override :
>>> "1.1";
>>
>> This is what the default value of debug_get_option is for, this is 
>> redundant. 
>> You just have to pass "1.1".
>>
>> Also, if we have a util function that statistically keep the value the extra 
>> device variable and funcs are not needed.
>> We may need it if we go for CL 2.0 latter with some devices only advertising 
>> CL 1.2 because of unsupported feature, but not for the moment.
>>
> 
> Thanks for the default value comment, did not know it. Will fix it. I do
> agree with a util function that would return "1.1" until we choose to
> bump it. However I would prefer to have function per-device because we
> will eventually need to do it like that anyway.
> 

On a second thought, I believe you are right on this one. I will simplify.

Regards,
Vedran

-- 
Vedran Miletić
vedran.miletic.net
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

[Kai Wasserbäch]

Disregard this, the mbox file only contained the second patch. Sorry for the 
noise.

Kai Wasserbäch wrote on 13.10.2016 19:20:
> Dear Tom,
> just FYI: this fails to apply on top of master
> (761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
> visit_image_store() hunk for me. Attached is a "refreshed" version, which
> applies for me. I hope I didn't butcher anything inadvertently.
> 
> Cheers,
> Kai



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

[Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Emil Velikov]

On Thursday, 13 October 2016, Mike Lothian > wrote:

> If you recompile llvm and mesa each time, are there any downsides of using
> the shared libs?
>
> How many devs rebuild package X when one of its dependencies has a bug fix
release. And how many think it's a good idea ;-)
Just some food for thought.

I think there were some issues with some programs / games that had clashing
> symbols but I'm not sure if that's still an issue
>
Have not used llvm drivers extensively, ^^ plus fun interactions with
steam's c++ runtime (as mentioned by Kai a while back) are the ones that
come to mind.

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

Re: [Mesa-dev] [PATCH 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

[Emil Velikov]

On Thursday, 13 October 2016, Emil Velikov  wrote:

> On 12 October 2016 at 18:59, Axel Davy >
> wrote:
> > On 12/10/2016 19:15, Emil Velikov wrote:
> >>
> >> On 11 October 2016 at 19:54, Axel Davy >
> wrote:
> >>>
> >>> On 11/10/2016 20:31, Emil Velikov wrote:
> 
> -   udev = udev_new();
>  -   if (!udev)
>  -  goto prime_clean;
>  +   if (drmGetDevice(default_fd, &device) != 0)
>  +  goto err;
> -   default_device_id_path_tag = get_id_path_tag_from_fd(udev,
>  default_fd);
>  -   if (!default_device_id_path_tag)
>  -  goto udev_clean;
>  -
>  -   is_different_device = 1;
>    /* two format are supported:
> * "1": choose any other card than the card used by default.
> * id_path_tag: (for example "pci-_02_00_0") choose the card
> * with this id_path_tag.
> */
>    if (!strcmp(prime,"1")) {
>  -  free(prime);
>  -  prime = strdup(default_device_id_path_tag);
>  -  /* request a card with a different card than the default card
> */
>  -  another_tag = 1;
>  -   } else if (!strcmp(default_device_id_path_tag, prime))
>  -  /* we are to get a new fd (render-node) of the same device */
>  -  is_different_device = 0;
>  +  /* Hmm... detection for 2-7 seems to be broken. Nicely done. */
> >>>
> >>> For DRI2, DRI_PRIME takes a number corresponding to the device number
> as
> >>> configured in xorg (and you have xrandr commands to configure the
> >>> behaviour). This doesn't work with the DRI3 scheme. However for
> >>> retrocompatibility, after several discussions, we decided to let DRI2's
> >>> most
> >>> used command 'DRI_PRIME=1' to still sorta work on DRI3, but the meaning
> >>> changed: DRI_PRIME=1 => 'give me any device that is not the
> >>> compositor/xorg
> >>> device'
> >>
> >> No argument/objection against DRI_PRIME with DRI3, yet the current
> >> hard coded DRI_PRIME=1 _only_ check is iffy. As per the spec there can
> >> be 8 devices (0-8) with 0 always being the xorg/compositor one and 1-7
> >> as 'other' devices. Yet here we only consider 1 and ignore everything
> >> else :-\
> >
> > Do you suggest to have DRI_PRIME=2 (up to 8) be the same than
> DRI_PRIME=1 ?
> >
> Where/how did you read that ? It sounds like you've not read through
> the spec, have you ?
>
> I'm saying that the DRI2(DriverPrime) spec allows for 8 devices in
> total. The 0 one is always the xserver one and you have 7 "others".
> Atm things are completely bonkers, since you have this half a**ed
> broken heuristics which ignores anything but 1. Admittedly there
> aren't many users with 3 or more GPUs but if they were things just
> won't work :-\
>
> Furthermore atm you get a walk over the renderD* (missing D in the
> libudev pattern ;-) devices which does not relate to what you get as
> the 1 device in any other DRI_PRIME use case.
>
> Or in other words, if you use DRI_PRIME=1 with libGL/EGL/gbm you can
> get different result than when doing the same with the
> vdpau/xvmc/omx/vaapi drivers.
>
> Even within libGL (DRI2) things are quite magical , fortunately you
> get the same device if the loader fails.
>
> Or it's likely just me being weird in expect IMG different components of
mesa to behave identically when DRI_PRIME is set ;-)

Either way I'll drop the lovely comments.

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

Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

[Rafael Antognolli]

Hi all,

On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:
> 
> 
> On 2016-10-11 01:37 PM, Chad Versace wrote:
> > On Tue 11 Oct 2016, Emil Velikov wrote:
> > > On 10 October 2016 at 20:41, Rob Clark  wrote:
> > > > On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace 
> > > >  wrote:
> > 
> > > > > Testing:
> > > > > 
> > > > > I haven't yet tested EGL_ANDROID_native_fence_sync with these 
> > > > > patches, but
> > > > > the series does build. I just wanted to get these patches on the 
> > > > > list as a
> > > > > status-update.  I'm slowly working on getting Rob Clark's 
> > > > > hacked-up kmscube to
> > > > > work on this series.
> > > > > 
> > > > > I did test that this series doesn't break any dEQP-EGL sync 
> > > > > tests. But my
> > > > > dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.
> > > > > 
> > 
> > > From a quick skim neither one of CTS/dEQP/piglit had
> > > EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
> > > adding a few piglits might be a good idea. It would be good to
> > > coordinate to avoid writing the same tests twice ;-)
> > 
> > Yes, we should have tests before committing this feature. I am releasing
> > any lock I may had held on test writing, as I don't have time to tackle
> > that this week.
> 
> Writing the tests is not on my table at the moment. Perhaps some time can be
> scraped together for it at a later point, but not now.

If nobody has started writing piglit tests yet, and it's OK with you
guys, I would like to give it a try since I'm also interested in this
feature.

Also if I understood correctly, the initial thing to test is whether
WaitSync and ClientWaitSync respect input fences, right? I'll try to
come up with a list of other things to test, like invalid fences and so
on, but if you guys already have a list of things to test in mind,
please let me know.

Anyway, is it fine if I start working on this?

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

[Mesa-dev] [PATCH] radv/winsys: Fail early on overgrown cs.

[Gustaw Smolarczyk]

When !use_ib_bos, we can't easily chain ibs one to another. If the
required cs size grows over 1Mi - 8 dwords just fail the cs so that we
won't assert-fail in radv_amdgpu_winsys_cs_submit later on.
---
Please, push the patch after it has been reviewed.

 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index 41dfcd3..b8558fa 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
@@ -187,12 +187,22 @@ static void radv_amdgpu_cs_grow(struct radeon_winsys_cs 
*_cs, size_t min_size)
}
 
if (!cs->ws->use_ib_bos) {
-   uint64_t ib_size = MAX2((cs->base.cdw + min_size) * 4 + 16,
-   cs->base.max_dw * 4 * 2);
-   uint32_t *new_buf = realloc(cs->base.buf, ib_size);
+   const uint64_t limit_dws = 0x8;
+   uint64_t ib_dws = MAX2(cs->base.cdw + min_size,
+  MIN2(cs->base.max_dw * 2, limit_dws));
+
+   /* The total ib size cannot exceed limit_dws dwords. */
+   if (ib_dws > limit_dws)
+   {
+   cs->failed = true;
+   cs->base.cdw = 0;
+   return;
+   }
+
+   uint32_t *new_buf = realloc(cs->base.buf, ib_dws * 4);
if (new_buf) {
cs->base.buf = new_buf;
-   cs->base.max_dw = ib_size / 4;
+   cs->base.max_dw = ib_dws;
} else {
cs->failed = true;
cs->base.cdw = 0;
-- 
2.10.0

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

Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

[Rob Clark]

On Thu, Oct 13, 2016 at 4:37 PM, Rafael Antognolli
 wrote:
> Hi all,
>
> On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:
>>
>>
>> On 2016-10-11 01:37 PM, Chad Versace wrote:
>> > On Tue 11 Oct 2016, Emil Velikov wrote:
>> > > On 10 October 2016 at 20:41, Rob Clark  wrote:
>> > > > On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace 
>> > > >  wrote:
>> >
>> > > > > Testing:
>> > > > >
>> > > > > I haven't yet tested EGL_ANDROID_native_fence_sync with these 
>> > > > > patches, but
>> > > > > the series does build. I just wanted to get these patches on the 
>> > > > > list as a
>> > > > > status-update.  I'm slowly working on getting Rob Clark's 
>> > > > > hacked-up kmscube to
>> > > > > work on this series.
>> > > > >
>> > > > > I did test that this series doesn't break any dEQP-EGL sync 
>> > > > > tests. But my
>> > > > > dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.
>> > > > >
>> >
>> > > From a quick skim neither one of CTS/dEQP/piglit had
>> > > EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
>> > > adding a few piglits might be a good idea. It would be good to
>> > > coordinate to avoid writing the same tests twice ;-)
>> >
>> > Yes, we should have tests before committing this feature. I am releasing
>> > any lock I may had held on test writing, as I don't have time to tackle
>> > that this week.
>>
>> Writing the tests is not on my table at the moment. Perhaps some time can be
>> scraped together for it at a later point, but not now.
>
> If nobody has started writing piglit tests yet, and it's OK with you
> guys, I would like to give it a try since I'm also interested in this
> feature.

that would be hugely useful.. I'm not sure anyone else has started on
tests, but they are definitely needed

> Also if I understood correctly, the initial thing to test is whether
> WaitSync and ClientWaitSync respect input fences, right? I'll try to
> come up with a list of other things to test, like invalid fences and so
> on, but if you guys already have a list of things to test in mind,
> please let me know.

I guess API level tests, like can you create a fence w/
NO_NATIVE_FENCE_FD as input, then glFlush(), and then get an fd back
from eglDupFenceFD(), and that sort of thing?  I haven't really given
it much thought yet.

BR,
-R

> Anyway, is it fine if I start working on this?
>
> Regards,
> Rafael
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/6] egl: Don't advertise unsupported platform extensions

[Chad Versace]

Mesa's set of supported platform extensions depends on the autoconf
option --with-egl-platforms=foo,bar,baz. If --with-egl-platforms lacks
foo, then eglGetPlatformDisplay(EGL_PLATFORM_FOO, ...) unconditonally
fails.

So, if --with-egl-platforms lacks foo, then remove
EGL_VENDOR_platform_foo from the EGL client extension string.
---
 src/egl/main/eglglobals.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/egl/main/eglglobals.c b/src/egl/main/eglglobals.c
index ac1a263..8fffa55 100644
--- a/src/egl/main/eglglobals.c
+++ b/src/egl/main/eglglobals.c
@@ -53,11 +53,17 @@ struct _egl_global _eglGlobal =
/* ClientExtensionString */
"EGL_EXT_client_extensions"
" EGL_EXT_platform_base"
+#ifdef HAVE_WAYLAND_PLATFORM
" EGL_EXT_platform_wayland"
+#endif
+#ifdef HAVE_X11_PLATFORM
" EGL_EXT_platform_x11"
+#endif
+#ifdef HAVE_DRM_PLATFORM
+   " EGL_MESA_platform_gbm"
+#endif
" EGL_KHR_client_get_all_proc_addresses"
-   " EGL_KHR_debug"
-   " EGL_MESA_platform_gbm",
+   " EGL_KHR_debug",
 
NULL, /* debugCallback */
_EGL_DEBUG_BIT_CRITICAL | _EGL_DEBUG_BIT_ERROR, /* debugTypesEnabled */
-- 
2.10.0

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

[Mesa-dev] [PATCH 1/6] docs: Add EGL_MESA_platform_surfaceless.txt (v2)

[Chad Versace]

v2:
- Assign enum values.
- Define interactions with EGL_EXT_platform_base and EGL 1.4.
- Add Gurchetan as contributor, as he implemented the pbuffer support.
---
 docs/specs/EGL_MESA_platform_surfaceless.txt | 120 +++
 1 file changed, 120 insertions(+)
 create mode 100644 docs/specs/EGL_MESA_platform_surfaceless.txt

diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
b/docs/specs/EGL_MESA_platform_surfaceless.txt
new file mode 100644
index 000..871ee50
--- /dev/null
+++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
@@ -0,0 +1,120 @@
+Name
+
+MESA_platform_surfaceless
+
+Name Strings
+
+EGL_MESA_platform_surfaceless
+
+Contributors
+
+Chad Versace 
+Haixia Shi 
+Stéphane Marchesin 
+Zach Reizner 
+Gurchetan Singh 
+
+Contacts
+
+Chad Versace 
+
+Status
+
+DRAFT
+
+Version
+
+Version 2, 2016-10-13
+
+Number
+
+EGL Extension #TODO
+
+Extension Type
+
+EGL client extension
+
+Dependencies
+
+Requires EGL 1.5 or later; or EGL 1.4 with EGL_EXT_platform_base.
+
+This extension is written against the EGL 1.5 Specification (draft
+20140122).
+
+This extension interacts with EGL_EXT_platform_base as follows. If the
+implementation supports EGL_EXT_platform_base, then text regarding
+eglGetPlatformDisplay applies also to eglGetPlatformDisplayEXT;
+eglCreatePlatformWindowSurface to eglCreatePlatformWindowSurfaceEXT; and
+eglCreatePlatformPixmapSurface to eglCreatePlatformPixmapSurfaceEXT.
+
+Overview
+
+This extension defines a new EGL platform, the "surfaceless" platform. This
+platfom's defining property is that it has no native surfaces, and hence
+neither eglCreatePlatformWindowSurface nor eglCreatePlatformPixmapSurface
+can be used. The platform is independent of any native window system.
+
+The platform's intended use case is for enabling OpenGL and OpenGL ES
+applications on systems where no window system exists. However, the
+platform's permitted usage is not restricted to this case.  Since the
+platform is independent of any native window system, it may also be used on
+systems where a window system is present.
+
+New Types
+
+None
+
+New Procedures and Functions
+
+None
+
+New Tokens
+
+Accepted as the  argument of eglGetPlatformDisplay:
+
+EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+
+Additions to the EGL Specification
+
+None.
+
+New Behavior
+
+To determine if the EGL implementation supports this extension, clients
+should query the EGL_EXTENSIONS string of EGL_NO_DISPLAY.
+
+To obtain an EGLDisplay on the surfaceless platform, call
+eglGetPlatformDisplay with  set to EGL_PLATFORM_SURFACELESS_MESA.
+The  parameter must be EGL_DEFAULT_DISPLAY.
+
+eglCreatePlatformWindowSurface fails when called with a  that
+belongs to the surfaceless platform. It returns EGL_NO_SURFACE and
+generates EGL_BAD_NATIVE_WINDOW. The justification for this unconditional
+failure is that the surfaceless platform has no native windows, and
+therefore the  parameter is always invalid.
+
+Likewise, eglCreatePlatformPixmapSurface also fails when called with a
+ that belongs to the surfaceless platform.  It returns
+EGL_NO_SURFACE and generates EGL_BAD_NATIVE_PIXMAP.
+
+The surfaceless platform imposes no platform-specific restrictions on the
+creation of pbuffers, as eglCreatePbufferSurface has no native surface
+parameter.  Specifically, if the EGLDisplay advertises an EGLConfig whose
+EGL_SURFACE_TYPE attribute contains EGL_PBUFFER_BIT, then the EGLDisplay
+permits the creation of pbuffers with that config.
+
+Issues
+
+None.
+
+Revision History
+
+Version 2, 2016-10-13 (Chad Versace)
+- Assign enum values
+- Define interfactions with EGL 1.4 and EGL_EXT_platform_base.
+- Add Gurchetan as contributor, as he implemented the pbuffer support.
+
+Version 1, 2016-09-23 (Chad Versace)
+- Initial version
+- Posted for review at
+  
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129549.html
-- 
2.10.0

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

[Mesa-dev] [PATCH 0/6] EGL_MESA_platform_surfaceless (v2)

[Chad Versace]

Mesa's EGL has supported Chrome OS's "surfaceless" platform for many
months, but the behavior of that platform has never been documented.
Here's my attempt to fix that.

I've already committed the draft extension spec into the private Khronos
registry. After these patches land in master, I plan to publish the spec
in the *public* Khronos registry then delete Mesa's copy.

See the piglit list for tests.

Branches:
- mesa: 
http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=review/EGL_MESA_platform_surfaceless-v02
- piglit: 
http://git.kiwitree.net/cgit/~chadv/piglit/log/?h=review/EGL_MESA_platform_surfaceless-v01

Chad Versace (6):
  docs: Add EGL_MESA_platform_surfaceless.txt (v2)
  egl: Don't advertise unsupported platform extensions
  egl: Implement EGL_MESA_platform_surfaceless
  egl: Move old EGL_MESA_screen_surface spec
  doc/specs: Reference the Khronos registry XML
  docs/specs: Update allocated EGL enum values

 docs/specs/EGL_MESA_platform_surfaceless.txt   | 120 +
 .../specs/OLD/EGL_MESA_screen_surface.txt  |   0
 docs/specs/enums.txt   |  41 +--
 include/EGL/eglmesaext.h   |   5 +
 src/egl/main/eglapi.c  |  42 +++-
 src/egl/main/egldisplay.c  |  21 
 src/egl/main/egldisplay.h  |   5 +
 src/egl/main/eglglobals.c  |  13 ++-
 8 files changed, 238 insertions(+), 9 deletions(-)
 create mode 100644 docs/specs/EGL_MESA_platform_surfaceless.txt
 rename src/egl/docs/EGL_MESA_screen_surface => 
docs/specs/OLD/EGL_MESA_screen_surface.txt (100%)

-- 
2.10.0

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

[Mesa-dev] [PATCH 4/6] egl: Move old EGL_MESA_screen_surface spec

[Chad Versace]

It was the lone file in src/egl/docs. Move it to where the other specs
live, in $MESA_TOP/docs/specs.
---
 .../EGL_MESA_screen_surface => docs/specs/OLD/EGL_MESA_screen_surface.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename src/egl/docs/EGL_MESA_screen_surface => 
docs/specs/OLD/EGL_MESA_screen_surface.txt (100%)

diff --git a/src/egl/docs/EGL_MESA_screen_surface 
b/docs/specs/OLD/EGL_MESA_screen_surface.txt
similarity index 100%
rename from src/egl/docs/EGL_MESA_screen_surface
rename to docs/specs/OLD/EGL_MESA_screen_surface.txt
-- 
2.10.0

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

[Mesa-dev] [PATCH 5/6] doc/specs: Reference the Khronos registry XML

[Chad Versace]

Years ago Khronos replaced the registry's spec files with newfangled XML
files.  Update the reference in doc/specs/enum.txt accordingly.
---
 docs/specs/enums.txt | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
index b37768e..1a49db4 100644
--- a/docs/specs/enums.txt
+++ b/docs/specs/enums.txt
@@ -1,5 +1,10 @@
+The definitive source for enum values and reserved ranges are the XML files in
+the Khronos registry:
 
-See the OpenGL ARB enum registry at 
http://www.opengl.org/registry/api/enum.spec
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/egl.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
 
 Blocks allocated to Mesa:
0x8750-0x875F
@@ -13,7 +18,7 @@ GL_MESA_packed_depth_stencil
GL_UNSIGNED_SHORT_15_1_MESA  0x8753
GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
 
-GL_MESA_trace.spec:
+GL_MESA_trace:
GL_TRACE_ALL_BITS_MESA   0x
GL_TRACE_OPERATIONS_BIT_MESA 0x0001
GL_TRACE_PRIMITIVES_BIT_MESA 0x0002
@@ -24,12 +29,12 @@ GL_MESA_trace.spec:
GL_TRACE_MASK_MESA   0x8755
GL_TRACE_NAME_MESA   0x8756
 
-MESA_ycbcr_texture.spec:
+GL_MESA_ycbcr_texture:
GL_YCBCR_MESA0x8757
GL_UNSIGNED_SHORT_8_8_MESA   0x85BA /* same as Apple's */
GL_UNSIGNED_SHORT_8_8_REV_MESA   0x85BB /* same as Apple's */
 
-GL_MESA_pack_invert.spec
+GL_MESA_pack_invert:
GL_PACK_INVERT_MESA  0x8758
 
 GL_MESA_shader_debug.spec: (obsolete)
@@ -37,7 +42,7 @@ GL_MESA_shader_debug.spec: (obsolete)
 GL_DEBUG_PRINT_MESA  0x875A
 GL_DEBUG_ASSERT_MESA 0x875B
 
-GL_MESA_program_debug.spec: (obsolete)
+GL_MESA_program_debug: (obsolete)
GL_FRAGMENT_PROGRAM_CALLBACK_MESA  0x
GL_VERTEX_PROGRAM_CALLBACK_MESA0x
GL_FRAGMENT_PROGRAM_POSITION_MESA  0x
@@ -54,4 +59,3 @@ GL_MESAX_texture_stack:
GL_PROXY_TEXTURE_2D_STACK_MESAX  0x875C
GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
-
-- 
2.10.0

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

[Mesa-dev] [PATCH 3/6] egl: Implement EGL_MESA_platform_surfaceless

[Chad Versace]

---
 include/EGL/eglmesaext.h  |  5 +
 src/egl/main/eglapi.c | 42 +-
 src/egl/main/egldisplay.c | 21 +
 src/egl/main/egldisplay.h |  5 +
 src/egl/main/eglglobals.c |  3 +++
 5 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 337dd2c..188452e 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -84,6 +84,11 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLSWAPBUFFERSREGIONNOK) 
(EGLDisplay dpy, EG
 #define EGL_NO_CONFIG_MESA ((EGLConfig)0)
 #endif
 
+#ifndef EGL_MESA_platform_surfaceless
+#define EGL_MESA_platform_surfaceless 1
+#define EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+#endif /* EGL_MESA_platform_surfaceless */
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4568b8b..d8bd76d 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -393,6 +393,11 @@ _eglGetPlatformDisplayCommon(EGLenum platform, void 
*native_display,
   attrib_list);
   break;
 #endif
+#ifdef HAVE_SURFACELESS_PLATFORM
+   case EGL_PLATFORM_SURFACELESS_MESA:
+  dpy = _eglGetSurfacelessDisplay(native_display, attrib_list);
+  break;
+#endif
default:
   RETURN_EGL_ERROR(NULL, EGL_BAD_PARAMETER, NULL);
}
@@ -837,11 +842,30 @@ _eglCreateWindowSurfaceCommon(_EGLDisplay *disp, 
EGLConfig config,
_EGLSurface *surf;
EGLSurface ret;
 
-   _EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
 
if (native_window == NULL)
   RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE);
 
+#ifdef HAVE_SURFACELESS_PLATFORM
+   if (disp->Platform == _EGL_PLATFORM_SURFACELESS) {
+  /* From the EGL_MESA_platform_surfaceless spec (v1):
+   *
+   *eglCreatePlatformWindowSurface fails when called with a 
+   *that belongs to the surfaceless platform. It returns
+   *EGL_NO_SURFACE and generates EGL_BAD_NATIVE_WINDOW. The
+   *justification for this unconditional failure is that the
+   *surfaceless platform has no native windows, and therefore the
+   * parameter is always invalid.
+   *
+   * This check must occur before checking the EGLConfig, which emits
+   * EGL_BAD_CONFIG.
+   */
+  RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE);
+   }
+#endif
+
+   _EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
+
surf = drv->API.CreateWindowSurface(drv, disp, conf, native_window,
attrib_list);
ret = (surf) ? _eglLinkSurface(surf) : EGL_NO_SURFACE;
@@ -943,6 +967,22 @@ _eglCreatePixmapSurfaceCommon(_EGLDisplay *disp, EGLConfig 
config,
_EGLSurface *surf;
EGLSurface ret;
 
+#if HAVE_SURFACELESS_PLATFORM
+   if (disp->Platform == _EGL_PLATFORM_SURFACELESS) {
+  /* From the EGL_MESA_platform_surfaceless spec (v1):
+   *
+   *   [Like eglCreatePlatformWindowSurface,] 
eglCreatePlatformPixmapSurface
+   *   also fails when called with a  that belongs to the
+   *   surfaceless platform.  It returns EGL_NO_SURFACE and generates
+   *   EGL_BAD_NATIVE_PIXMAP.
+   *
+   * This check must occur before checking the EGLConfig, which emits
+   * EGL_BAD_CONFIG.
+   */
+  RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_PIXMAP, EGL_NO_SURFACE);
+   }
+#endif
+
_EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
surf = drv->API.CreatePixmapSurface(drv, disp, conf, native_pixmap,
attrib_list);
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index 3d4eb81..37711bd 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -540,3 +540,24 @@ _eglGetWaylandDisplay(struct wl_display *native_display,
return _eglFindDisplay(_EGL_PLATFORM_WAYLAND, native_display);
 }
 #endif /* HAVE_WAYLAND_PLATFORM */
+
+#ifdef HAVE_SURFACELESS_PLATFORM
+_EGLDisplay*
+_eglGetSurfacelessDisplay(void *native_display,
+  const EGLint *attrib_list)
+{
+   /* This platform has no native display. */
+   if (native_display != NULL) {
+  _eglError(EGL_BAD_PARAMETER, "eglGetPlatformDisplay");
+  return NULL;
+   }
+
+   /* This platform recognizes no display attributes. */
+   if (attrib_list != NULL && attrib_list[0] != EGL_NONE) {
+  _eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
+  return NULL;
+   }
+
+   return _eglFindDisplay(_EGL_PLATFORM_SURFACELESS, native_display);
+}
+#endif /* HAVE_SURFACELESS_PLATFORM */
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index 22fb5c8..62d9a11 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -274,6 +274,11 @@ _eglGetWaylandDisplay(struct wl_display *native_display,
   const EGLint *attrib_list);
 #endif
 
+#ifdef HAVE_SURFACELESS_PLATFORM
+_EGLDisplay*
+_eglGetSurfacelessDisplay(void *n

[Mesa-dev] [PATCH 6/6] docs/specs: Update allocated EGL enum values

[Chad Versace]

Document the EGL enum ranges for Mesa and those values allocated by the
following extensions:

EGL_MESA_drm_image
EGL_MESA_platform_gbm
EGL_MESA_platform_surfaceless
EGL_WL_bind_wayland_display
---
 docs/specs/enums.txt | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
index 1a49db4..1caa284 100644
--- a/docs/specs/enums.txt
+++ b/docs/specs/enums.txt
@@ -6,10 +6,13 @@ the Khronos registry:
 https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
 https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
 
-Blocks allocated to Mesa:
+GL blocks allocated to Mesa:
0x8750-0x875F
0x8BB0-0x8BBF
 
+EGL blocks allocated to Mesa:
+   0x31D0-0x31DF
+   0x3290-0x329F
 
 GL_MESA_packed_depth_stencil
GL_DEPTH_STENCIL_MESA0x8750
@@ -59,3 +62,25 @@ GL_MESAX_texture_stack:
GL_PROXY_TEXTURE_2D_STACK_MESAX  0x875C
GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
+
+EGL_MESA_drm_image
+EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
+EGL_DRM_BUFFER_USE_MESA0x31D1
+EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2
+EGL_DRM_BUFFER_MESA0x31D3
+EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
+
+EGL_MESA_platform_gbm
+EGL_PLATFORM_GBM_MESA   0x31D7
+
+EGL_MESA_platform_surfaceless
+EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+
+EGL_WL_bind_wayland_display
+EGL_TEXTURE_FORMAT  0x3080
+EGL_WAYLAND_BUFFER_WL   0x31D5
+EGL_WAYLAND_PLANE_WL0x31D6
+EGL_TEXTURE_Y_U_V_WL0x31D7
+EGL_TEXTURE_Y_UV_WL 0x31D8
+EGL_TEXTURE_Y_XUXV_WL   0x31D9
+EGL_WAYLAND_Y_INVERTED_WL   0x31DB
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 5/5] st/glsl_to_tgsi: fix [ui]vec[34] conversion to double

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 13, 2016 at 5:13 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> The corresponding opcodes for integers need to be treated the same as F2D.
>
> Fixes GL45-CTS.gpu_shader_fp64.conversions.
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 682c034..f49a873 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -862,22 +862,23 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
> unsigned op,
>dinst->src[j].index++;
>}
>
> if (swz & 1)
>dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_Z, 
> SWIZZLE_W, SWIZZLE_Z, SWIZZLE_W);
> else
>dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_X, 
> SWIZZLE_Y, SWIZZLE_X, SWIZZLE_Y);
>
>  } else {
> /* some opcodes are special case in what they use as sources
> -  - F2D is a float src0, DLDEXP is integer src1 */
> -   if (op == TGSI_OPCODE_F2D ||
> +  - [FUI]2D/[UI]2I64 is a float/[u]int src0, DLDEXP is 
> integer src1 */
> +   if (op == TGSI_OPCODE_F2D || op == TGSI_OPCODE_U2D || op == 
> TGSI_OPCODE_I2D ||
> +   op == TGSI_OPCODE_I2I64 || op == TGSI_OPCODE_U2I64 ||
> op == TGSI_OPCODE_DLDEXP ||
> (op == TGSI_OPCODE_UCMP && dst_is_64bit[0])) {
>dinst->src[j].swizzle = MAKE_SWIZZLE4(swz, swz, swz, swz);
> }
>  }
>   }
>}
>inst = dinst;
> } else {
>this->instructions.push_tail(inst);
> --
> 2.7.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

[Mesa-dev] [Bug 98222] [radv] LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.image.store

[bugzilla-daemon]

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

--- Comment #1 from Christoph Haag  ---
https://cgit.freedesktop.org/mesa/mesa/commit/?id=5c66d46d6ace0603227e4b919b132416444949e7
should fix it.

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

Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

[Robert Foss]

On 2016-10-13 04:37 PM, Rafael Antognolli wrote:

Hi all,

On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:



On 2016-10-11 01:37 PM, Chad Versace wrote:

On Tue 11 Oct 2016, Emil Velikov wrote:

On 10 October 2016 at 20:41, Rob Clark  wrote:

On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace  wrote:



Testing:

I haven't yet tested EGL_ANDROID_native_fence_sync with these patches, but
the series does build. I just wanted to get these patches on the list as a
status-update.  I'm slowly working on getting Rob Clark's hacked-up kmscube 
to
work on this series.

I did test that this series doesn't break any dEQP-EGL sync tests. But my
dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.




From a quick skim neither one of CTS/dEQP/piglit had
EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
adding a few piglits might be a good idea. It would be good to
coordinate to avoid writing the same tests twice ;-)


Yes, we should have tests before committing this feature. I am releasing
any lock I may had held on test writing, as I don't have time to tackle
that this week.


Writing the tests is not on my table at the moment. Perhaps some time can be
scraped together for it at a later point, but not now.


If nobody has started writing piglit tests yet, and it's OK with you
guys, I would like to give it a try since I'm also interested in this
feature.

Also if I understood correctly, the initial thing to test is whether
WaitSync and ClientWaitSync respect input fences, right? I'll try to
come up with a list of other things to test, like invalid fences and so
on, but if you guys already have a list of things to test in mind,
please let me know.

Anyway, is it fine if I start working on this?


That would be very welcome!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] clover: Allow OpenCL version override

[Vedran Miletić]

CLOVER_CL_VERSION_OVERRIDE allows overriding default OpenCL version
supported by Clover, analogous to MESA_GL_VERSION_OVERRIDE for OpenGL.
CLOVER_CL_C_VERSION_OVERRIDE allows overridng default OpenCL C version.

v2:
  - move version getters to version.hpp, simplify
  - set -cl-std= to CLOVER_CL_C_VERSION_OVERRIDE
  - set __OPENCL_VERSION__ to CLOVER_CL_VERSION_OVERRIDE
---
 docs/envvars.html  | 12 ++
 src/gallium/state_trackers/clover/Makefile.sources |  3 +-
 src/gallium/state_trackers/clover/api/device.cpp   |  5 ++-
 src/gallium/state_trackers/clover/api/platform.cpp |  3 +-
 .../state_trackers/clover/llvm/invocation.cpp  | 30 --
 src/gallium/state_trackers/clover/llvm/util.hpp|  4 +-
 src/gallium/state_trackers/clover/util/version.hpp | 48 ++
 7 files changed, 95 insertions(+), 10 deletions(-)
 create mode 100644 src/gallium/state_trackers/clover/util/version.hpp

diff --git a/docs/envvars.html b/docs/envvars.html
index cf57ca5..f76827b 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -235,6 +235,18 @@ Setting to "tgsi", for example, will print all the TGSI 
shaders.
 See src/mesa/state_tracker/st_debug.c for other options.
 
 
+Clover state tracker environment variables
+
+
+CLOVER_CL_VERSION_OVERRIDE - allows overriding OpenCL version returned by
+clGetPlatformInfo(CL_PLATFORM_VERSION) and
+clGetDeviceInfo(CL_DEVICE_VERSION). Note that the setting sets the version
+of the platform and all the devices to the same value.
+CLOVER_CL_C_VERSION_OVERRIDE - allows overriding OpenCL C version reported
+by clGetDeviceInfo(CL_DEVICE_OPENCL_C_VERSION) and the value of the
+__OPENCL_VERSION__ macro in the OpenCL compiler.
+
+
 Softpipe driver environment variables
 
 SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment shaders
diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
b/src/gallium/state_trackers/clover/Makefile.sources
index e9828b1..37f61b0 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -50,7 +50,8 @@ CPP_SOURCES := \
util/lazy.hpp \
util/pointer.hpp \
util/range.hpp \
-   util/tuple.hpp
+   util/tuple.hpp \
+   util/version.hpp
 
 LLVM_SOURCES := \
llvm/codegen/bitcode.cpp \
diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index f7bd61b..a759e0e 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -23,6 +23,7 @@
 #include "api/util.hpp"
 #include "core/platform.hpp"
 #include "core/device.hpp"
+#include "util/version.hpp"
 #include "git_sha1.h"
 
 using namespace clover;
@@ -301,7 +302,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_VERSION:
-  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
+  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
PACKAGE_VERSION
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
@@ -355,7 +356,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_OPENCL_C_VERSION:
-  buf.as_string() = "OpenCL C 1.1 ";
+  buf.as_string() = "OpenCL C " + get_opencl_c_version() + " ";
   break;
 
case CL_DEVICE_PARENT_DEVICE:
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
b/src/gallium/state_trackers/clover/api/platform.cpp
index b1b1fdf..f3360fe 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -22,6 +22,7 @@
 
 #include "api/util.hpp"
 #include "core/platform.hpp"
+#include "util/version.hpp"
 #include "git_sha1.h"
 
 using namespace clover;
@@ -58,7 +59,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
   break;
 
case CL_PLATFORM_VERSION:
-  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
+  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
PACKAGE_VERSION
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index b5e8b52..6886dad 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -52,7 +52,7 @@
 #include "llvm/metadata.hpp"
 #include "llvm/util.hpp"
 #include "util/algorithm.hpp"
-
+#include "util/version.hpp"
 
 using namespace clover;
 using namespace clover::llvm;
@@ -120,10 +120,23 @@ namespace {
   // http://www.llvm.org/bugs/show_bug.cgi?id=19735
   c->getDiagnosticOpts().ShowCarets = false;
 
+  const std::string opencl_c_version = get_opencl_c_version();
+  clang::LangStandard::Kind lang_kind;
+  if (opencl_c_version == "1.0")
+ lang

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Michel Dänzer]

On 13/10/16 07:14 PM, Emil Velikov wrote:
> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
>> On 13/10/16 03:37 AM, Tobias Droste wrote:
>>> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>
> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
> +LLVM_VERSION_REQUIRED_R600=3.6.0
> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0

 There's a small related gotcha: as-is at build time we get the
 different codepaths thus, as people build against shared LLVM (hello
 Archlinux, I'm looking at you) and update their LLVM without
 rebuilding mesa (Arch I'm looking at you again) things go funny.
>>
>> What exactly happened there? LLVM upstream generates shared libraries
>> named libLLVM-..so*, so it shouldn't be possible for a
>> simple LLVM package update to break Mesa, unless Arch did something
>> really stupid.
>>
> The issue is not specific to Arch, but anyone who links against shared LLVM.
> 
> Here is another take on it:
> At least swr and r600/radeonsi depend at _build_ time on the _patch_
> version of LLVM. The latter of which is not part of the DSO name. Thus
> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
> "3.9.x" codepath even though you are be using "3.9.y" LLVM.

That should be fine, since 3.9.y is backwards compatible with 3.9.x.

Debian doesn't automatically recompile Mesa in such cases either, and I
haven't seen any problems there because of that.

So, what exactly was the problem?


 Tl;Dr; We really want to enable static linking by default and prod
 distros to use it.
>>>
>>> I'm all in favor of statically linking LLVM (that's the way I'm doing this 
>>> on
>>> my pc).
>>> I think the only reason this is not done is because people (also here on the
>>> list) don't want any static linkg of external libraries because of size or
>>> whatever.
>>> So changing the default to static is easy, but I doubt it will make everyone
>>> happy ;-)
>>
>> Indeed, it'd probably make many distro packagers unhappy, because
>> they'll just have to re-enable shared linking, because packaging
>> policies generally strongly discourage if not outright forbid static
>> linking.
>>
> The toggle is there and is not going away, afaict. If people are going
> to get upset that the default does not meet their policy... just
> toggle and get on with other things ;-)

The question is if it makes sense for the default to be different from
what the majority of users end up using. It doesn't to me.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Michel Dänzer]

On 13/10/16 11:16 PM, Mike Lothian wrote:
> If you recompile llvm and mesa each time, are there any downsides of
> using the shared libs?

No particular downsides come to mind, rather upsides:

* Generally no requirement to rebuild Mesa after changes to LLVM.
* Both LLVM and Mesa take significantly less time, memory and disk
  space to build.


> I think there were some issues with some programs / games that had
> clashing symbols but I'm not sure if that's still an issue

I'm only aware of such issues with the Steam runtime, which are arguably
because the current implementation (if not the design) of the Steam
runtime is broken (in ways affecting libraries other than Mesa as well,
so it's not like Mesa linking LLVM statically magically solves all Steam
runtime issues).

BTW, AFAIK just linking LLVM statically into Mesa isn't enough to avoid
these issues, one would also need to link libstdc++ statically into LLVM.


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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

[Michel Dänzer]

On 14/10/16 09:54 AM, Michel Dänzer wrote:
> On 13/10/16 11:16 PM, Mike Lothian wrote:
>> I think there were some issues with some programs / games that had
>> clashing symbols but I'm not sure if that's still an issue
> 
> I'm only aware of such issues with the Steam runtime, which are arguably
> because the current implementation (if not the design) of the Steam
> runtime is broken (in ways affecting libraries other than Mesa as well,
> so it's not like Mesa linking LLVM statically magically solves all Steam
> runtime issues).
> 
> BTW, AFAIK just linking LLVM statically into Mesa isn't enough to avoid
> these issues, one would also need to link libstdc++ statically into LLVM.

I forgot to mention that it's easy to avoid these issues via LD_PRELOAD.
I'm currently using this for Steam:

LD_PRELOAD='/$LIB/libgpg-error.so.0:/$LIB/libtinfo.so.5:/usr/$LIB/libstdc++.so.6:/usr/$LIB/libxcb.so.1':$LD_PRELOAD


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