date:20151005

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

--- Comment #5 from Emil Velikov  ---
(In reply to Neil Roberts from comment #2)
> I think the general problem is that if you install an old version of Mesa
> somewhere and then try and build a new version while specifying the install
> prefix of the old version as an include path with -I in the CPPFLAGS then it
> will end up picking up the old installed headers instead of the ones that
> are internal to the Mesa source tree. In this case the problematic header is
> GL/internal/dri_interface.h, but there are others. It doesn't seem like this
> is such an unusual thing to do so it would be nice if it worked.
> 
> Note, in this case it was being built out-of-tree, but I'm not sure if
> that's necessary to replicate the bug.

I've been building mesa OOT for 2+ years, and I'm afraid that I've not hit
headers issues. If you can come up with some examples/how to, that'll be
appreciated.

There is some (re-)linking fun, when libtool 'inserts' -L/usr/lib prior to
-L/custom/prefix, but that will require a massive rewrite on our side :'(

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] mesa: remove unneeded error check in create_textures()

2015-10-05 Thread Brian Paul

Callers of create_texture() will either pass target=0 or a validated
GL texture target enum so no need to do another error check inside
the loop.
---
 src/mesa/main/texobj.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 173e43c..aa4b38c 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1211,6 +1211,7 @@ _mesa_create_nameless_texture(struct gl_context *ctx, 
GLenum target)
  * glCreateTextures should throw errors if target = 0. This is not exposed to
  * the rest of Mesa to encourage Mesa internals to use nameless textures,
  * which do not require expensive hash lookups.
+ * \param target  either 0 or a a valid / error-checked texture target enum
  */
 static void
 create_textures(struct gl_context *ctx, GLenum target,
@@ -1219,6 +1220,7 @@ create_textures(struct gl_context *ctx, GLenum target,
GLuint first;
GLint i;
const char *func = dsa ? "Create" : "Gen";
+   const GLint targetIndex = _mesa_tex_target_to_index(ctx, target);
 
if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
   _mesa_debug(ctx, "gl%sTextures %d\n", func, n);
@@ -1241,7 +1243,6 @@ create_textures(struct gl_context *ctx, GLenum target,
/* Allocate new, empty texture objects */
for (i = 0; i < n; i++) {
   struct gl_texture_object *texObj;
-  GLint targetIndex;
   GLuint name = first + i;
   texObj = ctx->Driver.NewTextureObject(ctx, name, target);
   if (!texObj) {
@@ -1252,14 +1253,6 @@ create_textures(struct gl_context *ctx, GLenum target,
 
   /* Initialize the target index if target is non-zero. */
   if (target != 0) {
- targetIndex = _mesa_tex_target_to_index(ctx, texObj->Target);
- if (targetIndex < 0) { /* Bad Target */
-mtx_unlock(>Shared->Mutex);
-_mesa_error(ctx, GL_INVALID_ENUM, "gl%sTextures(target = %s)",
-func, _mesa_enum_to_string(texObj->Target));
-return;
- }
- assert(targetIndex < NUM_TEXTURE_TARGETS);
  texObj->TargetIndex = targetIndex;
   }
 
-- 
1.9.1

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

[Mesa-dev] [PATCH 3/3] mesa: move gl_texture_object::TargetIndex initializations

2015-10-05 Thread Brian Paul

Before, we were unconditionally assigning the TargetIndex field in
_mesa_BindTexture(), even if it was already set properly.  Now we
initialize TargetIndex wherever we initialize the Target field, in
_mesa_initialize_texture_object(), finish_texture_init(), etc.
---
 src/mesa/main/shared.c  |  5 +
 src/mesa/main/texobj.c  | 27 ++-
 src/mesa/main/textureview.c |  2 ++
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/shared.c b/src/mesa/main/shared.c
index 1acaf59..c37b31d 100644
--- a/src/mesa/main/shared.c
+++ b/src/mesa/main/shared.c
@@ -107,6 +107,11 @@ _mesa_alloc_shared_state(struct gl_context *ctx)
   };
   STATIC_ASSERT(ARRAY_SIZE(targets) == NUM_TEXTURE_TARGETS);
   shared->DefaultTex[i] = ctx->Driver.NewTextureObject(ctx, 0, targets[i]);
+  /* Need to explicitly set/overwrite the TargetIndex field here since
+   * the call to _mesa_tex_target_to_index() in NewTextureObject() may
+   * fail if the texture target is not supported.
+   */
+  shared->DefaultTex[i]->TargetIndex = i;
}
 
/* sanity check */
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 66eacf8..60c55ae 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -286,6 +286,12 @@ _mesa_initialize_texture_object( struct gl_context *ctx,
obj->RefCount = 1;
obj->Name = name;
obj->Target = target;
+   if (target != 0) {
+  obj->TargetIndex = _mesa_tex_target_to_index(ctx, target);
+   }
+   else {
+  obj->TargetIndex = NUM_TEXTURE_TARGETS; /* invalid/error value */
+   }
obj->Priority = 1.0F;
obj->BaseLevel = 0;
obj->MaxLevel = 1000;
@@ -340,6 +346,10 @@ finish_texture_init(struct gl_context *ctx, GLenum target,
GLenum filter = GL_LINEAR;
assert(obj->Target == 0);
 
+   obj->Target = target;
+   obj->TargetIndex = _mesa_tex_target_to_index(ctx, target);
+   assert(obj->TargetIndex < NUM_TEXTURE_TARGETS);
+
switch (target) {
   case GL_TEXTURE_2D_MULTISAMPLE:
   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
@@ -1200,7 +1210,6 @@ create_textures(struct gl_context *ctx, GLenum target,
GLuint first;
GLint i;
const char *func = dsa ? "Create" : "Gen";
-   const GLint targetIndex = _mesa_tex_target_to_index(ctx, target);
 
if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
   _mesa_debug(ctx, "gl%sTextures %d\n", func, n);
@@ -1231,11 +1240,6 @@ create_textures(struct gl_context *ctx, GLenum target,
  return;
   }
 
-  /* Initialize the target index if target is non-zero. */
-  if (target != 0) {
- texObj->TargetIndex = targetIndex;
-  }
-
   /* insert into hash table */
   _mesa_HashInsert(ctx->Shared->TexObjects, texObj->Name, texObj);
 
@@ -1356,8 +1360,12 @@ unbind_texobj_from_texunits(struct gl_context *ctx,
const gl_texture_index index = texObj->TargetIndex;
GLuint u;
 
-   if (texObj->Target == 0)
+   if (texObj->Target == 0) {
+  /* texture was never bound */
   return;
+   }
+
+   assert(index < NUM_TEXTURE_TARGETS);
 
for (u = 0; u < ctx->Texture.NumCurrentTexUsed; u++) {
   struct gl_texture_unit *unit = >Texture.Unit[u];
@@ -1725,10 +1733,11 @@ _mesa_BindTexture( GLenum target, GLuint texName )
  _mesa_HashInsert(ctx->Shared->TexObjects, texName, newTexObj);
  mtx_unlock(>Shared->Mutex);
   }
-  newTexObj->Target = target;
-  newTexObj->TargetIndex = targetIndex;
}
 
+   assert(newTexObj->Target == target);
+   assert(newTexObj->TargetIndex == targetIndex);
+
bind_texture(ctx, ctx->Texture.CurrentUnit, newTexObj);
 }
 
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 5a3282a..04b7d73 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -681,6 +681,8 @@ _mesa_TextureView(GLuint texture, GLenum target, GLuint 
origtexture,
texObj->Immutable = GL_TRUE;
texObj->ImmutableLevels = origTexObj->ImmutableLevels;
texObj->Target = target;
+   texObj->TargetIndex = _mesa_tex_target_to_index(ctx, target);
+   assert(texObj->TargetIndex < NUM_TEXTURE_TARGETS);
 
if (ctx->Driver.TextureView != NULL &&
!ctx->Driver.TextureView(ctx, texObj, origTexObj)) {
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/3] mesa: remove unused _mesa_create_nameless_texture()

2015-10-05 Thread Brian Paul

---
 src/mesa/main/texobj.c | 20 
 src/mesa/main/texobj.h |  3 ---
 2 files changed, 23 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index aa4b38c..66eacf8 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1185,26 +1185,6 @@ invalidate_tex_image_error_check(struct gl_context *ctx, 
GLuint texture,
return t;
 }
 
-/**
- * Wrapper for the driver function. Need this because _mesa_new_texture_object
- * permits a target of 0 and does not initialize targetIndex.
- */
-struct gl_texture_object *
-_mesa_create_nameless_texture(struct gl_context *ctx, GLenum target)
-{
-   struct gl_texture_object *texObj = NULL;
-   GLint targetIndex;
-
-   if (target == 0)
-  return texObj;
-
-   texObj = ctx->Driver.NewTextureObject(ctx, 0, target);
-   targetIndex = _mesa_tex_target_to_index(ctx, texObj->Target);
-   assert(targetIndex < NUM_TEXTURE_TARGETS);
-   texObj->TargetIndex = targetIndex;
-
-   return texObj;
-}
 
 /**
  * Helper function for glCreateTextures and glGenTextures. Need this because
diff --git a/src/mesa/main/texobj.h b/src/mesa/main/texobj.h
index 690878c..8421337 100644
--- a/src/mesa/main/texobj.h
+++ b/src/mesa/main/texobj.h
@@ -202,9 +202,6 @@ _mesa_unlock_context_textures( struct gl_context *ctx );
 extern void
 _mesa_lock_context_textures( struct gl_context *ctx );
 
-extern struct gl_texture_object *
-_mesa_create_nameless_texture(struct gl_context *ctx, GLenum target);
-
 extern void
 _mesa_delete_nameless_texture(struct gl_context *ctx,
   struct gl_texture_object *texObj);
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] glsl: Fix variable_referenced() for vector_{extract,insert} expressions

2015-10-05 Thread Markus Wick


Am 2015-10-05 11:42, schrieb Iago Toral Quiroga:

We get these when we operate on vector variables with array accessors
(i.e. things like a[0] where 'a' is a vec4). When we call 
variable_referenced()
on these expressions we want to return a reference to 'a' instead of 
NULL.


This fixes a problem where we pass a[0] as the first argument to an 
atomic
SSBO function that expects a buffer variable. In order to check this, 
we use
variable_referenced(), but that is currently returning NULL in this 
case, since

the underlying rvalue is a vector_extract expression.
---
 src/glsl/ir.cpp | 16 
 src/glsl/ir.h   |  2 ++
 2 files changed, 18 insertions(+)


Tested-by: Markus Wick 

This fixes my last issue with SSBO on dolphin-emu.

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

[Mesa-dev] [RFC v4] i965/gen8+: bo in state base address must be in 32-bit address range

2015-10-05 Thread Michel Thierry

Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.

In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap or Instruction State Heap must be in a 32-bit range
(GSH / ISH), because the General State Offset and Instruction State
Offset are limited to 32-bits.

Use drm_intel_bo_use_48b_address_range to flag when the 4GB limit is not
necessary, and the bo can be in the full address space.

This commit introduces a dependency of libdrm 2.4.6x, which introduces
the drm_intel_bo_use_48b_address_range function.

v2: s/48baddress/48b_address/,
Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address
offset is needed (Ben)
v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit
relocation needs the 32-bit workaround (Chris)
v4: In order to use full address space, libdrm requires to set the
support flag before calling emit_reloc.

References: 
http://lists.freedesktop.org/archives/dri-devel/2015-September/089757.html
Cc: Ben Widawsky 
Cc: Chris Wilson 
Signed-off-by: Michel Thierry 
---
 configure.ac  |  2 +-
 src/mesa/drivers/dri/i965/gen8_misc_state.c   | 17 ++---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 18 ++
 src/mesa/drivers/dri/i965/intel_batchbuffer.h | 16 
 4 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/configure.ac b/configure.ac
index 217281f..e31f4d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,7 +71,7 @@ dnl Versions for external dependencies
 LIBDRM_REQUIRED=2.4.60
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_AMDGPU_REQUIRED=2.4.63
-LIBDRM_INTEL_REQUIRED=2.4.61
+LIBDRM_INTEL_REQUIRED=2.4.66 #yes, it does not exist yet
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
 LIBDRM_NOUVEAU_REQUIRED=2.4.62
 LIBDRM_FREEDRENO_REQUIRED=2.4.65
diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c 
b/src/mesa/drivers/dri/i965/gen8_misc_state.c
index a46b252..7b4e448 100644
--- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
@@ -28,6 +28,9 @@
 
 /**
  * Define the base addresses which some state is referenced from.
+ * Use OUT_RELOC64_INSIDE_4G instead of OUT_RELOC64, because the General State
+ * Offset and Instruction State Offset are limited to 32-bits by hardware,
+ * and must be located in the first 4GBs (32-bit offset).
  */
 static void
 gen8_upload_state_base_address(struct brw_context *brw)
@@ -42,18 +45,18 @@ gen8_upload_state_base_address(struct brw_context *brw)
OUT_BATCH(0);
OUT_BATCH(mocs_wb << 16);
/* Surface state base address: */
-   OUT_RELOC64(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
-   mocs_wb << 4 | 1);
+   OUT_RELOC64_INSIDE_4G(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
+ mocs_wb << 4 | 1);
/* Dynamic state base address: */
-   OUT_RELOC64(brw->batch.bo,
-   I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION, 0,
-   mocs_wb << 4 | 1);
+   OUT_RELOC64_INSIDE_4G(brw->batch.bo,
+ I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION, 
0,
+ mocs_wb << 4 | 1);
/* Indirect object base address: MEDIA_OBJECT data */
OUT_BATCH(mocs_wb << 4 | 1);
OUT_BATCH(0);
/* Instruction base address: shader kernels (incl. SIP) */
-   OUT_RELOC64(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
-   mocs_wb << 4 | 1);
+   OUT_RELOC64_INSIDE_4G(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
+ mocs_wb << 4 | 1);
 
/* General state buffer size */
OUT_BATCH(0xf001);
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 0363bd3..b15d627 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -427,11 +427,21 @@ uint64_t
 intel_batchbuffer_reloc64(struct brw_context *brw,
   drm_intel_bo *buffer, uint32_t offset,
   uint32_t read_domains, uint32_t write_domain,
-  uint32_t delta)
+  uint32_t delta, uint32_t support_48bit_offset)
 {
-   int ret = drm_intel_bo_emit_reloc(brw->batch.bo, offset,
- buffer, delta,
- read_domains, write_domain);
+   int ret;
+
+   /* Not all buffers can be allocated outside the first 4GB, and
+* the offset must be limited to 32-bits.
+*/
+   if (support_48bit_offset)
+  drm_intel_bo_use_48b_address_range(buffer, 1);
+   else
+  drm_intel_bo_use_48b_address_range(buffer, 0);
+
+   ret = drm_intel_bo_emit_reloc(brw->batch.bo, offset,
+ buffer, delta,
+ read_domains, write_domain);
assert(ret == 0);
(void) ret;

Re: [Mesa-dev] [PATCH] mesa: Add missing _mm_mfence() before streaming loads.

2015-10-05 Thread Matt Turner

On Thu, Oct 1, 2015 at 11:20 AM, Jordan Justen
 wrote:
> On 2015-10-01 10:11:33, Matt Turner wrote:
>> According to the Intel Software Development Manual:
>
> How about a more specific doc location?
>
> According to the Intel Software Development Manual (Volume 1: Basic
> Architecture, 12.10.3 Streaming Load Hint Instruction):

Sure. Thanks for looking that up for me.

>>Streaming loads may be weakly ordered and may appear to software to
>>execute out of order with respect to other memory operations.
>>Software must explicitly use fences (e.g. MFENCE) if it needs to
>>preserve order among streaming loads or between streaming loads and
>>other memory operations.
>
> Does this mean we need a mfence following the load as well?

I didn't think so, and Joseph has confirmed.

Can I consider this a Reviewed-by?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92286] Distant geometry renders in front of closer geometry (depth test fail) in DarkRadiant / wxWidgets

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

MirceaKitsune  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from MirceaKitsune  ---
The cause of the issue has been at last found, thanks to a suggestion by
OrbWeaver. It was triggered by initializing the WX OpenGL canvas without any
attributes, which caused Mesa to assume no depth buffer at all. I have created
a patch for DarkRadiant which makes it usable.

I guess the question of this bug report remains whether Mesa is doing something
wrong here. On the proprietary video drivers, it's ok to leave the attribs
parameter of wxGLCanvas empty... but for depth buffering to work on Mesa, you
must include WX_GL_DEPTH_SIZE and give it a buffer size.

So if anyone here is familiar with wxWidgets, please take a look at this. If
you think Mesa is doing the right thing, this report can be closed. I don't
know enough to decide that, but to me it feels like depth testing being the
only thing that doesn't work in this scenario denotes a problem.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

2015-10-05 Thread Kristian Høgsberg

On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry  wrote:
> On 9/14/2015 2:54 PM, Michał Winiarski wrote:
>>
>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>>> allocated inside the 32-bit address range.
>>>
>>> In specific, any resource used with flat/heapless (0x-0xf000)
>>> General State Heap (GSH) or Instruction State Heap (ISH) must be in a
>>> 32-bit range, because the General State Offset and Instruction State
>>> Offset
>>> are limited to 32-bits.
>>>
>>> The i915 driver has been modified to provide a flag to set when the 4GB
>>> limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>>> 48-bit range will only be used when explicitly requested.
>>>
>>> Callers to the existing drm_intel_bo_emit_reloc function should set the
>>> use_48b_address_range flag beforehand, in order to use full ppgtt range.
>>>
>>> v2: Make set/clear functions nops on pre-gen8 platforms, and use them
>>>  internally in emit_reloc functions (Ben)
>>>  s/48BADDRESS/48B_ADDRESS/ (Dave)
>>> v3: Keep set/clear functions internal, no-one needs to use them directly.
>>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
>>>  before enabling set/clear function, print full offsets in debug
>>>  statements, using port of lower_32_bits and upper_32_bits from linux
>>>  kernel (Michał)
>>>
>>> References:
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>>> Cc: Ben Widawsky 
>>> Cc: Michał Winiarski 
>>
>>
>> +Kristian
>>
>> LGTM.
>> Acked-by: Michał Winiarski 
>>
>>> Signed-off-by: Michel Thierry 
>
>
>
> Hi Kristian,
>
> More comments on this?
> I've resent the mesa patch with the last changes
> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>
> Michał has agreed with the interface and will use it for his work.
> If mesa doesn't plan to use this for now, it's ok. The kernel changes have
> been done to prevent any regressions when the support 48-bit flag is not
> set.

I didn't get any replies to my last comments on this:

http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html

Basically, I tried explicitly placing buffers above 8G and didn't see
the HW problem described (ie it all worked fine).  I still think
there's some confusion as to what the W/A is about.

Here's my take: the W/A is a SW-only workaround to handle the cases
where a driver uses heapless and 48-bit ppgtt. The problem is that the
heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
anywhere it the 48 bit address space. If that happens it's consideredd
out-of-bounds for the heap and access fails. To prevent this we need
to make sure the bos we address in a heapless fashion are placed below
4g.

For mesa, we only configure general state base as heap-less, which
affects scratch bos. What this boils down to is that we need the 4G
restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
and 3DSTATE_PS (and tesselation stage eventually). Look for the
OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
and gen8_ps_state.c

Kristian

> Thanks,
>
> -Michel
>
>
>>> ---
>>>   include/drm/i915_drm.h|  3 +-
>>>   intel/intel_bufmgr.c  | 11 ++
>>>   intel/intel_bufmgr.h  |  1 +
>>>   intel/intel_bufmgr_gem.c  | 88
>>> +--
>>>   intel/intel_bufmgr_priv.h | 14 
>>>   5 files changed, 97 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>>> index ded43b1..426b25c 100644
>>> --- a/include/drm/i915_drm.h
>>> +++ b/include/drm/i915_drm.h
>>> @@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
>>>   #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>>   #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>>>   #define EXEC_OBJECT_WRITE (1<<2)
>>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>>> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
>>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS
>>> -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
>>> __u64 flags;
>>>
>>> __u64 rsvd1;
>>> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
>>> index 14ea9f9..0856e60 100644
>>> --- a/intel/intel_bufmgr.c
>>> +++ b/intel/intel_bufmgr.c
>>> @@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
>>>   }
>>>
>>>   int
>>> +drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
>>> +{
>>> +   if (bo->bufmgr->bo_use_48b_address_range) {
>>> +   bo->bufmgr->bo_use_48b_address_range(bo, enable);
>>> +   return 0;
>>> +   }
>>> +
>>> +   return -ENODEV;
>>> +}
>>> +
>>> +int
>>>   drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
>>>   {
>>> return bo->bufmgr->bo_references(bo, target_bo);
>>>

Re: [Mesa-dev] [PATCH 2/2] i965: Fix intel_miptree_is_fast_clear_capable()

2015-10-05 Thread Chad Versace

On Thu 01 Oct 2015, Ben Widawsky wrote:
> On Thu, Oct 01, 2015 at 08:20:07AM -0700, Chad Versace wrote:
> > There are three types of fast clears:
> >   a. fast depth clears
> >   b. fast singlesample color clears
> >   c. fast multisample color clears
> > Function intel_miptree_is_fast_clear_capable() checks if a miptree
> > supports fast clears of type (b).
> > 
> > Rename the function to disambiguate what it does:
> >   old: intel_miptree_is_fast_clear_capable
> >   new: intel_miptree_supports_non_msrt_fast_clear
> > 
> > The functionally *accidentally* rejected multisampled color surfaces
> > because it thought they were singlesample array surfaces. Fix that by
> > explicitly rejecting surfaces with samples > 1.
> > 
> 
> I wasn't going to say anything except you put "accidentally" in bold. I
> don't think you can determine what Paul was thinking when he originally
> implemented that code. Calling it accidental is unnecessarily judgmental (as 
> is
> my response here). The code was correct, and unless you want to ask him, we
> should assume it was intentional.

Ok, I removed the asterisks around "accidentally".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nouveau: make sure there's always room to emit a fence

2015-10-05 Thread Ilia Mirkin

I started seeing a lot of situations on nv30 where fence emission
wouldn't fit into the previous buffer (causing assertions). This ensures
that whenever checking for space, we always leave a bit of extra room
for the fence emission commands. Adjusts the nv30 and nvc0 fence
emission logic to bypass the space checking as well.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/nouveau_winsys.h   | 2 ++
 src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
 src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h 
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 389a229..a44fd3e 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -24,6 +24,8 @@ PUSH_AVAIL(struct nouveau_pushbuf *push)
 static inline bool
 PUSH_SPACE(struct nouveau_pushbuf *push, uint32_t size)
 {
+   /* Provide a buffer so that fences always have room to be emitted */
+   size += 8;
if (PUSH_AVAIL(push) < size)
   return nouveau_pushbuf_space(push, size, 0, 0) == 0;
return true;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 39267b3..335c163 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -347,7 +347,9 @@ nv30_screen_fence_emit(struct pipe_screen *pscreen, 
uint32_t *sequence)
 
*sequence = ++screen->base.fence.sequence;
 
-   BEGIN_NV04(push, NV30_3D(FENCE_OFFSET), 2);
+   assert(PUSH_AVAIL(push) >= 3);
+   PUSH_DATA (push, NV30_3D_FENCE_OFFSET |
+  (2 /* size */ << 18) | (7 /* subchan */ << 13));
PUSH_DATA (push, 0);
PUSH_DATA (push, *sequence);
 }
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 6012ff6..812b246 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -388,6 +388,7 @@ nv50_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
/* we need to do it after possible flush in MARK_RING */
*sequence = ++screen->base.fence.sequence;
 
+   assert(PUSH_AVAIL(push) >= 5);
PUSH_DATA (push, NV50_FIFO_PKHDR(NV50_3D(QUERY_ADDRESS_HIGH), 4));
PUSH_DATAh(push, screen->fence.bo->offset);
PUSH_DATA (push, screen->fence.bo->offset);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 32da76c..afd91e6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -537,7 +537,8 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
/* we need to do it after possible flush in MARK_RING */
*sequence = ++screen->base.fence.sequence;
 
-   BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 4);
+   assert(PUSH_AVAIL(push) >= 5);
+   PUSH_DATA (push, NVC0_FIFO_PKHDR_SQ(NVC0_3D(QUERY_ADDRESS_HIGH), 4));
PUSH_DATAh(push, screen->fence.bo->offset);
PUSH_DATA (push, screen->fence.bo->offset);
PUSH_DATA (push, *sequence);
-- 
2.4.9

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

Re: [Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

2015-10-05 Thread Michel Thierry


On 9/14/2015 2:54 PM, Michał Winiarski wrote:

On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:

Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.

In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State Offset
are limited to 32-bits.

The i915 driver has been modified to provide a flag to set when the 4GB
limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
48-bit range will only be used when explicitly requested.

Callers to the existing drm_intel_bo_emit_reloc function should set the
use_48b_address_range flag beforehand, in order to use full ppgtt range.

v2: Make set/clear functions nops on pre-gen8 platforms, and use them
 internally in emit_reloc functions (Ben)
 s/48BADDRESS/48B_ADDRESS/ (Dave)
v3: Keep set/clear functions internal, no-one needs to use them directly.
v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
 before enabling set/clear function, print full offsets in debug
 statements, using port of lower_32_bits and upper_32_bits from linux
 kernel (Michał)

References: 
http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
Cc: Ben Widawsky 
Cc: Michał Winiarski 


+Kristian

LGTM.
Acked-by: Michał Winiarski 


Signed-off-by: Michel Thierry 



Hi Kristian,

More comments on this?
I've resent the mesa patch with the last changes 
(http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).


Michał has agreed with the interface and will use it for his work.
If mesa doesn't plan to use this for now, it's ok. The kernel changes 
have been done to prevent any regressions when the support 48-bit flag 
is not set.


Thanks,

-Michel


---
  include/drm/i915_drm.h|  3 +-
  intel/intel_bufmgr.c  | 11 ++
  intel/intel_bufmgr.h  |  1 +
  intel/intel_bufmgr_gem.c  | 88 +--
  intel/intel_bufmgr_priv.h | 14 
  5 files changed, 97 insertions(+), 20 deletions(-)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..426b25c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
  #define EXEC_OBJECT_NEEDS_GTT (1<<1)
  #define EXEC_OBJECT_WRITE (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
__u64 flags;

__u64 rsvd1;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 14ea9f9..0856e60 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
  }

  int
+drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
+{
+   if (bo->bufmgr->bo_use_48b_address_range) {
+   bo->bufmgr->bo_use_48b_address_range(bo, enable);
+   return 0;
+   }
+
+   return -ENODEV;
+}
+
+int
  drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
  {
return bo->bufmgr->bo_references(bo, target_bo);
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 95eecb8..a14c78f 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * 
tiling_mode,
  int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
  int drm_intel_bo_busy(drm_intel_bo *bo);
  int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
+int drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable);

  int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
  int drm_intel_bo_is_reusable(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2723e21..09d82d2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -83,6 +83,22 @@
  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
  #define MAX2(A, B) ((A) > (B) ? (A) : (B))

+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((__u32)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((__u32)(n))
+
  typedef struct _drm_intel_bo_gem drm_intel_bo_gem;

  struct drm_intel_gem_bo_bucket {
@@ -237,6 +253,15 @@ struct _drm_intel_bo_gem {
bool is_userptr;

/**
+* Boolean of whether this buffer can be placed in

Re: [Mesa-dev] [PATCH] mesa: Add missing _mm_mfence() before streaming loads.

2015-10-05 Thread Jordan Justen

On 2015-10-05 11:55:57, Matt Turner wrote:
> On Thu, Oct 1, 2015 at 11:20 AM, Jordan Justen
>  wrote:
> > On 2015-10-01 10:11:33, Matt Turner wrote:
> >> According to the Intel Software Development Manual:
> >
> > How about a more specific doc location?
> >
> > According to the Intel Software Development Manual (Volume 1: Basic
> > Architecture, 12.10.3 Streaming Load Hint Instruction):
> 
> Sure. Thanks for looking that up for me.
> 
> >>Streaming loads may be weakly ordered and may appear to software to
> >>execute out of order with respect to other memory operations.
> >>Software must explicitly use fences (e.g. MFENCE) if it needs to
> >>preserve order among streaming loads or between streaming loads and
> >>other memory operations.
> >
> > Does this mean we need a mfence following the load as well?
> 
> I didn't think so, and Joseph has confirmed.
> 
> Can I consider this a Reviewed-by?

Reviewed-by: Jordan Justen 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/5] nvc0: split HW/SQ queries in different files

Hi there,

This series splits HW (including MP performance counters) and SW queries in
different files to improve readability of this area of the nvc0 driver.

This also prepares the way for landing global performance counters (PCOUNTER)
in the next few weeks.

I tested this series on Fermi and Kepler and I launched some piglit tests
related to those queries. No regressions.

Feel free to review,
Thanks.

Samuel.

Samuel Pitoiset (5):
  nvc0: add a header file for nvc0_query
  nvc0: move nvc0_so_target_save_offset() to its correct location
  nvc0: move SW queries to nvc0_query_sw.c/h files
  nvc0: move HW queries to nvc0_query_hw.c/h files
  nvc0: move HW SM queries to nvc0_query_hw_sm.c/h files

 src/gallium/drivers/nouveau/Makefile.sources   |7 +
 src/gallium/drivers/nouveau/nvc0/nvc0_context.h|   12 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c  | 1183 +---
 src/gallium/drivers/nouveau/nvc0/nvc0_query.h  |   33 +
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c   |  457 
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h   |  156 +++
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c|  749 +
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.h|   20 +
 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.c   |   92 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.h   |   61 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.h |  144 +--
 .../drivers/nouveau/nvc0/nvc0_shader_state.c   |5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c  |   20 +
 src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c|5 +-
 14 files changed, 1633 insertions(+), 1311 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query.h
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.h
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.h

-- 
2.6.0

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

[Mesa-dev] [Bug 92122] [bisected, cts] Regression with Assault Android Cactus

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

Mark Janes  changed:

   What|Removed |Added

Summary|[bisected] Regression with  |[bisected, cts] Regression
   |Assault Android Cactus  |with Assault Android Cactus

--- Comment #10 from Mark Janes  ---
The bisected commit also breaks OpenGL conformance:

es2-cts.gtf.gl2tests.glgetprogramiv_2_0.glgetprogramiv

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

Re: [Mesa-dev] [RFC] ARB_shader_clock, hardware counters and i965

On Mon, Oct 5, 2015 at 5:36 PM, Emil Velikov  wrote:
> P.S. Does anyone recall the consensus wrt adding the 2015 extensions
> to GL3.txt ?

I think the decision was that the list wouldn't contain any non-core extensions.

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

Re: [Mesa-dev] [Patchwork] The infrequent patchwork update #1

2015-10-05 Thread Timothy Arceri

On Tue, 2015-09-29 at 16:33 +0100, Damien Lespiau wrote:
> Hi all,
> 
> You may have noticed already, patchwork.freedesktop.org looks
> different.
> 
> That new version includes:
>   - Some re-design. Design is very much an iterative process,
> thoughts
> and comments are welcome,
>   - Showing the number of Reviewed-by, Acked-by, Tested-by tags,

Hi Damien,

Just took a look at the new patchwork and I think the improvements are
great :) I really like the above change, makes it really easy to see
how much of a series remains unreviewed.

Also the new patch filters are great too, being find my own patches is
helpful.

Thanks for the improvements.

Tim


>   - Some cleanup of the data base, removing stale registration email
> addresses (mostly bots trying to register) that were showing in
> the
> completion list.
> 
> That's it for the first update. I wanted to keep it small-ish to do
> some
> heavy lifting behind the scenes (latest patchwork, latest django, new
> db
> migration system, virtualenvs, ...)
> 
> One can open issues against the freedesktop version of patchwork (not
> all is upstream just yet, but hopefully on its way there) on github:
> 
>   https://github.com/dlespiau/patchwork/issues
> 
> For administrative tasks (eg. add projects/maintainers), please use
> fdo's bugzilla, product freedeskop.org, component patchwork:
> 
>   https://bugs.freedesktop.org/enter_bug.cgi?product=freedesktop.org
> 
> Future plans include a "series-aware" patchwork with the goal of
> exposing series and revision of series (v2, 3, ..) to the world so
> one
> can hook automatic testing to patchwork, read more at:
> 
>   https://lists.ozlabs.org/pipermail/patchwork/2015-September/001601.
> html
> 
> HTH,
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92286] Distant geometry renders in front of closer geometry (depth test fail) in DarkRadiant / wxWidgets

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

--- Comment #2 from Roland Scheidegger  ---
(In reply to MirceaKitsune from comment #1)
> I guess the question of this bug report remains whether Mesa is doing
> something wrong here. On the proprietary video drivers, it's ok to leave the
> attribs parameter of wxGLCanvas empty... but for depth buffering to work on
> Mesa, you must include WX_GL_DEPTH_SIZE and give it a buffer size.
> 
> So if anyone here is familiar with wxWidgets, please take a look at this. If
> you think Mesa is doing the right thing, this report can be closed. I don't
> know enough to decide that, but to me it feels like depth testing being the
> only thing that doesn't work in this scenario denotes a problem.

I'm not familiar with wxWidgets, but this definitely doesn't sound like a mesa
bug. If you don't explicitly request a visual with depth bits, then you may or
may not get a depth buffer, and it looks like it just happens some proprietary
drivers will give you a visual with it but mesa won't.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 08/23] i965/vs: Fix a subtlety in the nr_attributes == 0 workaround.

2015-10-05 Thread Kenneth Graunke

nr_attributes is used to compute first_non_payload_grf, which is the
first register we're allowed to use for ordinary register allocation.

The hardware requires us to read at least one pair of values, but we're
completely free to overwrite that garbage register with whatever we like.

Instead of altering nr_attributes, we should alter urb_read_length, which
only affects the amount we ask the VF to read.  This should save us a
register in trivial cases (which admittedly isn't very useful).

While we're at it, improve the explanation in the comments.

v2: Actually do what I said (caught by Ilia).

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_vs.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

Ilia pointed out on IRC that my previous version of this patch was totally
bunk - I kept editing nr_attributes, and actually made the SIMD8 case start
using a read length of 1.

Here's one that actually does what I meant.  I verified that it actually
keeps using a URB Read Length of 0 in the SIMD8 VS.  I also verified that
the previous patch doesn't break that either, so I think it's OK after all.


diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index f585f22..677a58f 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -195,14 +195,16 @@ brw_codegen_vs_prog(struct brw_context *brw,
   nr_attributes++;
}
 
-   /* The BSpec says we always have to read at least one thing from the VF,
-* and it appears that the hardware wedges otherwise.
+   /* The 3DSTATE_VS documentation lists the lower bound on "Vertex URB Entry
+* Read Length" as 1 in vec4 mode, and 0 in SIMD8 mode.  Empirically, in
+* vec4 mode, the hardware appears to wedge unless we read something.
 */
-   if (nr_attributes == 0 && !brw->intelScreen->compiler->scalar_vs)
-  nr_attributes = 1;
+   if (brw->intelScreen->compiler->scalar_vs)
+  prog_data.base.urb_read_length = DIV_ROUND_UP(nr_attributes, 2);
+   else
+  prog_data.base.urb_read_length = DIV_ROUND_UP(MAX2(nr_attributes, 1), 2);
 
prog_data.nr_attributes = nr_attributes;
-   prog_data.base.urb_read_length = DIV_ROUND_UP(nr_attributes, 2);
 
/* Since vertex shaders reuse the same VUE entry for inputs and outputs
 * (overwriting the original contents), we need to make sure the size is
-- 
2.5.3

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

Re: [Mesa-dev] [PATCH] glsl: Remove CSE pass.

2015-10-05 Thread Kenneth Graunke

On Saturday, October 03, 2015 10:57:38 AM Matt Turner wrote:
> With NIR, it actually hurts things.
> 
> total instructions in shared programs: 6529329 -> 652 (-0.01%)
> instructions in affected programs: 14833 -> 14392 (-2.97%)
> helped:299
> HURT:  1
> 
> In all affected programs I inspected (including the single hurt one) the
> pass CSE'd some multiplies and caused some reassociation (e.g., caused
> (A * B) * C to be A * (B * C)) when the original intermediate result was
> reused elsewhere.
> ---
>  src/glsl/Makefile.sources   |   1 -
>  src/glsl/glsl_parser_extras.cpp |   1 -
>  src/glsl/ir_optimization.h  |   1 -
>  src/glsl/opt_cse.cpp| 472 
> 
>  4 files changed, 475 deletions(-)
>  delete mode 100644 src/glsl/opt_cse.cpp

FWIW, I'm in favor of removing this pass.
Acked-by: Kenneth Graunke 

In general, I think it makes a lot of sense to introduce a boolean for
"I don't want GLSL IR optimizations, NIR/LLVM/NVC/whatever is going to
take care of that for me later."...and put more and more passes behind
it.

But, this pass has serious problems.  One example is that, given two
large identical expression trees, it will start at the bottom up, and
CSE two operations.  But the new CSE temporaries won't be marked read
only...and the pass bails on non-read-only things.  So it then won't
be able to CSE the rest of the tree.  Shoots itself in the foot.

The other thing is that the primary motivation for the pass was to
optimize repeated texturing with the same coordinates.  The fact that it
only handles constant/read-only coordinates really limits this - who
does repeated texturing with identical *constant* coordinates?  The old
Unigine Tropics demo, of course...but I doubt anybody cares about
running that on old hardware.  (Their newer stuff is more reasonable,
thankfully...)

I'd be in favor of keeping a solid CSE pass behind a flag, but this is
not that.  Let's drop it.

--Ken

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

[Mesa-dev] [PATCH 1/5] nvc0: add a header file for nvc0_query

This will allow to split SW and HW queries in an upcoming patch.

While we are at it, make use of nvc0_query struct instead of pipe_query.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/Makefile.sources   |   1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_context.h|  12 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c  |  37 +---
 src/gallium/drivers/nouveau/nvc0/nvc0_query.h  | 191 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 142 ---
 .../drivers/nouveau/nvc0/nvc0_shader_state.c   |   4 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c|   4 +-
 7 files changed, 202 insertions(+), 189 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query.h

diff --git a/src/gallium/drivers/nouveau/Makefile.sources 
b/src/gallium/drivers/nouveau/Makefile.sources
index 9346ea3..350837c 100644
--- a/src/gallium/drivers/nouveau/Makefile.sources
+++ b/src/gallium/drivers/nouveau/Makefile.sources
@@ -151,6 +151,7 @@ NVC0_C_SOURCES := \
nvc0/nvc0_program.c \
nvc0/nvc0_program.h \
nvc0/nvc0_query.c \
+   nvc0/nvc0_query.h \
nvc0/nvc0_resource.c \
nvc0/nvc0_resource.h \
nvc0/nvc0_screen.c \
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index 30bee3a..4af83c5 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -15,6 +15,7 @@
 #include "nvc0/nvc0_screen.h"
 #include "nvc0/nvc0_program.h"
 #include "nvc0/nvc0_resource.h"
+#include "nvc0/nvc0_query.h"
 
 #include "nv50/nv50_transfer.h"
 
@@ -231,17 +232,6 @@ uint32_t nvc0_program_symbol_offset(const struct 
nvc0_program *,
 uint32_t label);
 void nvc0_program_init_tcp_empty(struct nvc0_context *);
 
-/* nvc0_query.c */
-void nvc0_init_query_functions(struct nvc0_context *);
-void nvc0_query_pushbuf_submit(struct nouveau_pushbuf *,
-   struct pipe_query *, unsigned result_offset);
-void nvc0_query_fifo_wait(struct nouveau_pushbuf *, struct pipe_query *);
-void nvc0_so_target_save_offset(struct pipe_context *,
-struct pipe_stream_output_target *, unsigned i,
-bool *serialize);
-
-#define NVC0_QUERY_TFB_BUFFER_OFFSET (PIPE_QUERY_TYPES + 0)
-
 /* nvc0_shader_state.c */
 void nvc0_vertprog_validate(struct nvc0_context *);
 void nvc0_tctlprog_validate(struct nvc0_context *);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index b13df6a..793425b 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -25,6 +25,8 @@
 #define NVC0_PUSH_EXPLICIT_SPACE_CHECKING
 
 #include "nvc0/nvc0_context.h"
+#include "nvc0/nvc0_query.h"
+
 #include "nv_object.xml.h"
 #include "nvc0/nve4_compute.xml.h"
 #include "nvc0/nvc0_compute.xml.h"
@@ -34,26 +36,6 @@
 #define NVC0_QUERY_STATE_ENDED   2
 #define NVC0_QUERY_STATE_FLUSHED 3
 
-struct nvc0_query {
-   uint32_t *data;
-   uint16_t type;
-   uint16_t index;
-   int8_t ctr[4];
-   uint32_t sequence;
-   struct nouveau_bo *bo;
-   uint32_t base;
-   uint32_t offset; /* base + i * rotate */
-   uint8_t state;
-   bool is64bit;
-   uint8_t rotate;
-   int nesting; /* only used for occlusion queries */
-   union {
-  struct nouveau_mm_allocation *mm;
-  uint64_t value;
-   } u;
-   struct nouveau_fence *fence;
-};
-
 #define NVC0_QUERY_ALLOC_SPACE 256
 
 static boolean nvc0_hw_sm_query_begin(struct nvc0_context *,
@@ -62,12 +44,6 @@ static void nvc0_hw_sm_query_end(struct nvc0_context *, 
struct nvc0_query *);
 static boolean nvc0_hw_sm_query_result(struct nvc0_context *,
struct nvc0_query *, void *, boolean);
 
-static inline struct nvc0_query *
-nvc0_query(struct pipe_query *pipe)
-{
-   return (struct nvc0_query *)pipe;
-}
-
 static bool
 nvc0_query_allocate(struct nvc0_context *nvc0, struct nvc0_query *q, int size)
 {
@@ -523,9 +499,8 @@ nvc0_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
 }
 
 void
-nvc0_query_fifo_wait(struct nouveau_pushbuf *push, struct pipe_query *pq)
+nvc0_query_fifo_wait(struct nouveau_pushbuf *push, struct nvc0_query *q)
 {
-   struct nvc0_query *q = nvc0_query(pq);
unsigned offset = q->offset;
 
if (q->type == PIPE_QUERY_SO_OVERFLOW_PREDICATE) offset += 0x20;
@@ -596,7 +571,7 @@ nvc0_render_condition(struct pipe_context *pipe,
}
 
if (wait)
-  nvc0_query_fifo_wait(push, pq);
+  nvc0_query_fifo_wait(push, q);
 
PUSH_SPACE(push, 7);
PUSH_REFN (push, q->bo, NOUVEAU_BO_GART | NOUVEAU_BO_RD);
@@ -611,10 +586,8 @@ nvc0_render_condition(struct pipe_context *pipe,
 
 void
 nvc0_query_pushbuf_submit(struct nouveau_pushbuf *push,
-  struct pipe_query *pq, unsigned

[Mesa-dev] [PATCH 2/5] nvc0: move nvc0_so_target_save_offset() to its correct location

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 21 -
 src/gallium/drivers/nouveau/nvc0/nvc0_query.h |  3 ---
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 19 +++
 3 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index 793425b..69e9cdb 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -596,27 +596,6 @@ nvc0_query_pushbuf_submit(struct nouveau_pushbuf *push,
 NVC0_IB_ENTRY_1_NO_PREFETCH);
 }
 
-void
-nvc0_so_target_save_offset(struct pipe_context *pipe,
-   struct pipe_stream_output_target *ptarg,
-   unsigned index, bool *serialize)
-{
-   struct nvc0_so_target *targ = nvc0_so_target(ptarg);
-
-   if (*serialize) {
-  *serialize = false;
-  PUSH_SPACE(nvc0_context(pipe)->base.pushbuf, 1);
-  IMMED_NVC0(nvc0_context(pipe)->base.pushbuf, NVC0_3D(SERIALIZE), 0);
-
-  NOUVEAU_DRV_STAT(nouveau_screen(pipe->screen), gpu_serialize_count, 1);
-   }
-
-   nvc0_query(targ->pq)->index = index;
-
-   nvc0_query_end(pipe, targ->pq);
-}
-
-
 /* === DRIVER STATISTICS === */
 
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
index 741ad21..65858cf 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
@@ -184,8 +184,5 @@ void nvc0_init_query_functions(struct nvc0_context *);
 void nvc0_query_pushbuf_submit(struct nouveau_pushbuf *, struct nvc0_query *,
unsigned);
 void nvc0_query_fifo_wait(struct nouveau_pushbuf *, struct nvc0_query *);
-void nvc0_so_target_save_offset(struct pipe_context *,
-struct pipe_stream_output_target *, unsigned,
-bool *);
 
 #endif
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
index c5bfd03..269c75b 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
@@ -1091,6 +1091,25 @@ nvc0_so_target_create(struct pipe_context *pipe,
 }
 
 static void
+nvc0_so_target_save_offset(struct pipe_context *pipe,
+   struct pipe_stream_output_target *ptarg,
+   unsigned index, bool *serialize)
+{
+   struct nvc0_so_target *targ = nvc0_so_target(ptarg);
+
+   if (*serialize) {
+  *serialize = false;
+  PUSH_SPACE(nvc0_context(pipe)->base.pushbuf, 1);
+  IMMED_NVC0(nvc0_context(pipe)->base.pushbuf, NVC0_3D(SERIALIZE), 0);
+
+  NOUVEAU_DRV_STAT(nouveau_screen(pipe->screen), gpu_serialize_count, 1);
+   }
+
+   nvc0_query(targ->pq)->index = index;
+   pipe->end_query(pipe, targ->pq);
+}
+
+static void
 nvc0_so_target_destroy(struct pipe_context *pipe,
struct pipe_stream_output_target *ptarg)
 {
-- 
2.6.0

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

[Mesa-dev] [PATCH 5/5] nvc0: move HW SM queries to nvc0_query_hw_sm.c/h files

Global performance counters (PCOUNTER) will be added to
nvc0_query_hw_pm.c/h files.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/Makefile.sources   |   2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c   | 707 +--
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h   |  14 +-
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 749 +
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.h|  20 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.h |   2 +-
 6 files changed, 803 insertions(+), 691 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.h

diff --git a/src/gallium/drivers/nouveau/Makefile.sources 
b/src/gallium/drivers/nouveau/Makefile.sources
index e45c564..edc6cf4 100644
--- a/src/gallium/drivers/nouveau/Makefile.sources
+++ b/src/gallium/drivers/nouveau/Makefile.sources
@@ -154,6 +154,8 @@ NVC0_C_SOURCES := \
nvc0/nvc0_query.h \
nvc0/nvc0_query_hw.c \
nvc0/nvc0_query_hw.h \
+   nvc0/nvc0_query_hw_sm.c \
+   nvc0/nvc0_query_hw_sm.h \
nvc0/nvc0_query_sw.c \
nvc0/nvc0_query_sw.h \
nvc0/nvc0_resource.c \
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
index f0f9661..1fd5df1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
@@ -25,10 +25,7 @@
 
 #include "nvc0/nvc0_context.h"
 #include "nvc0/nvc0_query_hw.h"
-
-#include "nv_object.xml.h"
-#include "nvc0/nve4_compute.xml.h"
-#include "nvc0/nvc0_compute.xml.h"
+#include "nvc0/nvc0_query_hw_sm.h"
 
 #define NVC0_QUERY_STATE_READY   0
 #define NVC0_QUERY_STATE_ACTIVE  1
@@ -37,632 +34,7 @@
 
 #define NVC0_QUERY_ALLOC_SPACE 256
 
-/* === PERFORMANCE MONITORING COUNTERS for NVE4+ === */
-
-/* Code to read out MP counters: They are accessible via mmio, too, but let's
- * just avoid mapping registers in userspace. We'd have to know which MPs are
- * enabled/present, too, and that information is not presently exposed.
- * We could add a kernel interface for it, but reading the counters like this
- * has the advantage of being async (if get_result isn't called immediately).
- */
-static const uint64_t nve4_read_hw_sm_counters_code[] =
-{
-   /* sched 0x20 0x20 0x20 0x20 0x20 0x20 0x20
-* mov b32 $r8 $tidx
-* mov b32 $r12 $physid
-* mov b32 $r0 $pm0
-* mov b32 $r1 $pm1
-* mov b32 $r2 $pm2
-* mov b32 $r3 $pm3
-* mov b32 $r4 $pm4
-* sched 0x20 0x20 0x23 0x04 0x20 0x04 0x2b
-* mov b32 $r5 $pm5
-* mov b32 $r6 $pm6
-* mov b32 $r7 $pm7
-* set $p0 0x1 eq u32 $r8 0x0
-* mov b32 $r10 c0[0x0]
-* ext u32 $r8 $r12 0x414
-* mov b32 $r11 c0[0x4]
-* sched 0x04 0x2e 0x04 0x20 0x20 0x28 0x04
-* ext u32 $r9 $r12 0x208
-* (not $p0) exit
-* set $p1 0x1 eq u32 $r9 0x0
-* mul $r8 u32 $r8 u32 96
-* mul $r12 u32 $r9 u32 16
-* mul $r13 u32 $r9 u32 4
-* add b32 $r9 $r8 $r13
-* sched 0x28 0x04 0x2c 0x04 0x2c 0x04 0x2c
-* add b32 $r8 $r8 $r12
-* mov b32 $r12 $r10
-* add b32 $r10 $c $r10 $r8
-* mov b32 $r13 $r11
-* add b32 $r11 $r11 0x0 $c
-* add b32 $r12 $c $r12 $r9
-* st b128 wt g[$r10d] $r0q
-* sched 0x4 0x2c 0x20 0x04 0x2e 0x00 0x00
-* mov b32 $r0 c0[0x8]
-* add b32 $r13 $r13 0x0 $c
-* $p1 st b128 wt g[$r12d+0x40] $r4q
-* st b32 wt g[$r12d+0x50] $r0
-* exit */
-   0x2202020202020207ULL,
-   0x2c0084021c04ULL,
-   0x2c000c031c04ULL,
-   0x2c0010001c04ULL,
-   0x2c0014005c04ULL,
-   0x2c0018009c04ULL,
-   0x2c001c00dc04ULL,
-   0x2c0020011c04ULL,
-   0x22b0420042320207ULL,
-   0x2c0024015c04ULL,
-   0x2c0028019c04ULL,
-   0x2c002c01dc04ULL,
-   0x190efc81dc03ULL,
-   0x280040029de4ULL,
-   0x7000c01050c21c03ULL,
-   0x280040001002dde4ULL,
-   0x204282020042e047ULL,
-   0x7000c00820c25c03ULL,
-   0x800021e7ULL,
-   0x190efc93dc03ULL,
-   0x100180821c02ULL,
-   0x100040931c02ULL,
-   0x100010935c02ULL,
-   0x480034825c03ULL,
-   0x22c042c042c04287ULL,
-   0x480030821c03ULL,
-   0x280028031de4ULL,
-   0x480120a29c03ULL,
-   0x28002c035de4ULL,
-   0x08b2dc42ULL,
-   0x480124c31c03ULL,
-   0x94a01fc5ULL,
-   0x22e04202c047ULL,
-   0x2800400020001de4ULL,
-   0x08d35c42ULL,
-   0x940100c107c5ULL,
-   0x940140c01f85ULL,
-   0x80001de7ULL
-};
-
-/* For simplicity, we will allocate as many group slots as we allocate counter
- * slots. This means that a single counter which wants to source from 2 groups
- * will have to be declared as using 2 counter slots. This shouldn't really be
- * a problem because such queries don't make much sense ... (unless someone is
- * really creative).
- */
-struct nvc0_mp_counter_cfg
-{
-   uint32_t func:

[Mesa-dev] [PATCH 4/5] nvc0: move HW queries to nvc0_query_hw.c/h files

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/Makefile.sources   |2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c  | 1122 +--
 src/gallium/drivers/nouveau/nvc0/nvc0_query.h  |  121 ---
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c   | 1128 
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h   |  144 +++
 .../drivers/nouveau/nvc0/nvc0_shader_state.c   |5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c  |1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c|5 +-
 8 files changed, 1308 insertions(+), 1220 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h

diff --git a/src/gallium/drivers/nouveau/Makefile.sources 
b/src/gallium/drivers/nouveau/Makefile.sources
index 0e1cb19..e45c564 100644
--- a/src/gallium/drivers/nouveau/Makefile.sources
+++ b/src/gallium/drivers/nouveau/Makefile.sources
@@ -152,6 +152,8 @@ NVC0_C_SOURCES := \
nvc0/nvc0_program.h \
nvc0/nvc0_query.c \
nvc0/nvc0_query.h \
+   nvc0/nvc0_query_hw.c \
+   nvc0/nvc0_query_hw.h \
nvc0/nvc0_query_sw.c \
nvc0/nvc0_query_sw.h \
nvc0/nvc0_resource.c \
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index 349140c..2f78358 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -27,485 +27,48 @@
 #include "nvc0/nvc0_context.h"
 #include "nvc0/nvc0_query.h"
 #include "nvc0/nvc0_query_sw.h"
-
-#include "nv_object.xml.h"
-#include "nvc0/nve4_compute.xml.h"
-#include "nvc0/nvc0_compute.xml.h"
-
-#define NVC0_QUERY_STATE_READY   0
-#define NVC0_QUERY_STATE_ACTIVE  1
-#define NVC0_QUERY_STATE_ENDED   2
-#define NVC0_QUERY_STATE_FLUSHED 3
-
-#define NVC0_QUERY_ALLOC_SPACE 256
-
-static boolean nvc0_hw_sm_query_begin(struct nvc0_context *,
-  struct nvc0_query *);
-static void nvc0_hw_sm_query_end(struct nvc0_context *, struct nvc0_query *);
-static boolean nvc0_hw_sm_query_result(struct nvc0_context *,
-   struct nvc0_query *, void *, boolean);
-
-static bool
-nvc0_query_allocate(struct nvc0_context *nvc0, struct nvc0_query *q, int size)
-{
-   struct nvc0_screen *screen = nvc0->screen;
-   int ret;
-
-   if (q->bo) {
-  nouveau_bo_ref(NULL, >bo);
-  if (q->mm) {
- if (q->state == NVC0_QUERY_STATE_READY)
-nouveau_mm_free(q->mm);
- else
-nouveau_fence_work(screen->base.fence.current,
-   nouveau_mm_free_work, q->mm);
-  }
-   }
-   if (size) {
-  q->mm = nouveau_mm_allocate(screen->base.mm_GART, size, >bo, 
>base);
-  if (!q->bo)
- return false;
-  q->offset = q->base;
-
-  ret = nouveau_bo_map(q->bo, 0, screen->base.client);
-  if (ret) {
- nvc0_query_allocate(nvc0, q, 0);
- return false;
-  }
-  q->data = (uint32_t *)((uint8_t *)q->bo->map + q->base);
-   }
-   return true;
-}
-
-static void
-nvc0_query_destroy(struct pipe_context *pipe, struct pipe_query *pq)
-{
-   nvc0_query_allocate(nvc0_context(pipe), nvc0_query(pq), 0);
-   nouveau_fence_ref(NULL, _query(pq)->fence);
-   FREE(nvc0_query(pq));
-}
+#include "nvc0/nvc0_query_hw.h"
 
 static struct pipe_query *
-nvc0_query_create(struct pipe_context *pipe, unsigned type, unsigned index)
+nvc0_create_query(struct pipe_context *pipe, unsigned type, unsigned index)
 {
struct nvc0_context *nvc0 = nvc0_context(pipe);
struct nvc0_query *q;
-   unsigned space = NVC0_QUERY_ALLOC_SPACE;
 
q = nvc0_sw_create_query(nvc0, type, index);
-   if (q)
-  return (struct pipe_query *)q;
-
-   q = CALLOC_STRUCT(nvc0_query);
if (!q)
-  return NULL;
-
-   switch (type) {
-   case PIPE_QUERY_OCCLUSION_COUNTER:
-   case PIPE_QUERY_OCCLUSION_PREDICATE:
-  q->rotate = 32;
-  space = NVC0_QUERY_ALLOC_SPACE;
-  break;
-   case PIPE_QUERY_PIPELINE_STATISTICS:
-  q->is64bit = true;
-  space = 512;
-  break;
-   case PIPE_QUERY_SO_STATISTICS:
-   case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
-  q->is64bit = true;
-  space = 64;
-  break;
-   case PIPE_QUERY_PRIMITIVES_GENERATED:
-   case PIPE_QUERY_PRIMITIVES_EMITTED:
-  q->is64bit = true;
-  q->index = index;
-  space = 32;
-  break;
-   case PIPE_QUERY_TIME_ELAPSED:
-   case PIPE_QUERY_TIMESTAMP:
-   case PIPE_QUERY_TIMESTAMP_DISJOINT:
-   case PIPE_QUERY_GPU_FINISHED:
-  space = 32;
-  break;
-   case NVC0_QUERY_TFB_BUFFER_OFFSET:
-  space = 16;
-  break;
-   default:
-  if (nvc0->screen->base.device->drm_version >= 0x01000101) {
- if (type >= NVE4_HW_SM_QUERY(0) && type <= NVE4_HW_SM_QUERY_LAST) {
-/* for each MP:
- * [00] = WS0.C0
- * [04] = WS0.C1
-

[Mesa-dev] [PATCH 3/5] nvc0: move SW queries to nvc0_query_sw.c/h files

Loosely based on freedreno driver.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/Makefile.sources |  2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c| 31 
 src/gallium/drivers/nouveau/nvc0/nvc0_query.h| 56 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.c | 92 
 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.h | 61 
 5 files changed, 178 insertions(+), 64 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.c
 create mode 100644 src/gallium/drivers/nouveau/nvc0/nvc0_query_sw.h

diff --git a/src/gallium/drivers/nouveau/Makefile.sources 
b/src/gallium/drivers/nouveau/Makefile.sources
index 350837c..0e1cb19 100644
--- a/src/gallium/drivers/nouveau/Makefile.sources
+++ b/src/gallium/drivers/nouveau/Makefile.sources
@@ -152,6 +152,8 @@ NVC0_C_SOURCES := \
nvc0/nvc0_program.h \
nvc0/nvc0_query.c \
nvc0/nvc0_query.h \
+   nvc0/nvc0_query_sw.c \
+   nvc0/nvc0_query_sw.h \
nvc0/nvc0_resource.c \
nvc0/nvc0_resource.h \
nvc0/nvc0_screen.c \
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index 69e9cdb..349140c 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -26,6 +26,7 @@
 
 #include "nvc0/nvc0_context.h"
 #include "nvc0/nvc0_query.h"
+#include "nvc0/nvc0_query_sw.h"
 
 #include "nv_object.xml.h"
 #include "nvc0/nve4_compute.xml.h"
@@ -52,16 +53,16 @@ nvc0_query_allocate(struct nvc0_context *nvc0, struct 
nvc0_query *q, int size)
 
if (q->bo) {
   nouveau_bo_ref(NULL, >bo);
-  if (q->u.mm) {
+  if (q->mm) {
  if (q->state == NVC0_QUERY_STATE_READY)
-nouveau_mm_free(q->u.mm);
+nouveau_mm_free(q->mm);
  else
 nouveau_fence_work(screen->base.fence.current,
-   nouveau_mm_free_work, q->u.mm);
+   nouveau_mm_free_work, q->mm);
   }
}
if (size) {
-  q->u.mm = nouveau_mm_allocate(screen->base.mm_GART, size, >bo, 
>base);
+  q->mm = nouveau_mm_allocate(screen->base.mm_GART, size, >bo, 
>base);
   if (!q->bo)
  return false;
   q->offset = q->base;
@@ -91,6 +92,10 @@ nvc0_query_create(struct pipe_context *pipe, unsigned type, 
unsigned index)
struct nvc0_query *q;
unsigned space = NVC0_QUERY_ALLOC_SPACE;
 
+   q = nvc0_sw_create_query(nvc0, type, index);
+   if (q)
+  return (struct pipe_query *)q;
+
q = CALLOC_STRUCT(nvc0_query);
if (!q)
   return NULL;
@@ -126,14 +131,6 @@ nvc0_query_create(struct pipe_context *pipe, unsigned 
type, unsigned index)
   space = 16;
   break;
default:
-#ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
-  if (type >= NVC0_QUERY_DRV_STAT(0) && type <= NVC0_QUERY_DRV_STAT_LAST) {
- space = 0;
- q->is64bit = true;
- q->index = type - NVC0_QUERY_DRV_STAT(0);
- break;
-  } else
-#endif
   if (nvc0->screen->base.device->drm_version >= 0x01000101) {
  if (type >= NVE4_HW_SM_QUERY(0) && type <= NVE4_HW_SM_QUERY_LAST) {
 /* for each MP:
@@ -297,10 +294,7 @@ nvc0_query_begin(struct pipe_context *pipe, struct 
pipe_query *pq)
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
   if (q->type >= NVC0_QUERY_DRV_STAT(0) &&
   q->type <= NVC0_QUERY_DRV_STAT_LAST) {
- if (q->index >= 5)
-q->u.value = nvc0->screen->base.stats.v[q->index];
- else
-q->u.value = 0;
+ return q->funcs->begin_query(nvc0, q);
   } else
 #endif
   if ((q->type >= NVE4_HW_SM_QUERY(0) && q->type <= NVE4_HW_SM_QUERY_LAST) 
||
@@ -384,7 +378,7 @@ nvc0_query_end(struct pipe_context *pipe, struct pipe_query 
*pq)
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
   if (q->type >= NVC0_QUERY_DRV_STAT(0) &&
   q->type <= NVC0_QUERY_DRV_STAT_LAST) {
- q->u.value = nvc0->screen->base.stats.v[q->index] - q->u.value;
+ q->funcs->end_query(nvc0, q);
  return;
   } else
 #endif
@@ -425,8 +419,7 @@ nvc0_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
if (q->type >= NVC0_QUERY_DRV_STAT(0) &&
q->type <= NVC0_QUERY_DRV_STAT_LAST) {
-  res64[0] = q->u.value;
-  return true;
+  return q->funcs->get_query_result(nvc0, q, wait, result);
} else
 #endif
if ((q->type >= NVE4_HW_SM_QUERY(0) && q->type <= NVE4_HW_SM_QUERY_LAST) ||
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
index 65858cf..c37c80f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.h
@@ -9,8 +9,18 @@
 #define NVC0_QUERY_TFB_BUFFER_OFFSET (PIPE_QUERY_TYPES + 0)
 
 struct nvc0_context;
+struct nvc0_query;
+
+struct nvc0_query_funcs

Re: [Mesa-dev] [Nouveau] [PATCH] nouveau: make sure there's always room to emit a fence


Reviewed-by: Samuel Pitoiset 

On 10/05/2015 09:21 PM, Ilia Mirkin wrote:

I started seeing a lot of situations on nv30 where fence emission
wouldn't fit into the previous buffer (causing assertions). This ensures
that whenever checking for space, we always leave a bit of extra room
for the fence emission commands. Adjusts the nv30 and nvc0 fence
emission logic to bypass the space checking as well.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
  src/gallium/drivers/nouveau/nouveau_winsys.h   | 2 ++
  src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
  src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
  4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h 
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 389a229..a44fd3e 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -24,6 +24,8 @@ PUSH_AVAIL(struct nouveau_pushbuf *push)
  static inline bool
  PUSH_SPACE(struct nouveau_pushbuf *push, uint32_t size)
  {
+   /* Provide a buffer so that fences always have room to be emitted */
+   size += 8;
 if (PUSH_AVAIL(push) < size)
return nouveau_pushbuf_space(push, size, 0, 0) == 0;
 return true;
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 39267b3..335c163 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -347,7 +347,9 @@ nv30_screen_fence_emit(struct pipe_screen *pscreen, 
uint32_t *sequence)
  
 *sequence = ++screen->base.fence.sequence;
  
-   BEGIN_NV04(push, NV30_3D(FENCE_OFFSET), 2);

+   assert(PUSH_AVAIL(push) >= 3);
+   PUSH_DATA (push, NV30_3D_FENCE_OFFSET |
+  (2 /* size */ << 18) | (7 /* subchan */ << 13));


Is there some other places where we do something like this?
If so, maybe we should introduce NV30_FIFO_PKHDR_SQ.


 PUSH_DATA (push, 0);
 PUSH_DATA (push, *sequence);
  }
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 6012ff6..812b246 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -388,6 +388,7 @@ nv50_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
 /* we need to do it after possible flush in MARK_RING */
 *sequence = ++screen->base.fence.sequence;
  
+   assert(PUSH_AVAIL(push) >= 5);

 PUSH_DATA (push, NV50_FIFO_PKHDR(NV50_3D(QUERY_ADDRESS_HIGH), 4));
 PUSH_DATAh(push, screen->fence.bo->offset);
 PUSH_DATA (push, screen->fence.bo->offset);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 32da76c..afd91e6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -537,7 +537,8 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 
*sequence)
 /* we need to do it after possible flush in MARK_RING */
 *sequence = ++screen->base.fence.sequence;
  
-   BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 4);

+   assert(PUSH_AVAIL(push) >= 5);
+   PUSH_DATA (push, NVC0_FIFO_PKHDR_SQ(NVC0_3D(QUERY_ADDRESS_HIGH), 4));
 PUSH_DATAh(push, screen->fence.bo->offset);
 PUSH_DATA (push, screen->fence.bo->offset);
 PUSH_DATA (push, *sequence);


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

[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1

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

Pekka Paalanen  changed:

   What|Removed |Added

 CC||four...@xfce.org

--- Comment #6 from Pekka Paalanen  ---
*** Bug 92247 has been marked as a duplicate of this bug. ***

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1

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

Pekka Paalanen  changed:

   What|Removed |Added

 CC||ppaala...@gmail.com

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

[Mesa-dev] [PATCH] i965: Make vec4_visitor's destructor virtual

2015-10-05 Thread Iago Toral Quiroga

We need a virtual destructor when at least one of the class' methods is virtual.
Failure to do so leads to undefined behavior when destructing derived classes.
Fixes the following warning:

brw_vec4_gs_visitor.cpp: In function 'const unsigned int* 
brw::brw_gs_emit(brw_context*, gl_shader_program*, brw_gs_compile*, void*, 
unsigned int*)':
brw_vec4_gs_visitor.cpp:703:11: warning: deleting object of polymorphic class 
type 'brw::vec4_gs_visitor' which has non-virtual destructor might cause 
undefined behaviour [-Wdelete-non-virtual-dtor]
delete gs;
---
 src/mesa/drivers/dri/i965/brw_vec4.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index d1fa095..5e3500c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -76,7 +76,7 @@ public:
void *mem_ctx,
 bool no_spills,
 int shader_time_index);
-   ~vec4_visitor();
+   virtual ~vec4_visitor();
 
dst_reg dst_null_f()
{
-- 
1.9.1

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

[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1

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

--- Comment #7 from Pekka Paalanen  ---
I don't think you mean GL_EXT_abgr, I don't see Weston using that.

Weston is using GL_BGRA_EXT format, when GL_EXT_texture_format_BGRA
extension is available. Weston's GL-renderer refuses to start without this
extension.

I believe this is because GL_BGRA_EXT, GL_UNSIGNED_BYTE matches the
WL_SHM_FORMAT_XRGB and WL_SHM_FORMAT_ARGB layouts, so we can avoid a
conversion.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] mesa: fix GetProgramiv/GetActiveAttrib regression

Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings
as part of program resource list. We need to take this to account with
all functions dealing with active input attributes.

Patch fixes the issue by adding additional check to is_active_attrib
and iterating only active attribs (not any inputs) explicitly in
GetActiveAttrib function.

I've tested that fix works for Assault Android Cactus (demo version)
and does not cause Piglit or CTS regressions in glGetProgramiv tests.

v2: simplify and optimize with help of is_packed_varying bit

Signed-off-by: Tapani Pälli 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122
---
 src/mesa/main/shader_query.cpp | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 7189676..6d54e61 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -108,7 +108,8 @@ is_active_attrib(const ir_variable *var)
 
switch (var->data.mode) {
case ir_var_shader_in:
-  return var->data.location != -1;
+  return var->data.location != -1 &&
+ !var->data.is_packed_varying;
 
case ir_var_system_value:
   /* From GL 4.3 core spec, section 11.1.1 (Vertex Attributes):
@@ -153,12 +154,18 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint 
desired_index,
   return;
}
 
-   struct gl_program_resource *res =
-  _mesa_program_resource_find_index(shProg, GL_PROGRAM_INPUT,
-desired_index);
+   struct gl_program_resource *res = shProg->ProgramResourceList;
+   unsigned index = -1;
+   for (unsigned i = 0; i < shProg->NumProgramResourceList; i++, res++) {
+  if (res->Type != GL_PROGRAM_INPUT ||
+  !is_active_attrib(RESOURCE_VAR(res)))
+ continue;
+  if (++index == desired_index)
+ break;
+   }
 
/* User asked for index that does not exist. */
-   if (!res) {
+   if (!res || index != desired_index) {
   _mesa_error(ctx, GL_INVALID_VALUE, "glGetActiveAttrib(index)");
   return;
}
@@ -270,7 +277,8 @@ _mesa_longest_attribute_name_length(struct 
gl_shader_program *shProg)
size_t longest = 0;
for (unsigned j = 0; j < shProg->NumProgramResourceList; j++, res++) {
   if (res->Type == GL_PROGRAM_INPUT &&
-  res->StageReferences & (1 << MESA_SHADER_VERTEX)) {
+  res->StageReferences & (1 << MESA_SHADER_VERTEX) &&
+  is_active_attrib(RESOURCE_VAR(res))) {
 
   const size_t length = strlen(RESOURCE_VAR(res)->name);
   if (length >= longest)
-- 
2.4.3

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

[Mesa-dev] [PATCH 1/2] glsl: mark packed varyings during lower_packed_varyings

This makes it easier and faster to identify a packed varying in
shader queries.

Signed-off-by: Tapani Pälli 
---
 src/glsl/ir.h  | 5 +
 src/glsl/lower_packed_varyings.cpp | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 43a2bf0..d33d67e 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -791,6 +791,11 @@ public:
*/
   unsigned from_ssbo_unsized_array:1; /**< unsized array buffer variable. 
*/
 
+  /** If set, variable is packed along with other variables in a
+   * single varying slot.
+   */
+  unsigned is_packed_varying:1;
+
   /**
* Emit a warning if this variable is accessed.
*/
diff --git a/src/glsl/lower_packed_varyings.cpp 
b/src/glsl/lower_packed_varyings.cpp
index 5d66ca9..79b6d0e 100644
--- a/src/glsl/lower_packed_varyings.cpp
+++ b/src/glsl/lower_packed_varyings.cpp
@@ -278,6 +278,8 @@ lower_packed_varyings_visitor::run(struct gl_shader *shader)
   if (!shader->packed_varyings)
  shader->packed_varyings = new (shader) exec_list;
 
+  var->data.is_packed_varying = 1;
+
   shader->packed_varyings->push_tail(var->clone(shader, NULL));
 
   /* Change the old varying into an ordinary global. */
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH 2/2] mesa: fix GetProgramiv/GetActiveAttrib regression

2015-10-05 Thread Ilia Mirkin

On Mon, Oct 5, 2015 at 3:14 AM, Tapani Pälli  wrote:
> Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings
> as part of program resource list. We need to take this to account with
> all functions dealing with active input attributes.

Don't you have this same problem with output attributes as well? Is
the situation here that the packed varying pass adds its own varyings
on top of the usual ones, and so things were getting (essentially)
double-counted?

>
> Patch fixes the issue by adding additional check to is_active_attrib
> and iterating only active attribs (not any inputs) explicitly in
> GetActiveAttrib function.
>
> I've tested that fix works for Assault Android Cactus (demo version)
> and does not cause Piglit or CTS regressions in glGetProgramiv tests.
>
> v2: simplify and optimize with help of is_packed_varying bit
>
> Signed-off-by: Tapani Pälli 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122
> ---
>  src/mesa/main/shader_query.cpp | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index 7189676..6d54e61 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -108,7 +108,8 @@ is_active_attrib(const ir_variable *var)
>
> switch (var->data.mode) {
> case ir_var_shader_in:
> -  return var->data.location != -1;
> +  return var->data.location != -1 &&
> + !var->data.is_packed_varying;
>
> case ir_var_system_value:
>/* From GL 4.3 core spec, section 11.1.1 (Vertex Attributes):
> @@ -153,12 +154,18 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint 
> desired_index,
>return;
> }
>
> -   struct gl_program_resource *res =
> -  _mesa_program_resource_find_index(shProg, GL_PROGRAM_INPUT,
> -desired_index);
> +   struct gl_program_resource *res = shProg->ProgramResourceList;
> +   unsigned index = -1;
> +   for (unsigned i = 0; i < shProg->NumProgramResourceList; i++, res++) {
> +  if (res->Type != GL_PROGRAM_INPUT ||
> +  !is_active_attrib(RESOURCE_VAR(res)))
> + continue;
> +  if (++index == desired_index)
> + break;
> +   }
>
> /* User asked for index that does not exist. */
> -   if (!res) {
> +   if (!res || index != desired_index) {
>_mesa_error(ctx, GL_INVALID_VALUE, "glGetActiveAttrib(index)");
>return;
> }
> @@ -270,7 +277,8 @@ _mesa_longest_attribute_name_length(struct 
> gl_shader_program *shProg)
> size_t longest = 0;
> for (unsigned j = 0; j < shProg->NumProgramResourceList; j++, res++) {
>if (res->Type == GL_PROGRAM_INPUT &&
> -  res->StageReferences & (1 << MESA_SHADER_VERTEX)) {
> +  res->StageReferences & (1 << MESA_SHADER_VERTEX) &&
> +  is_active_attrib(RESOURCE_VAR(res))) {
>
>const size_t length = strlen(RESOURCE_VAR(res)->name);
>if (length >= longest)
> --
> 2.4.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: fix GetProgramiv/GetActiveAttrib regression




On 10/05/2015 10:21 AM, Ilia Mirkin wrote:

On Mon, Oct 5, 2015 at 3:14 AM, Tapani Pälli  wrote:

Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings
as part of program resource list. We need to take this to account with
all functions dealing with active input attributes.


Don't you have this same problem with output attributes as well? Is
the situation here that the packed varying pass adds its own varyings
on top of the usual ones, and so things were getting (essentially)
double-counted?


As far as I see the problem is only with active attribute variables, 
glGetActiveAttrib used to take in to account all resources with input 
type (as it was just calling _mesa_program_resource_find_index). Now it 
explicitly checks that varyings are not counted as active attribute 
variables.


For querying outputs via program resource queries I don't see any 
regressions on the current tests so I'm not convinced there is such problem.


For fragment shader outputs there is a problem but I consider it 
separate from this. Mesa lowers fragment output array as series of 
variables like 'gl_out_FragData0, gl_out_FragData1 ..' while user 
expects there to be 'array[0], array[1] ..' and query for array[0] does 
not match gl_out_FragData0. This one I was planning to tackle next.





Patch fixes the issue by adding additional check to is_active_attrib
and iterating only active attribs (not any inputs) explicitly in
GetActiveAttrib function.

I've tested that fix works for Assault Android Cactus (demo version)
and does not cause Piglit or CTS regressions in glGetProgramiv tests.

v2: simplify and optimize with help of is_packed_varying bit

Signed-off-by: Tapani Pälli 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122
---
  src/mesa/main/shader_query.cpp | 20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 7189676..6d54e61 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -108,7 +108,8 @@ is_active_attrib(const ir_variable *var)

 switch (var->data.mode) {
 case ir_var_shader_in:
-  return var->data.location != -1;
+  return var->data.location != -1 &&
+ !var->data.is_packed_varying;

 case ir_var_system_value:
/* From GL 4.3 core spec, section 11.1.1 (Vertex Attributes):
@@ -153,12 +154,18 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint 
desired_index,
return;
 }

-   struct gl_program_resource *res =
-  _mesa_program_resource_find_index(shProg, GL_PROGRAM_INPUT,
-desired_index);
+   struct gl_program_resource *res = shProg->ProgramResourceList;
+   unsigned index = -1;
+   for (unsigned i = 0; i < shProg->NumProgramResourceList; i++, res++) {
+  if (res->Type != GL_PROGRAM_INPUT ||
+  !is_active_attrib(RESOURCE_VAR(res)))
+ continue;
+  if (++index == desired_index)
+ break;
+   }

 /* User asked for index that does not exist. */
-   if (!res) {
+   if (!res || index != desired_index) {
_mesa_error(ctx, GL_INVALID_VALUE, "glGetActiveAttrib(index)");
return;
 }
@@ -270,7 +277,8 @@ _mesa_longest_attribute_name_length(struct 
gl_shader_program *shProg)
 size_t longest = 0;
 for (unsigned j = 0; j < shProg->NumProgramResourceList; j++, res++) {
if (res->Type == GL_PROGRAM_INPUT &&
-  res->StageReferences & (1 << MESA_SHADER_VERTEX)) {
+  res->StageReferences & (1 << MESA_SHADER_VERTEX) &&
+  is_active_attrib(RESOURCE_VAR(res))) {

const size_t length = strlen(RESOURCE_VAR(res)->name);
if (length >= longest)
--
2.4.3


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

Re: [Mesa-dev] [PATCH 2/2] mesa: fix GetProgramiv/GetActiveAttrib regression

2015-10-05 Thread Ilia Mirkin

On Mon, Oct 5, 2015 at 3:33 AM, Tapani Pälli  wrote:
>
>
> On 10/05/2015 10:21 AM, Ilia Mirkin wrote:
>>
>> On Mon, Oct 5, 2015 at 3:14 AM, Tapani Pälli 
>> wrote:
>>>
>>> Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings
>>> as part of program resource list. We need to take this to account with
>>> all functions dealing with active input attributes.
>>
>>
>> Don't you have this same problem with output attributes as well? Is
>> the situation here that the packed varying pass adds its own varyings
>> on top of the usual ones, and so things were getting (essentially)
>> double-counted?
>
>
> As far as I see the problem is only with active attribute variables,
> glGetActiveAttrib used to take in to account all resources with input type
> (as it was just calling _mesa_program_resource_find_index). Now it
> explicitly checks that varyings are not counted as active attribute
> variables.
>
> For querying outputs via program resource queries I don't see any
> regressions on the current tests so I'm not convinced there is such problem.
>
> For fragment shader outputs there is a problem but I consider it separate
> from this. Mesa lowers fragment output array as series of variables like
> 'gl_out_FragData0, gl_out_FragData1 ..' while user expects there to be
> 'array[0], array[1] ..' and query for array[0] does not match
> gl_out_FragData0. This one I was planning to tackle next.

Oh, well fragment shader outputs don't get packed, so that's not an
issue. There's no way to query the inter-stage stuff? Then what does
this have to do with packing in the first place? Not like vertex
attributes can get packed either...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: fix GetProgramiv/GetActiveAttrib regression




On 10/05/2015 10:38 AM, Ilia Mirkin wrote:

On Mon, Oct 5, 2015 at 3:33 AM, Tapani Pälli  wrote:



On 10/05/2015 10:21 AM, Ilia Mirkin wrote:


On Mon, Oct 5, 2015 at 3:14 AM, Tapani Pälli 
wrote:


Commit 4639cea2921669527eb43dcb49724c05afb27e8e added packed varyings
as part of program resource list. We need to take this to account with
all functions dealing with active input attributes.



Don't you have this same problem with output attributes as well? Is
the situation here that the packed varying pass adds its own varyings
on top of the usual ones, and so things were getting (essentially)
double-counted?



As far as I see the problem is only with active attribute variables,
glGetActiveAttrib used to take in to account all resources with input type
(as it was just calling _mesa_program_resource_find_index). Now it
explicitly checks that varyings are not counted as active attribute
variables.

For querying outputs via program resource queries I don't see any
regressions on the current tests so I'm not convinced there is such problem.

For fragment shader outputs there is a problem but I consider it separate
from this. Mesa lowers fragment output array as series of variables like
'gl_out_FragData0, gl_out_FragData1 ..' while user expects there to be
'array[0], array[1] ..' and query for array[0] does not match
gl_out_FragData0. This one I was planning to tackle next.


Oh, well fragment shader outputs don't get packed, so that's not an
issue. There's no way to query the inter-stage stuff? Then what does
this have to do with packing in the first place? Not like vertex
attributes can get packed either...


There exists issue with fragment shader outputs but it is separate (like 
I mentioned above).


This patch and problem is about input attributes, previous version of 
the query for these was stepping over all available inputs in resource 
list including those varyings that are inputs for output shader stage. I 
hope this clears the issue (?)


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

Re: [Mesa-dev] [PATCH v2] nir: split SSBO min/max atomic instrinsics into signed/unsigned versions

2015-10-05 Thread Iago Toral

Hi Markus,

I noticed that you did not reply to mesa-dev in your original e-mail so
I am CCing the list now so we keep the discussion here.

On Mon, 2015-10-05 at 08:07 +0200, Iago Toral wrote:
> Hi Markus,
> 
> On Sun, 2015-10-04 at 18:15 +0200, Markus Wick wrote:
> > Hi Iago,
> > 
> > I've tried your SSBO patch with splitted signed / unsigned handling with 
> > dolphin-emu and it did work fine, so feel free to add
> > Tested-by: Markus Wick 
> 
> Thanks!
> 
> > But I have another issue with SSBO on master. I get "First argument to 
> > atomic function must be a buffer variable" because of this code: "buffer 
> > {ivec4 a;} ; ... atomicMax(a[0], 0); ...".
> 
> 
> 
> > Ilia has told me on #dri-devel about having the same issue with 
> > tesselation:
> > imirkin_> the second issue sounds fun though... we had issues like that 
> > with tess for a while
> > imirkin_> probably the same helpers can be reused to peer through the 
> > swizzles
> > 
> > Do you know a way how to fix it?
> 
> I'll look into it and reply here with my findings (or a patch). Thanks
> for reporting it!
> 
> Iago
> 
> > Thanks
> > 
> > Markus - degasus
> > 
> 


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

Re: [Mesa-dev] [PATCH 1/3] i965/fs: Remove SNB embedded-comparison support from optimizations.

2015-10-05 Thread Jason Ekstrand

Series is

Reviewed-by: Jason Ekstrand 

On Sat, Oct 3, 2015 at 10:58 AM, Matt Turner  wrote:
> We never emit IF instructions with an embedded comparison (lost in the
> switch to NIR), so this code is not used. If we want to readd support,
> we should have a pass that merges a CMP instruction with an IF or a
> WHILE instruction after other optimizations have run.
> ---
>  .../dri/i965/brw_fs_peephole_predicated_break.cpp   | 14 ++
>  src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp   | 21 
> +
>  2 files changed, 3 insertions(+), 32 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
> index b75f40b..8f7bd83 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
> @@ -83,18 +83,8 @@ fs_visitor::opt_peephole_predicated_break()
>bblock_t *if_block = jump_block->prev();
>bblock_t *endif_block = jump_block->next();
>
> -  /* For Sandybridge with IF with embedded comparison we need to emit an
> -   * instruction to set the flag register.
> -   */
> -  if (devinfo->gen == 6 && if_inst->conditional_mod) {
> - const fs_builder ibld(this, if_block, if_inst);
> - ibld.CMP(ibld.null_reg_d(), if_inst->src[0], if_inst->src[1],
> -  if_inst->conditional_mod);
> - jump_inst->predicate = BRW_PREDICATE_NORMAL;
> -  } else {
> - jump_inst->predicate = if_inst->predicate;
> - jump_inst->predicate_inverse = if_inst->predicate_inverse;
> -  }
> +  jump_inst->predicate = if_inst->predicate;
> +  jump_inst->predicate_inverse = if_inst->predicate_inverse;
>
>bblock_t *earlier_block = if_block;
>if (if_block->start_ip == if_block->end_ip) {
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
> index d190d8e..8613725 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
> @@ -155,18 +155,6 @@ fs_visitor::opt_peephole_sel()
>if (movs == 0)
>   continue;
>
> -  enum brw_predicate predicate;
> -  bool predicate_inverse;
> -  if (devinfo->gen == 6 && if_inst->conditional_mod) {
> - /* For Sandybridge with IF with embedded comparison */
> - predicate = BRW_PREDICATE_NORMAL;
> - predicate_inverse = false;
> -  } else {
> - /* Separate CMP and IF instructions */
> - predicate = if_inst->predicate;
> - predicate_inverse = if_inst->predicate_inverse;
> -  }
> -
>/* Generate SEL instructions for pairs of MOVs to a common 
> destination. */
>for (int i = 0; i < movs; i++) {
>   if (!then_mov[i] || !else_mov[i])
> @@ -195,13 +183,6 @@ fs_visitor::opt_peephole_sel()
>if (movs == 0)
>   continue;
>
> -  /* Emit a CMP if our IF used the embedded comparison */
> -  if (devinfo->gen == 6 && if_inst->conditional_mod) {
> - const fs_builder ibld(this, block, if_inst);
> - ibld.CMP(ibld.null_reg_d(), if_inst->src[0], if_inst->src[1],
> -  if_inst->conditional_mod);
> -  }
> -
>for (int i = 0; i < movs; i++) {
>   const fs_builder ibld = fs_builder(this, then_block, then_mov[i])
>   .at(block, if_inst);
> @@ -220,7 +201,7 @@ fs_visitor::opt_peephole_sel()
> ibld.MOV(src0, then_mov[i]->src[0]);
>  }
>
> -set_predicate_inv(predicate, predicate_inverse,
> +set_predicate_inv(if_inst->predicate, if_inst->predicate_inverse,
>ibld.SEL(then_mov[i]->dst, src0,
> else_mov[i]->src[0]));
>   }
> --
> 2.4.9
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Fix variable_referenced() for vector_{extract, insert} expressions

2015-10-05 Thread Iago Toral Quiroga

We get these when we operate on vector variables with array accessors
(i.e. things like a[0] where 'a' is a vec4). When we call variable_referenced()
on these expressions we want to return a reference to 'a' instead of NULL.

This fixes a problem where we pass a[0] as the first argument to an atomic
SSBO function that expects a buffer variable. In order to check this, we use
variable_referenced(), but that is currently returning NULL in this case, since
the underlying rvalue is a vector_extract expression.
---
 src/glsl/ir.cpp | 16 
 src/glsl/ir.h   |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 2c45b9e..4c22843 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -662,6 +662,22 @@ ir_expression::get_operator(const char *str)
return (ir_expression_operation) -1;
 }
 
+ir_variable *
+ir_expression::variable_referenced() const
+{
+   switch (operation) {
+  case ir_binop_vector_extract:
+  case ir_triop_vector_insert:
+ /* We get these for things like a[0] where a is a vector type. In 
these
+  * cases we want variable_referenced() to return the actual vector
+  * variable this is wrapping.
+  */
+ return operands[0]->variable_referenced();
+  default:
+ return ir_rvalue::variable_referenced();
+   }
+}
+
 ir_constant::ir_constant()
: ir_rvalue(ir_type_constant)
 {
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 43a2bf0..9c9f22d 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1731,6 +1731,8 @@ public:
 
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
 
+   virtual ir_variable *variable_referenced() const;
+
ir_expression_operation operation;
ir_rvalue *operands[4];
 };
-- 
1.9.1

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

[Mesa-dev] [PATCH 09/17] st/mesa: implement glBitmap shader transformation using tgsi_transform_shader

From: Marek Olšák 

---
 src/mesa/Makefile.sources|   1 +
 src/mesa/state_tracker/st_cb_bitmap.c| 145 --
 src/mesa/state_tracker/st_cb_bitmap.h|  11 +-
 src/mesa/state_tracker/st_cb_bitmap_shader.c | 174 +++
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   |  78 
 src/mesa/state_tracker/st_glsl_to_tgsi.h |   3 -
 src/mesa/state_tracker/st_program.c  |  34 --
 7 files changed, 202 insertions(+), 244 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_cb_bitmap_shader.c

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 0915594..8eb43ce 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -415,6 +415,7 @@ STATETRACKER_FILES = \
state_tracker/st_cache.h \
state_tracker/st_cb_bitmap.c \
state_tracker/st_cb_bitmap.h \
+   state_tracker/st_cb_bitmap_shader.c \
state_tracker/st_cb_blit.c \
state_tracker/st_cb_blit.h \
state_tracker/st_cb_bufferobjects.c \
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
b/src/mesa/state_tracker/st_cb_bitmap.c
index 230eba8..bb6dfe8 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -108,151 +108,6 @@ struct bitmap_cache
 
 
 /**
- * Make fragment program for glBitmap:
- *   Sample the texture and kill the fragment if the bit is 0.
- * This program will be combined with the user's fragment program.
- */
-static struct st_fragment_program *
-make_bitmap_fragment_program(struct gl_context *ctx, GLuint samplerIndex)
-{
-   struct st_context *st = st_context(ctx);
-   struct st_fragment_program *stfp;
-   struct gl_program *p;
-   GLuint ic = 0;
-
-   p = ctx->Driver.NewProgram(ctx, GL_FRAGMENT_PROGRAM_ARB, 0);
-   if (!p)
-  return NULL;
-
-   p->NumInstructions = 3;
-
-   p->Instructions = _mesa_alloc_instructions(p->NumInstructions);
-   if (!p->Instructions) {
-  ctx->Driver.DeleteProgram(ctx, p);
-  return NULL;
-   }
-   _mesa_init_instructions(p->Instructions, p->NumInstructions);
-
-   /* TEX tmp0, fragment.texcoord[0], texture[0], 2D; */
-   p->Instructions[ic].Opcode = OPCODE_TEX;
-   p->Instructions[ic].DstReg.File = PROGRAM_TEMPORARY;
-   p->Instructions[ic].DstReg.Index = 0;
-   p->Instructions[ic].SrcReg[0].File = PROGRAM_INPUT;
-   p->Instructions[ic].SrcReg[0].Index = VARYING_SLOT_TEX0;
-   p->Instructions[ic].TexSrcUnit = samplerIndex;
-   p->Instructions[ic].TexSrcTarget = TEXTURE_2D_INDEX;
-   ic++;
-
-   /* KIL if -tmp0 < 0 # texel=0 -> keep / texel=0 -> discard */
-   p->Instructions[ic].Opcode = OPCODE_KIL;
-   p->Instructions[ic].SrcReg[0].File = PROGRAM_TEMPORARY;
-
-   if (st->bitmap.tex_format == PIPE_FORMAT_L8_UNORM)
-  p->Instructions[ic].SrcReg[0].Swizzle = SWIZZLE_;
-
-   p->Instructions[ic].SrcReg[0].Index = 0;
-   p->Instructions[ic].SrcReg[0].Negate = NEGATE_XYZW;
-   ic++;
-
-   /* END; */
-   p->Instructions[ic++].Opcode = OPCODE_END;
-
-   assert(ic == p->NumInstructions);
-
-   p->InputsRead = VARYING_BIT_TEX0;
-   p->OutputsWritten = 0x0;
-   p->SamplersUsed = (1 << samplerIndex);
-
-   stfp = (struct st_fragment_program *) p;
-   stfp->Base.UsesKill = GL_TRUE;
-
-   return stfp;
-}
-
-
-static struct gl_program *
-make_bitmap_fragment_program_glsl(struct st_context *st,
-  struct st_fragment_program *orig,
-  GLuint samplerIndex)
-{
-   struct gl_context *ctx = st->ctx;
-   struct st_fragment_program *fp = (struct st_fragment_program *)
-  ctx->Driver.NewProgram(ctx, GL_FRAGMENT_PROGRAM_ARB, 0);
-
-   if (!fp)
-  return NULL;
-   
-   get_bitmap_visitor(fp, orig->glsl_to_tgsi, samplerIndex);
-   return >Base.Base;
-}
-
-
-static int
-find_free_bit(uint bitfield)
-{
-   int i;
-   for (i = 0; i < 32; i++) {
-  if ((bitfield & (1 << i)) == 0) {
- return i;
-  }
-   }
-   return -1;
-}
-
-
-/**
- * Combine basic bitmap fragment program with the user-defined program.
- * \param st  current context
- * \param fpIn  the incoming fragment program
- * \param fpOut  the new fragment program which does fragment culling
- * \param bitmap_sampler  sampler number for the bitmap texture
- */
-void
-st_make_bitmap_fragment_program(struct st_context *st,
-struct gl_fragment_program *fpIn,
-struct gl_fragment_program **fpOut,
-GLuint *bitmap_sampler)
-{
-   struct st_fragment_program *bitmap_prog;
-   struct st_fragment_program *stfpIn = (struct st_fragment_program *) fpIn;
-   struct gl_program *newProg;
-   uint sampler;
-
-   /*
-* Generate new program which is the user-defined program prefixed
-* with the bitmap sampler/kill instructions.
-*/
-   sampler = find_free_bit(fpIn->Base.SamplersUsed);
-   
-   if (stfpIn->glsl_to_tgsi)
-  newProg =

[Mesa-dev] [PATCH 15/17] st/mesa: translate geometry shaders into TGSI when we get them

From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_program.c |  2 ++
 src/mesa/state_tracker/st_program.c| 38 --
 src/mesa/state_tracker/st_program.h|  5 +
 3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_program.c 
b/src/mesa/state_tracker/st_cb_program.c
index 40eeb0f..dff06dd 100644
--- a/src/mesa/state_tracker/st_cb_program.c
+++ b/src/mesa/state_tracker/st_cb_program.c
@@ -244,6 +244,8 @@ st_program_string_notify( struct gl_context *ctx,
   struct st_geometry_program *stgp = (struct st_geometry_program *) prog;
 
   st_release_gp_variants(st, stgp);
+  if (!st_translate_geometry_program(st, stgp))
+ return false;
 
   if (st->gp == stgp)
 st->dirty.st |= ST_NEW_GEOMETRY_PROGRAM;
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 5eded93..37e7a09 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -170,6 +170,11 @@ st_release_gp_variants(struct st_context *st, struct 
st_geometry_program *stgp)
}
 
stgp->variants = NULL;
+
+   if (stgp->tgsi.tokens) {
+  ureg_free_tokens(stgp->tgsi.tokens);
+  stgp->tgsi.tokens = NULL;
+   }
 }
 
 
@@ -1276,19 +1281,15 @@ st_translate_program_common(struct st_context *st,
 /**
  * Translate a geometry program to create a new variant.
  */
-static struct st_gp_variant *
+bool
 st_translate_geometry_program(struct st_context *st,
-  struct st_geometry_program *stgp,
-  const struct st_gp_variant_key *key)
+  struct st_geometry_program *stgp)
 {
-   struct pipe_context *pipe = st->pipe;
struct ureg_program *ureg;
-   struct st_gp_variant *gpv;
-   struct pipe_shader_state state;
 
ureg = ureg_create_with_screen(TGSI_PROCESSOR_GEOMETRY, st->pipe->screen);
if (ureg == NULL)
-  return NULL;
+  return false;
 
ureg_property(ureg, TGSI_PROPERTY_GS_INPUT_PRIM, stgp->Base.InputType);
ureg_property(ureg, TGSI_PROPERTY_GS_OUTPUT_PRIM, stgp->Base.OutputType);
@@ -1297,19 +1298,26 @@ st_translate_geometry_program(struct st_context *st,
ureg_property(ureg, TGSI_PROPERTY_GS_INVOCATIONS, stgp->Base.Invocations);
 
st_translate_program_common(st, >Base.Base, stgp->glsl_to_tgsi, ureg,
-   TGSI_PROCESSOR_GEOMETRY, );
+   TGSI_PROCESSOR_GEOMETRY, >tgsi);
+   return true;
+}
+
+
+static struct st_gp_variant *
+st_create_gp_variant(struct st_context *st,
+ struct st_geometry_program *stgp,
+ const struct st_gp_variant_key *key)
+{
+   struct pipe_context *pipe = st->pipe;
+   struct st_gp_variant *gpv;
 
gpv = CALLOC_STRUCT(st_gp_variant);
-   if (!gpv) {
-  ureg_free_tokens(state.tokens);
+   if (!gpv)
   return NULL;
-   }
 
/* fill in new variant */
-   gpv->driver_shader = pipe->create_gs_state(pipe, );
+   gpv->driver_shader = pipe->create_gs_state(pipe, >tgsi);
gpv->key = *key;
-
-   ureg_free_tokens(state.tokens);
return gpv;
 }
 
@@ -1333,7 +1341,7 @@ st_get_gp_variant(struct st_context *st,
 
if (!gpv) {
   /* create new */
-  gpv = st_translate_geometry_program(st, stgp, key);
+  gpv = st_create_gp_variant(st, stgp, key);
   if (gpv) {
  /* insert into list */
  gpv->next = stgp->variants;
diff --git a/src/mesa/state_tracker/st_program.h 
b/src/mesa/state_tracker/st_program.h
index d4b5c1f..3a4c260 100644
--- a/src/mesa/state_tracker/st_program.h
+++ b/src/mesa/state_tracker/st_program.h
@@ -200,6 +200,7 @@ struct st_gp_variant
 struct st_geometry_program
 {
struct gl_geometry_program Base;  /**< The Mesa geometry program */
+   struct pipe_shader_state tgsi;
struct glsl_to_tgsi_visitor* glsl_to_tgsi;
 
struct st_gp_variant *variants;
@@ -442,6 +443,10 @@ extern bool
 st_translate_fragment_program(struct st_context *st,
   struct st_fragment_program *stfp);
 
+extern bool
+st_translate_geometry_program(struct st_context *st,
+  struct st_geometry_program *stgp);
+
 extern void
 st_print_current_vertex_program(void);
 
-- 
2.1.4

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

[Mesa-dev] [PATCH 11/17] st/mesa: implement DrawPixels shader transformation using tgsi_transform_shader

From: Marek Olšák 

---
 src/mesa/Makefile.sources|   1 +
 src/mesa/state_tracker/st_atom_pixeltransfer.c   | 225 +---
 src/mesa/state_tracker/st_cb_drawpixels.c| 118 +--
 src/mesa/state_tracker/st_cb_drawpixels.h|   9 +-
 src/mesa/state_tracker/st_cb_drawpixels_shader.c | 255 +++
 src/mesa/state_tracker/st_context.c  |   6 +-
 src/mesa/state_tracker/st_context.h  |   7 -
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 132 
 src/mesa/state_tracker/st_glsl_to_tgsi.h |   3 -
 src/mesa/state_tracker/st_program.c  |  51 +++--
 10 files changed, 303 insertions(+), 504 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_cb_drawpixels_shader.c

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 8eb43ce..36a0d33 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -426,6 +426,7 @@ STATETRACKER_FILES = \
state_tracker/st_cb_condrender.h \
state_tracker/st_cb_drawpixels.c \
state_tracker/st_cb_drawpixels.h \
+   state_tracker/st_cb_drawpixels_shader.c \
state_tracker/st_cb_drawtex.c \
state_tracker/st_cb_drawtex.h \
state_tracker/st_cb_eglimage.c \
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c 
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index a04163c..f94c358 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -25,65 +25,17 @@
  * 
  **/
 
-/*
- * Generate fragment programs to implement pixel transfer ops, such as
- * scale/bias, colortable, convolution...
- *
- * Authors:
+/* Authors:
  *   Brian Paul
  */
 
-#include "main/imports.h"
-#include "main/image.h"
-#include "main/macros.h"
-#include "program/program.h"
-#include "program/prog_cache.h"
-#include "program/prog_instruction.h"
-#include "program/prog_parameter.h"
-#include "program/prog_print.h"
-
 #include "st_context.h"
-#include "st_format.h"
 #include "st_texture.h"
 
-#include "pipe/p_screen.h"
-#include "pipe/p_context.h"
 #include "util/u_inlines.h"
 #include "util/u_pack_color.h"
 
 
-struct state_key
-{
-   GLuint scaleAndBias:1;
-   GLuint pixelMaps:1;
-
-#if 0
-   GLfloat Maps[3][256][4];
-   int NumMaps;
-   GLint NumStages;
-   pipeline_stage Stages[STAGE_MAX];
-   GLboolean StagesUsed[STAGE_MAX];
-   GLfloat Scale1[4], Bias1[4];
-   GLfloat Scale2[4], Bias2[4];
-#endif
-};
-
-static void
-make_state_key(struct gl_context *ctx,  struct state_key *key)
-{
-   memset(key, 0, sizeof(*key));
-
-   if (ctx->Pixel.RedBias != 0.0 || ctx->Pixel.RedScale != 1.0 ||
-   ctx->Pixel.GreenBias != 0.0 || ctx->Pixel.GreenScale != 1.0 ||
-   ctx->Pixel.BlueBias != 0.0 || ctx->Pixel.BlueScale != 1.0 ||
-   ctx->Pixel.AlphaBias != 0.0 || ctx->Pixel.AlphaScale != 1.0) {
-  key->scaleAndBias = 1;
-   }
-
-   key->pixelMaps = ctx->Pixel.MapColorFlag;
-}
-
-
 /**
  * Update the pixelmap texture with the contents of the R/G/B/A pixel maps.
  */
@@ -128,74 +80,15 @@ load_color_map_texture(struct gl_context *ctx, struct 
pipe_resource *pt)
pipe_transfer_unmap(pipe, transfer);
 }
 
-
-
-#define MAX_INST 100
-
 /**
- * Returns a fragment program which implements the current pixel transfer ops.
+ * Upload the pixel transfer color map texture.
  */
-static struct gl_fragment_program *
-get_pixel_transfer_program(struct gl_context *ctx, const struct state_key *key)
+static void
+update_pixel_transfer(struct st_context *st)
 {
-   struct st_context *st = st_context(ctx);
-   struct prog_instruction inst[MAX_INST];
-   struct gl_program_parameter_list *params;
-   struct gl_fragment_program *fp;
-   GLuint ic = 0;
-   const GLuint colorTemp = 0;
-
-   fp = (struct gl_fragment_program *)
-  ctx->Driver.NewProgram(ctx, GL_FRAGMENT_PROGRAM_ARB, 0);
-   if (!fp)
-  return NULL;
-
-   params = _mesa_new_parameter_list();
-
-   /*
-* Get initial pixel color from the texture.
-* TEX colorTemp, fragment.texcoord[0], texture[0], 2D;
-*/
-   _mesa_init_instructions(inst + ic, 1);
-   inst[ic].Opcode = OPCODE_TEX;
-   inst[ic].DstReg.File = PROGRAM_TEMPORARY;
-   inst[ic].DstReg.Index = colorTemp;
-   inst[ic].SrcReg[0].File = PROGRAM_INPUT;
-   inst[ic].SrcReg[0].Index = VARYING_SLOT_TEX0;
-   inst[ic].TexSrcUnit = 0;
-   inst[ic].TexSrcTarget = TEXTURE_2D_INDEX;
-   ic++;
-   fp->Base.InputsRead = BITFIELD64_BIT(VARYING_SLOT_TEX0);
-   fp->Base.OutputsWritten = BITFIELD64_BIT(FRAG_RESULT_COLOR);
-   fp->Base.SamplersUsed = 0x1;  /* sampler 0 (bit 0) is used */
-
-   if (key->scaleAndBias) {
-  static const gl_state_index scale_state[STATE_LENGTH] =
- { STATE_INTERNAL, STATE_PT_SCALE, 0, 0, 0 };
-  static const gl_state_index bias_state[STATE_LENGTH] =
- { STATE_INTERNAL, STATE_PT_BIAS, 0, 0, 0 };
-

[Mesa-dev] [PATCH 03/17] tgsi/scan: add info about declared samplers

From: Marek Olšák 

---
 src/gallium/auxiliary/tgsi/tgsi_scan.c | 2 ++
 src/gallium/auxiliary/tgsi/tgsi_scan.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 00b07c8..1c45748 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -208,6 +208,8 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
   assert(fullinst->Instruction.Texture);
   assert(src->Register.Index < 
Elements(info->is_msaa_sampler));
 
+  info->samplers_declared |= 1 << src->Register.Index;
+
   if (fullinst->Instruction.Texture &&
   (fullinst->Texture.Texture == TGSI_TEXTURE_2D_MSAA ||
fullinst->Texture.Texture == 
TGSI_TEXTURE_2D_ARRAY_MSAA)) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 3ceb557..d60ccab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -64,6 +64,7 @@ struct tgsi_shader_info
uint file_count[TGSI_FILE_COUNT];  /**< number of declared registers */
int file_max[TGSI_FILE_COUNT];  /**< highest index of declared registers */
int const_file_max[PIPE_MAX_CONSTANT_BUFFERS];
+   unsigned samplers_declared; /**< bitmask of declared samplers */
 
ubyte input_array_first[PIPE_MAX_SHADER_INPUTS];
ubyte input_array_last[PIPE_MAX_SHADER_INPUTS];
-- 
2.1.4

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

[Mesa-dev] [PATCH 08/17] st/mesa: remove old emulation for VS and FS variants

From: Marek Olšák 

---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 48 +++-
 src/mesa/state_tracker/st_glsl_to_tgsi.h   |  4 +--
 src/mesa/state_tracker/st_mesa_to_tgsi.c   | 50 +++---
 src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 +--
 src/mesa/state_tracker/st_program.c| 18 +++
 5 files changed, 17 insertions(+), 107 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 633e90f..1488ea0 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4852,7 +4852,7 @@ src_register(struct st_translate *t, const st_src_reg 
*reg)
 static struct ureg_dst
 translate_dst(struct st_translate *t,
   const st_dst_reg *dst_reg,
-  bool saturate, bool clamp_color)
+  bool saturate)
 {
struct ureg_dst dst = dst_register(t, dst_reg->file, dst_reg->index,
   dst_reg->array_id);
@@ -4864,28 +4864,6 @@ translate_dst(struct st_translate *t,
 
if (saturate)
   dst = ureg_saturate(dst);
-   else if (clamp_color && dst_reg->file == PROGRAM_OUTPUT) {
-  /* Clamp colors for ARB_color_buffer_float. */
-  switch (t->procType) {
-  case TGSI_PROCESSOR_VERTEX:
- /* This can only occur with a compatibility profile, which doesn't
-  * support geometry shaders. */
- if (dst_reg->index == VARYING_SLOT_COL0 ||
- dst_reg->index == VARYING_SLOT_COL1 ||
- dst_reg->index == VARYING_SLOT_BFC0 ||
- dst_reg->index == VARYING_SLOT_BFC1) {
-dst = ureg_saturate(dst);
- }
- break;
-
-  case TGSI_PROCESSOR_FRAGMENT:
- if (dst_reg->index == FRAG_RESULT_COLOR ||
- dst_reg->index >= FRAG_RESULT_DATA0) {
-dst = ureg_saturate(dst);
- }
- break;
-  }
-   }
 
if (dst_reg->reladdr != NULL) {
   assert(dst_reg->file != PROGRAM_TEMPORARY);
@@ -4991,8 +4969,7 @@ translate_tex_offset(struct st_translate *t,
 
 static void
 compile_tgsi_instruction(struct st_translate *t,
- const glsl_to_tgsi_instruction *inst,
- bool clamp_dst_color_output)
+ const glsl_to_tgsi_instruction *inst)
 {
struct ureg_program *ureg = t->ureg;
GLuint i;
@@ -5010,8 +4987,7 @@ compile_tgsi_instruction(struct st_translate *t,
for (i = 0; i < num_dst; i++)
   dst[i] = translate_dst(t,
  >dst[i],
- inst->saturate,
- clamp_dst_color_output);
+ inst->saturate);
 
for (i = 0; i < num_src; i++)
   src[i] = translate_src(t, >src[i]);
@@ -5286,16 +5262,6 @@ emit_face_var(struct gl_context *ctx, struct 
st_translate *t)
t->inputs[t->inputMapping[VARYING_SLOT_FACE]] = ureg_src(face_temp);
 }
 
-static void
-emit_edgeflags(struct st_translate *t)
-{
-   struct ureg_program *ureg = t->ureg;
-   struct ureg_dst edge_dst = t->outputs[t->outputMapping[VARYING_SLOT_EDGE]];
-   struct ureg_src edge_src = t->inputs[t->inputMapping[VERT_ATTRIB_EDGEFLAG]];
-
-   ureg_MOV(ureg, edge_dst, edge_src);
-}
-
 static bool
 find_array(unsigned attr, struct array_decl *arrays, unsigned count,
unsigned *array_id, unsigned *array_size)
@@ -5353,9 +5319,7 @@ st_translate_program(
const GLuint outputMapping[],
const GLuint outputSlotToAttr[],
const ubyte outputSemanticName[],
-   const ubyte outputSemanticIndex[],
-   boolean passthrough_edgeflags,
-   boolean clamp_color)
+   const ubyte outputSemanticIndex[])
 {
struct st_translate *t;
unsigned i;
@@ -5544,8 +5508,6 @@ st_translate_program(
 t->outputs[i] = ureg_writemask(t->outputs[i], TGSI_WRITEMASK_X);
  }
   }
-  if (passthrough_edgeflags)
- emit_edgeflags(t);
}
 
/* Declare address register.
@@ -5696,7 +5658,7 @@ st_translate_program(
 */
foreach_in_list(glsl_to_tgsi_instruction, inst, >instructions) {
   set_insn_start(t, ureg_get_instruction_number(ureg));
-  compile_tgsi_instruction(t, inst, clamp_color);
+  compile_tgsi_instruction(t, inst);
}
 
/* Fix up all emitted labels:
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.h 
b/src/mesa/state_tracker/st_glsl_to_tgsi.h
index 4af747f..c29fc76 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.h
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.h
@@ -52,9 +52,7 @@ enum pipe_error st_translate_program(
const GLuint outputMapping[],
const GLuint outputSlotToAttr[],
const ubyte outputSemanticName[],
-   const ubyte outputSemanticIndex[],
-   boolean passthrough_edgeflags,
-   boolean clamp_color);
+   const ubyte outputSemanticIndex[]);
 
 void free_glsl_to_tgsi_visitor(struct glsl_to_tgsi_visitor *v);
 void get_pixel_transfer_visitor(struct

[Mesa-dev] [PATCH 16/17] st/mesa: translate tessellation shaders into TGSI when we get them

From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_program.c |  4 ++
 src/mesa/state_tracker/st_program.c| 86 --
 src/mesa/state_tracker/st_program.h| 10 
 3 files changed, 64 insertions(+), 36 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_program.c 
b/src/mesa/state_tracker/st_cb_program.c
index dff06dd..003ce33 100644
--- a/src/mesa/state_tracker/st_cb_program.c
+++ b/src/mesa/state_tracker/st_cb_program.c
@@ -265,6 +265,8 @@ st_program_string_notify( struct gl_context *ctx,
  (struct st_tessctrl_program *) prog;
 
   st_release_tcp_variants(st, sttcp);
+  if (!st_translate_tessctrl_program(st, sttcp))
+ return false;
 
   if (st->tcp == sttcp)
  st->dirty.st |= ST_NEW_TESSCTRL_PROGRAM;
@@ -274,6 +276,8 @@ st_program_string_notify( struct gl_context *ctx,
  (struct st_tesseval_program *) prog;
 
   st_release_tep_variants(st, sttep);
+  if (!st_translate_tesseval_program(st, sttep))
+ return false;
 
   if (st->tep == sttep)
  st->dirty.st |= ST_NEW_TESSEVAL_PROGRAM;
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 37e7a09..3317071 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -207,6 +207,11 @@ st_release_tcp_variants(struct st_context *st, struct 
st_tessctrl_program *sttcp
}
 
sttcp->variants = NULL;
+
+   if (sttcp->tgsi.tokens) {
+  ureg_free_tokens(sttcp->tgsi.tokens);
+  sttcp->tgsi.tokens = NULL;
+   }
 }
 
 
@@ -239,6 +244,11 @@ st_release_tep_variants(struct st_context *st, struct 
st_tesseval_program *sttep
}
 
sttep->variants = NULL;
+
+   if (sttep->tgsi.tokens) {
+  ureg_free_tokens(sttep->tgsi.tokens);
+  sttep->tgsi.tokens = NULL;
+   }
 }
 
 
@@ -1356,38 +1366,40 @@ st_get_gp_variant(struct st_context *st,
 /**
  * Translate a tessellation control program to create a new variant.
  */
-static struct st_tcp_variant *
+bool
 st_translate_tessctrl_program(struct st_context *st,
-  struct st_tessctrl_program *sttcp,
-  const struct st_tcp_variant_key *key)
+  struct st_tessctrl_program *sttcp)
 {
-   struct pipe_context *pipe = st->pipe;
struct ureg_program *ureg;
-   struct st_tcp_variant *tcpv;
-   struct pipe_shader_state state;
 
-   ureg = ureg_create_with_screen(TGSI_PROCESSOR_TESS_CTRL, pipe->screen);
-   if (ureg == NULL) {
-  return NULL;
-   }
+   ureg = ureg_create_with_screen(TGSI_PROCESSOR_TESS_CTRL, st->pipe->screen);
+   if (ureg == NULL)
+  return false;
 
ureg_property(ureg, TGSI_PROPERTY_TCS_VERTICES_OUT,
  sttcp->Base.VerticesOut);
 
st_translate_program_common(st, >Base.Base, sttcp->glsl_to_tgsi,
-   ureg, TGSI_PROCESSOR_TESS_CTRL, );
+   ureg, TGSI_PROCESSOR_TESS_CTRL, >tgsi);
+   return true;
+}
+
+
+static struct st_tcp_variant *
+st_create_tcp_variant(struct st_context *st,
+  struct st_tessctrl_program *sttcp,
+  const struct st_tcp_variant_key *key)
+{
+   struct pipe_context *pipe = st->pipe;
+   struct st_tcp_variant *tcpv;
 
tcpv = CALLOC_STRUCT(st_tcp_variant);
-   if (!tcpv) {
-  ureg_free_tokens(state.tokens);
+   if (!tcpv)
   return NULL;
-   }
 
/* fill in new variant */
-   tcpv->driver_shader = pipe->create_tcs_state(pipe, );
+   tcpv->driver_shader = pipe->create_tcs_state(pipe, >tgsi);
tcpv->key = *key;
-
-   ureg_free_tokens(state.tokens);
return tcpv;
 }
 
@@ -1411,7 +1423,7 @@ st_get_tcp_variant(struct st_context *st,
 
if (!tcpv) {
   /* create new */
-  tcpv = st_translate_tessctrl_program(st, sttcp, key);
+  tcpv = st_create_tcp_variant(st, sttcp, key);
   if (tcpv) {
  /* insert into list */
  tcpv->next = sttcp->variants;
@@ -1426,20 +1438,15 @@ st_get_tcp_variant(struct st_context *st,
 /**
  * Translate a tessellation evaluation program to create a new variant.
  */
-static struct st_tep_variant *
+bool
 st_translate_tesseval_program(struct st_context *st,
-  struct st_tesseval_program *sttep,
-  const struct st_tep_variant_key *key)
+  struct st_tesseval_program *sttep)
 {
-   struct pipe_context *pipe = st->pipe;
struct ureg_program *ureg;
-   struct st_tep_variant *tepv;
-   struct pipe_shader_state state;
 
-   ureg = ureg_create_with_screen(TGSI_PROCESSOR_TESS_EVAL, pipe->screen);
-   if (ureg == NULL) {
-  return NULL;
-   }
+   ureg = ureg_create_with_screen(TGSI_PROCESSOR_TESS_EVAL, st->pipe->screen);
+   if (ureg == NULL)
+  return false;
 
if (sttep->Base.PrimitiveMode == GL_ISOLINES)
   ureg_property(ureg, TGSI_PROPERTY_TES_PRIM_MODE, GL_LINES);
@@ -1467,19 +1474,26 @@

[Mesa-dev] [PATCH 04/17] st/mesa: inline st_prepare_vertex_program

From: Marek Olšák 

No other shader stage has a "prepare" function.
This will allow removing some variables from st_vertex_program.

Also, prepare_fragment_program was a dead prototype.
---
 src/mesa/state_tracker/st_program.c | 41 ++---
 src/mesa/state_tracker/st_program.h | 10 -
 2 files changed, 11 insertions(+), 40 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index a07f8fe..63ffad7 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -228,24 +228,25 @@ st_release_tep_variants(struct st_context *st, struct 
st_tesseval_program *sttep
 
 
 /**
- * Translate a Mesa vertex shader into a TGSI shader.
- * \param outputMapping  to map vertex program output registers 
(VARYING_SLOT_x)
- *   to TGSI output slots
- * \param tokensOut  destination for TGSI tokens
- * \return  pointer to cached pipe_shader object.
+ * Translate a vertex program to create a new variant.
  */
-void
-st_prepare_vertex_program(struct gl_context *ctx,
-struct st_vertex_program *stvp)
+static struct st_vp_variant *
+st_translate_vertex_program(struct st_context *st,
+struct st_vertex_program *stvp,
+const struct st_vp_variant_key *key)
 {
-   struct st_context *st = st_context(ctx);
+   struct st_vp_variant *vpv = CALLOC_STRUCT(st_vp_variant);
+   struct pipe_context *pipe = st->pipe;
+   struct ureg_program *ureg;
+   enum pipe_error error;
+   unsigned num_outputs;
GLuint attr;
 
stvp->num_inputs = 0;
stvp->num_outputs = 0;
 
if (stvp->Base.IsPositionInvariant)
-  _mesa_insert_mvp_code(ctx, >Base);
+  _mesa_insert_mvp_code(st->ctx, >Base);
 
/*
 * Determine number of inputs, the mappings between VERT_ATTRIB_x
@@ -361,29 +362,9 @@ st_prepare_vertex_program(struct gl_context *ctx,
stvp->result_to_output[VARYING_SLOT_EDGE] = stvp->num_outputs;
stvp->output_semantic_name[stvp->num_outputs] = TGSI_SEMANTIC_EDGEFLAG;
stvp->output_semantic_index[stvp->num_outputs] = 0;
-}
-
-
-/**
- * Translate a vertex program to create a new variant.
- */
-static struct st_vp_variant *
-st_translate_vertex_program(struct st_context *st,
-struct st_vertex_program *stvp,
-const struct st_vp_variant_key *key)
-{
-   struct st_vp_variant *vpv = CALLOC_STRUCT(st_vp_variant);
-   struct pipe_context *pipe = st->pipe;
-   struct ureg_program *ureg;
-   enum pipe_error error;
-   unsigned num_outputs;
-
-   st_prepare_vertex_program(st->ctx, stvp);
 
if (!stvp->glsl_to_tgsi)
-   {
   _mesa_remove_output_reads(>Base.Base, PROGRAM_OUTPUT);
-   }
 
ureg = ureg_create_with_screen(TGSI_PROCESSOR_VERTEX, st->pipe->screen);
if (ureg == NULL) {
diff --git a/src/mesa/state_tracker/st_program.h 
b/src/mesa/state_tracker/st_program.h
index 7013993..f54cf83 100644
--- a/src/mesa/state_tracker/st_program.h
+++ b/src/mesa/state_tracker/st_program.h
@@ -414,16 +414,6 @@ st_get_tep_variant(struct st_context *st,
struct st_tesseval_program *stgp,
const struct st_tep_variant_key *key);
 
-
-extern void
-st_prepare_vertex_program(struct gl_context *ctx,
-  struct st_vertex_program *stvp);
-
-extern GLboolean
-st_prepare_fragment_program(struct gl_context *ctx,
-struct st_fragment_program *stfp);
-
-
 extern void
 st_release_vp_variants( struct st_context *st,
 struct st_vertex_program *stvp );
-- 
2.1.4

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

[Mesa-dev] [PATCH 14/17] st/mesa: translate fragment shaders into TGSI when we get them

From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_program.c |  2 +
 src/mesa/state_tracker/st_debug.c  |  2 +-
 src/mesa/state_tracker/st_program.c| 81 --
 src/mesa/state_tracker/st_program.h|  7 ++-
 4 files changed, 55 insertions(+), 37 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_program.c 
b/src/mesa/state_tracker/st_cb_program.c
index 745b447..40eeb0f 100644
--- a/src/mesa/state_tracker/st_cb_program.c
+++ b/src/mesa/state_tracker/st_cb_program.c
@@ -234,6 +234,8 @@ st_program_string_notify( struct gl_context *ctx,
   struct st_fragment_program *stfp = (struct st_fragment_program *) prog;
 
   st_release_fp_variants(st, stfp);
+  if (!st_translate_fragment_program(st, stfp))
+ return false;
 
   if (st->fp == stfp)
 st->dirty.st |= ST_NEW_FRAGMENT_PROGRAM;
diff --git a/src/mesa/state_tracker/st_debug.c 
b/src/mesa/state_tracker/st_debug.c
index 50891c1..6d859c6 100644
--- a/src/mesa/state_tracker/st_debug.c
+++ b/src/mesa/state_tracker/st_debug.c
@@ -98,7 +98,7 @@ st_print_current(void)
if (st->vp->Base.Base.Parameters)
   _mesa_print_parameter_list(st->vp->Base.Base.Parameters);
 
-   tgsi_dump( st->fp->variants[0].tgsi.tokens, 0 );
+   tgsi_dump(st->fp->tgsi.tokens, 0);
if (st->fp->Base.Base.Parameters)
   _mesa_print_parameter_list(st->fp->Base.Base.Parameters);
 }
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 4bdbf85..5eded93 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -114,8 +114,6 @@ delete_fp_variant(struct st_context *st, struct 
st_fp_variant *fpv)
   cso_delete_fragment_shader(st->cso_context, fpv->driver_shader);
if (fpv->parameters)
   _mesa_free_parameter_list(fpv->parameters);
-   if (fpv->tgsi.tokens)
-  ureg_free_tokens(fpv->tgsi.tokens);
free(fpv);
 }
 
@@ -135,6 +133,11 @@ st_release_fp_variants(struct st_context *st, struct 
st_fragment_program *stfp)
}
 
stfp->variants = NULL;
+
+   if (stfp->tgsi.tokens) {
+  ureg_free_tokens(stfp->tgsi.tokens);
+  stfp->tgsi.tokens = NULL;
+   }
 }
 
 
@@ -531,17 +534,12 @@ st_translate_interp(enum glsl_interp_qualifier glsl_qual, 
bool is_color)
 
 
 /**
- * Translate a Mesa fragment shader into a TGSI shader using extra info in
- * the key.
- * \return  new fragment program variant
+ * Translate a Mesa fragment shader into a TGSI shader.
  */
-static struct st_fp_variant *
+bool
 st_translate_fragment_program(struct st_context *st,
-  struct st_fragment_program *stfp,
-  const struct st_fp_variant_key *key)
+  struct st_fragment_program *stfp)
 {
-   struct pipe_context *pipe = st->pipe;
-   struct st_fp_variant *variant = CALLOC_STRUCT(st_fp_variant);
GLuint outputMapping[FRAG_RESULT_MAX];
GLuint inputMapping[VARYING_SLOT_MAX];
GLuint inputSlotToAttr[VARYING_SLOT_MAX];
@@ -561,10 +559,6 @@ st_translate_fragment_program(struct st_context *st,
ubyte fs_output_semantic_index[PIPE_MAX_SHADER_OUTPUTS];
uint fs_num_outputs = 0;
 
-   if (!variant)
-  return NULL;
-
-   assert(!(key->bitmap && key->drawpixels));
memset(inputSlotToAttr, ~0, sizeof(inputSlotToAttr));
 
if (!stfp->glsl_to_tgsi)
@@ -772,10 +766,8 @@ st_translate_fragment_program(struct st_context *st,
}
 
ureg = ureg_create_with_screen(TGSI_PROCESSOR_FRAGMENT, st->pipe->screen);
-   if (ureg == NULL) {
-  free(variant);
-  return NULL;
-   }
+   if (ureg == NULL)
+  return false;
 
if (ST_DEBUG & DEBUG_MESA) {
   _mesa_print_program(>Base.Base);
@@ -845,8 +837,26 @@ st_translate_fragment_program(struct st_context *st,
 fs_output_semantic_name,
 fs_output_semantic_index);
 
-   variant->tgsi.tokens = ureg_get_tokens(ureg, NULL);
+   stfp->tgsi.tokens = ureg_get_tokens(ureg, NULL);
ureg_destroy(ureg);
+   return stfp->tgsi.tokens != NULL;
+}
+
+static struct st_fp_variant *
+st_create_fp_variant(struct st_context *st,
+ struct st_fragment_program *stfp,
+ const struct st_fp_variant_key *key)
+{
+   struct pipe_context *pipe = st->pipe;
+   struct st_fp_variant *variant = CALLOC_STRUCT(st_fp_variant);
+   struct pipe_shader_state tgsi = {0};
+
+   if (!variant)
+  return NULL;
+
+   tgsi.tokens = stfp->tgsi.tokens;
+
+   assert(!(key->bitmap && key->drawpixels));
 
/* Emulate features. */
if (key->clamp_color || key->persample_shading) {
@@ -855,12 +865,11 @@ st_translate_fragment_program(struct st_context *st,
  (key->clamp_color ? TGSI_EMU_CLAMP_COLOR_OUTPUTS : 0) |
  (key->persample_shading ? TGSI_EMU_FORCE_PERSAMPLE_INTERP : 0);
 
-  tokens = tgsi_emulate(variant->tgsi.tokens, flags);
+  tokens = tgsi_emulate(tgsi.tokens, flags);
 
-  if

[Mesa-dev] [PATCH 17/17] st/mesa: release the glsl_to_tgsi visitor after translation

From: Marek Olšák 

---
 src/mesa/state_tracker/st_program.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 3317071..6a69ba7 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -425,6 +425,9 @@ st_translate_vertex_program(struct st_context *st,
   st_translate_stream_output_info(stvp->glsl_to_tgsi,
   stvp->result_to_output,
   >tgsi.stream_output);
+
+  free_glsl_to_tgsi_visitor(stvp->glsl_to_tgsi);
+  stvp->glsl_to_tgsi = NULL;
} else
   error = st_translate_mesa_program(st->ctx,
 TGSI_PROCESSOR_VERTEX,
@@ -815,7 +818,7 @@ st_translate_fragment_program(struct st_context *st,
   }
}
 
-   if (stfp->glsl_to_tgsi)
+   if (stfp->glsl_to_tgsi) {
   st_translate_program(st->ctx,
TGSI_PROCESSOR_FRAGMENT,
ureg,
@@ -835,7 +838,10 @@ st_translate_fragment_program(struct st_context *st,
NULL,
fs_output_semantic_name,
fs_output_semantic_index);
-   else
+
+  free_glsl_to_tgsi_visitor(stfp->glsl_to_tgsi);
+  stfp->glsl_to_tgsi = NULL;
+   } else
   st_translate_mesa_program(st->ctx,
 TGSI_PROCESSOR_FRAGMENT,
 ureg,
@@ -1309,6 +1315,9 @@ st_translate_geometry_program(struct st_context *st,
 
st_translate_program_common(st, >Base.Base, stgp->glsl_to_tgsi, ureg,
TGSI_PROCESSOR_GEOMETRY, >tgsi);
+
+   free_glsl_to_tgsi_visitor(stgp->glsl_to_tgsi);
+   stgp->glsl_to_tgsi = NULL;
return true;
 }
 
@@ -1381,6 +1390,9 @@ st_translate_tessctrl_program(struct st_context *st,
 
st_translate_program_common(st, >Base.Base, sttcp->glsl_to_tgsi,
ureg, TGSI_PROCESSOR_TESS_CTRL, >tgsi);
+
+   free_glsl_to_tgsi_visitor(sttcp->glsl_to_tgsi);
+   sttcp->glsl_to_tgsi = NULL;
return true;
 }
 
@@ -1475,6 +1487,9 @@ st_translate_tesseval_program(struct st_context *st,
 
st_translate_program_common(st, >Base.Base, sttep->glsl_to_tgsi,
ureg, TGSI_PROCESSOR_TESS_EVAL, >tgsi);
+
+   free_glsl_to_tgsi_visitor(sttep->glsl_to_tgsi);
+   sttep->glsl_to_tgsi = NULL;
return true;
 }
 
-- 
2.1.4

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

[Mesa-dev] [PATCH 10/17] st/mesa: make Z/S drawpix shaders independent of variants, don't use Mesa IR

From: Marek Olšák 

- there is no connection to user fragment shaders, so having these as
  shader variants makes no sense
- don't use Mesa IR, use TGSI
- don't create gl_fragment_program, just create the shader CSO
---
 src/mesa/state_tracker/st_cb_drawpixels.c | 185 +++---
 src/mesa/state_tracker/st_cb_drawpixels.h |   6 -
 src/mesa/state_tracker/st_context.h   |   2 +-
 src/mesa/state_tracker/st_program.c   |  15 +--
 src/mesa/state_tracker/st_program.h   |   2 -
 5 files changed, 72 insertions(+), 138 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 152160e..0ef0e69 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -189,100 +189,80 @@ st_make_drawpix_fragment_program(struct st_context *st,
  * stencil value value, then writes to FRAG_RESULT_DEPTH/FRAG_RESULT_STENCIL.
  * Used for glDrawPixels(GL_DEPTH_COMPONENT / GL_STENCIL_INDEX).
  * Pass fragment color through as-is.
- * \return pointer to the gl_fragment program
+ *
+ * \return CSO of the fragment shader.
  */
-struct gl_fragment_program *
-st_make_drawpix_z_stencil_program(struct st_context *st,
-  GLboolean write_depth,
-  GLboolean write_stencil)
+static void *
+get_drawpix_z_stencil_program(struct st_context *st,
+  GLboolean write_depth,
+  GLboolean write_stencil)
 {
-   struct gl_context *ctx = st->ctx;
-   struct gl_program *p;
-   struct gl_fragment_program *fp;
-   GLuint ic = 0;
+   struct ureg_program *ureg;
+   struct ureg_src depth_sampler, stencil_sampler;
+   struct ureg_src texcoord, color;
+   struct ureg_dst out_color, out_depth, out_stencil;
const GLuint shaderIndex = write_depth * 2 + write_stencil;
+   void *cso;
 
-   assert(shaderIndex < ARRAY_SIZE(st->drawpix.shaders));
+   assert(shaderIndex < ARRAY_SIZE(st->drawpix.zs_shaders));
 
-   if (st->drawpix.shaders[shaderIndex]) {
+   if (st->drawpix.zs_shaders[shaderIndex]) {
   /* already have the proper shader */
-  return st->drawpix.shaders[shaderIndex];
+  return st->drawpix.zs_shaders[shaderIndex];
}
 
-   /*
-* Create shader now
-*/
-   p = ctx->Driver.NewProgram(ctx, GL_FRAGMENT_PROGRAM_ARB, 0);
-   if (!p)
-  return NULL;
-
-   p->NumInstructions = write_depth ? 3 : 1;
-   p->NumInstructions += write_stencil ? 1 : 0;
-
-   p->Instructions = _mesa_alloc_instructions(p->NumInstructions);
-   if (!p->Instructions) {
-  ctx->Driver.DeleteProgram(ctx, p);
+   ureg = ureg_create(TGSI_PROCESSOR_FRAGMENT);
+   if (ureg == NULL)
   return NULL;
-   }
-   _mesa_init_instructions(p->Instructions, p->NumInstructions);
 
if (write_depth) {
-  /* TEX result.depth, fragment.texcoord[0], texture[0], 2D; */
-  p->Instructions[ic].Opcode = OPCODE_TEX;
-  p->Instructions[ic].DstReg.File = PROGRAM_OUTPUT;
-  p->Instructions[ic].DstReg.Index = FRAG_RESULT_DEPTH;
-  p->Instructions[ic].DstReg.WriteMask = WRITEMASK_Z;
-  p->Instructions[ic].SrcReg[0].File = PROGRAM_INPUT;
-  p->Instructions[ic].SrcReg[0].Index = VARYING_SLOT_TEX0;
-  p->Instructions[ic].TexSrcUnit = 0;
-  p->Instructions[ic].TexSrcTarget = TEXTURE_2D_INDEX;
-  ic++;
-  /* MOV result.color, fragment.color; */
-  p->Instructions[ic].Opcode = OPCODE_MOV;
-  p->Instructions[ic].DstReg.File = PROGRAM_OUTPUT;
-  p->Instructions[ic].DstReg.Index = FRAG_RESULT_COLOR;
-  p->Instructions[ic].SrcReg[0].File = PROGRAM_INPUT;
-  p->Instructions[ic].SrcReg[0].Index = VARYING_SLOT_COL0;
-  ic++;
+  depth_sampler = ureg_DECL_sampler(ureg, 0);
+  ureg_DECL_sampler_view(ureg, 0, TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+  out_depth = ureg_DECL_output(ureg, TGSI_SEMANTIC_POSITION, 0);
}
 
if (write_stencil) {
-  /* TEX result.stencil, fragment.texcoord[0], texture[0], 2D; */
-  p->Instructions[ic].Opcode = OPCODE_TEX;
-  p->Instructions[ic].DstReg.File = PROGRAM_OUTPUT;
-  p->Instructions[ic].DstReg.Index = FRAG_RESULT_STENCIL;
-  p->Instructions[ic].DstReg.WriteMask = WRITEMASK_Y;
-  p->Instructions[ic].SrcReg[0].File = PROGRAM_INPUT;
-  p->Instructions[ic].SrcReg[0].Index = VARYING_SLOT_TEX0;
-  p->Instructions[ic].TexSrcUnit = 1;
-  p->Instructions[ic].TexSrcTarget = TEXTURE_2D_INDEX;
-  ic++;
+  stencil_sampler = ureg_DECL_sampler(ureg, 1);
+  ureg_DECL_sampler_view(ureg, 0, TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_UINT,
+ TGSI_RETURN_TYPE_UINT,
+ TGSI_RETURN_TYPE_UINT,
+

[Mesa-dev] [PATCH 06/17] st/mesa: use TGSI utility to emulate features for VS variants

From: Marek Olšák 

---
 src/mesa/state_tracker/st_program.c | 41 ++---
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 9e100db..6ace352 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -43,6 +43,8 @@
 #include "pipe/p_shader_tokens.h"
 #include "draw/draw_context.h"
 #include "tgsi/tgsi_dump.h"
+#include "tgsi/tgsi_emulate.h"
+#include "tgsi/tgsi_parse.h"
 #include "tgsi/tgsi_ureg.h"
 
 #include "st_debug.h"
@@ -377,12 +379,6 @@ st_translate_vertex_program(struct st_context *st,
 
vpv->key = *key;
 
-   vpv->num_inputs = stvp->num_inputs;
-   if (key->passthrough_edgeflags) {
-  vpv->num_inputs++;
-  num_outputs++;
-   }
-
if (ST_DEBUG & DEBUG_MESA) {
   _mesa_print_program(>Base.Base);
   _mesa_print_program_parameters(st->ctx, >Base.Base);
@@ -396,7 +392,7 @@ st_translate_vertex_program(struct st_context *st,
stvp->glsl_to_tgsi,
>Base.Base,
/* inputs */
-   vpv->num_inputs,
+   stvp->num_inputs,
input_to_index,
NULL, /* inputSlotToAttr */
NULL, /* input semantic name */
@@ -409,15 +405,15 @@ st_translate_vertex_program(struct st_context *st,
output_slot_to_attr,
output_semantic_name,
output_semantic_index,
-   key->passthrough_edgeflags,
-   key->clamp_color);
+   false,
+   false);
else
   error = st_translate_mesa_program(st->ctx,
 TGSI_PROCESSOR_VERTEX,
 ureg,
 >Base.Base,
 /* inputs */
-vpv->num_inputs,
+stvp->num_inputs,
 input_to_index,
 NULL, /* input semantic name */
 NULL, /* input semantic index */
@@ -427,8 +423,8 @@ st_translate_vertex_program(struct st_context *st,
 stvp->result_to_output,
 output_semantic_name,
 output_semantic_index,
-key->passthrough_edgeflags,
-key->clamp_color);
+false,
+false);
 
if (error)
   goto fail;
@@ -445,6 +441,27 @@ st_translate_vertex_program(struct st_context *st,
   >tgsi.stream_output);
}
 
+   vpv->num_inputs = stvp->num_inputs;
+
+   /* Emulate features. */
+   if (key->clamp_color || key->passthrough_edgeflags) {
+  const struct tgsi_token *tokens;
+  unsigned flags =
+ (key->clamp_color ? TGSI_EMU_CLAMP_COLOR_OUTPUTS : 0) |
+ (key->passthrough_edgeflags ? TGSI_EMU_PASSTHROUGH_EDGEFLAG : 0);
+
+  tokens = tgsi_emulate(vpv->tgsi.tokens, flags);
+
+  if (tokens) {
+ tgsi_free_tokens(vpv->tgsi.tokens);
+ vpv->tgsi.tokens = tokens;
+
+ if (key->passthrough_edgeflags)
+vpv->num_inputs++;
+  } else
+ fprintf(stderr, "mesa: cannot emulate deprecated features\n");
+   }
+
if (ST_DEBUG & DEBUG_TGSI) {
   tgsi_dump(vpv->tgsi.tokens, 0);
   debug_printf("\n");
-- 
2.1.4

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

[Mesa-dev] [PATCH 13/17] st/mesa: translate vertex shaders into TGSI when we get them

From: Marek Olšák 

The translate functions is split into two:
- translation to TGSI
- creating the variant (TGSI transformations only)
---
 src/mesa/state_tracker/st_cb_program.c |  4 +-
 src/mesa/state_tracker/st_program.c| 72 +-
 src/mesa/state_tracker/st_program.h|  4 ++
 3 files changed, 44 insertions(+), 36 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_program.c 
b/src/mesa/state_tracker/st_cb_program.c
index 3029909..745b447 100644
--- a/src/mesa/state_tracker/st_cb_program.c
+++ b/src/mesa/state_tracker/st_cb_program.c
@@ -249,7 +249,9 @@ st_program_string_notify( struct gl_context *ctx,
else if (target == GL_VERTEX_PROGRAM_ARB) {
   struct st_vertex_program *stvp = (struct st_vertex_program *) prog;
 
-  st_release_vp_variants( st, stvp );
+  st_release_vp_variants(st, stvp);
+  if (!st_translate_vertex_program(st, stvp))
+ return false;
 
   if (st->vp == stvp)
 st->dirty.st |= ST_NEW_VERTEX_PROGRAM;
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 95ad2f4..4bdbf85 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -94,6 +94,11 @@ st_release_vp_variants( struct st_context *st,
}
 
stvp->variants = NULL;
+
+   if (stvp->tgsi.tokens) {
+  tgsi_free_tokens(stvp->tgsi.tokens);
+  stvp->tgsi.tokens = NULL;
+   }
 }
 
 
@@ -230,15 +235,12 @@ st_release_tep_variants(struct st_context *st, struct 
st_tesseval_program *sttep
 
 
 /**
- * Translate a vertex program to create a new variant.
+ * Translate a vertex program.
  */
-static struct st_vp_variant *
+bool
 st_translate_vertex_program(struct st_context *st,
-struct st_vertex_program *stvp,
-const struct st_vp_variant_key *key)
+struct st_vertex_program *stvp)
 {
-   struct st_vp_variant *vpv = CALLOC_STRUCT(st_vp_variant);
-   struct pipe_context *pipe = st->pipe;
struct ureg_program *ureg;
enum pipe_error error;
unsigned num_outputs = 0;
@@ -372,12 +374,8 @@ st_translate_vertex_program(struct st_context *st,
   _mesa_remove_output_reads(>Base.Base, PROGRAM_OUTPUT);
 
ureg = ureg_create_with_screen(TGSI_PROCESSOR_VERTEX, st->pipe->screen);
-   if (ureg == NULL) {
-  free(vpv);
-  return NULL;
-   }
-
-   vpv->key = *key;
+   if (ureg == NULL)
+  return false;
 
if (ST_DEBUG & DEBUG_MESA) {
   _mesa_print_program(>Base.Base);
@@ -385,7 +383,7 @@ st_translate_vertex_program(struct st_context *st,
   debug_printf("\n");
}
 
-   if (stvp->glsl_to_tgsi)
+   if (stvp->glsl_to_tgsi) {
   error = st_translate_program(st->ctx,
TGSI_PROCESSOR_VERTEX,
ureg,
@@ -405,7 +403,11 @@ st_translate_vertex_program(struct st_context *st,
output_slot_to_attr,
output_semantic_name,
output_semantic_index);
-   else
+
+  st_translate_stream_output_info(stvp->glsl_to_tgsi,
+  stvp->result_to_output,
+  >tgsi.stream_output);
+   } else
   error = st_translate_mesa_program(st->ctx,
 TGSI_PROCESSOR_VERTEX,
 ureg,
@@ -422,21 +424,29 @@ st_translate_vertex_program(struct st_context *st,
 output_semantic_name,
 output_semantic_index);
 
-   if (error)
-  goto fail;
-
-   vpv->tgsi.tokens = ureg_get_tokens( ureg, NULL );
-   if (!vpv->tgsi.tokens)
-  goto fail;
+   if (error) {
+  debug_printf("%s: failed to translate Mesa program:\n", __func__);
+  _mesa_print_program(>Base.Base);
+  debug_assert(0);
+  return false;
+   }
 
-   ureg_destroy( ureg );
+   stvp->tgsi.tokens = ureg_get_tokens(ureg, NULL);
+   ureg_destroy(ureg);
+   return stvp->tgsi.tokens != NULL;
+}
 
-   if (stvp->glsl_to_tgsi) {
-  st_translate_stream_output_info(stvp->glsl_to_tgsi,
-  stvp->result_to_output,
-  >tgsi.stream_output);
-   }
+static struct st_vp_variant *
+st_create_vp_variant(struct st_context *st,
+ struct st_vertex_program *stvp,
+ const struct st_vp_variant_key *key)
+{
+   struct st_vp_variant *vpv = CALLOC_STRUCT(st_vp_variant);
+   struct pipe_context *pipe = st->pipe;
 
+   vpv->key = *key;
+   vpv->tgsi.tokens = tgsi_dup_tokens(stvp->tgsi.tokens);
+   vpv->tgsi.stream_output = stvp->tgsi.stream_output;
vpv->num_inputs = stvp->num_inputs;
 
/* Emulate features. */
@@ -465,14 +475,6 @@ st_translate_vertex_program(struct st_context *st,
 
vpv->driver_shader = pipe->create_vs_state(pipe,

[Mesa-dev] [PATCH 05/17] st/mesa: decrease the size of st_vertex_program

From: Marek Olšák 

The other variables can't be moved.
---
 src/mesa/state_tracker/st_program.c | 94 +++--
 src/mesa/state_tracker/st_program.h |  5 --
 2 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 63ffad7..9e100db 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -239,11 +239,14 @@ st_translate_vertex_program(struct st_context *st,
struct pipe_context *pipe = st->pipe;
struct ureg_program *ureg;
enum pipe_error error;
-   unsigned num_outputs;
-   GLuint attr;
+   unsigned num_outputs = 0;
+   unsigned attr;
+   unsigned input_to_index[VERT_ATTRIB_MAX] = {0};
+   unsigned output_slot_to_attr[VARYING_SLOT_MAX] = {0};
+   ubyte output_semantic_name[VARYING_SLOT_MAX] = {0};
+   ubyte output_semantic_index[VARYING_SLOT_MAX] = {0};
 
stvp->num_inputs = 0;
-   stvp->num_outputs = 0;
 
if (stvp->Base.IsPositionInvariant)
   _mesa_insert_mvp_code(st->ctx, >Base);
@@ -254,7 +257,7 @@ st_translate_vertex_program(struct st_context *st,
 */
for (attr = 0; attr < VERT_ATTRIB_MAX; attr++) {
   if ((stvp->Base.Base.InputsRead & BITFIELD64_BIT(attr)) != 0) {
- stvp->input_to_index[attr] = stvp->num_inputs;
+ input_to_index[attr] = stvp->num_inputs;
  stvp->index_to_input[stvp->num_inputs] = attr;
  stvp->num_inputs++;
  if ((stvp->Base.Base.DoubleInputsRead & BITFIELD64_BIT(attr)) != 0) {
@@ -265,7 +268,7 @@ st_translate_vertex_program(struct st_context *st,
   }
}
/* bit of a hack, presetup potentially unused edgeflag input */
-   stvp->input_to_index[VERT_ATTRIB_EDGEFLAG] = stvp->num_inputs;
+   input_to_index[VERT_ATTRIB_EDGEFLAG] = stvp->num_inputs;
stvp->index_to_input[stvp->num_inputs] = VERT_ATTRIB_EDGEFLAG;
 
/* Compute mapping of vertex program outputs to slots.
@@ -275,62 +278,62 @@ st_translate_vertex_program(struct st_context *st,
  stvp->result_to_output[attr] = ~0;
   }
   else {
- unsigned slot = stvp->num_outputs++;
+ unsigned slot = num_outputs++;
 
  stvp->result_to_output[attr] = slot;
- stvp->output_slot_to_attr[slot] = attr;
+ output_slot_to_attr[slot] = attr;
 
  switch (attr) {
  case VARYING_SLOT_POS:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_POSITION;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_POSITION;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_COL0:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_COLOR;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_COLOR;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_COL1:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_COLOR;
-stvp->output_semantic_index[slot] = 1;
+output_semantic_name[slot] = TGSI_SEMANTIC_COLOR;
+output_semantic_index[slot] = 1;
 break;
  case VARYING_SLOT_BFC0:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_BCOLOR;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_BCOLOR;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_BFC1:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_BCOLOR;
-stvp->output_semantic_index[slot] = 1;
+output_semantic_name[slot] = TGSI_SEMANTIC_BCOLOR;
+output_semantic_index[slot] = 1;
 break;
  case VARYING_SLOT_FOGC:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_FOG;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_FOG;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_PSIZ:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_PSIZE;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_PSIZE;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_CLIP_DIST0:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_CLIPDIST;
-stvp->output_semantic_index[slot] = 0;
+output_semantic_name[slot] = TGSI_SEMANTIC_CLIPDIST;
+output_semantic_index[slot] = 0;
 break;
  case VARYING_SLOT_CLIP_DIST1:
-stvp->output_semantic_name[slot] = TGSI_SEMANTIC_CLIPDIST;
-stvp->output_semantic_index[slot] = 1;
+output_semantic_name[slot] = TGSI_SEMANTIC_CLIPDIST;
+output_semantic_index[slot] = 1;
 break;
  case VARYING_SLOT_EDGE:

[Mesa-dev] [PATCH 12/17] st/mesa: fix glDrawPixels with a texture

From: Marek Olšák 

The samplers for DrawPixels data and the pixel map are assigned to slots
which don't overlap with the existing sampler slots.

The texture coordinates for the user texture are uploaded as a constant.
---
 src/mesa/state_tracker/st_cb_drawpixels.c| 52 +-
 src/mesa/state_tracker/st_cb_drawpixels.h|  4 +-
 src/mesa/state_tracker/st_cb_drawpixels_shader.c | 55 +---
 src/mesa/state_tracker/st_program.c  | 25 ++-
 src/mesa/state_tracker/st_program.h  |  4 ++
 5 files changed, 111 insertions(+), 29 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index a08c0b2..cc2c885 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -535,6 +535,7 @@ draw_textured_quad(struct gl_context *ctx, GLint x, GLint 
y, GLfloat z,
int num_sampler_view,
void *driver_vp,
void *driver_fp,
+   struct st_fp_variant *fpv,
const GLfloat *color,
GLboolean invertTex,
GLboolean write_depth, GLboolean write_stencil)
@@ -622,10 +623,9 @@ draw_textured_quad(struct gl_context *ctx, GLint x, GLint 
y, GLfloat z,
cso_set_tesseval_shader_handle(cso, NULL);
cso_set_geometry_shader_handle(cso, NULL);
 
-   /* texture sampling state: */
+   /* user samplers, plus the drawpix samplers */
{
   struct pipe_sampler_state sampler;
-  const struct pipe_sampler_state *states[2] = {, };
 
   memset(, 0, sizeof(sampler));
   sampler.wrap_s = PIPE_TEX_WRAP_CLAMP;
@@ -636,8 +636,25 @@ draw_textured_quad(struct gl_context *ctx, GLint x, GLint 
y, GLfloat z,
   sampler.mag_img_filter = PIPE_TEX_FILTER_NEAREST;
   sampler.normalized_coords = normalized;
 
-  cso_set_samplers(cso, PIPE_SHADER_FRAGMENT,
-   num_sampler_view > 1 ? 2 : 1, states);
+  if (fpv) {
+ const struct pipe_sampler_state *samplers[PIPE_MAX_SAMPLERS];
+ uint num = MAX2(MAX2(fpv->drawpix_sampler, fpv->pixelmap_sampler) + 1,
+ st->state.num_samplers[PIPE_SHADER_FRAGMENT]);
+ uint i;
+
+ for (i = 0; i < st->state.num_samplers[PIPE_SHADER_FRAGMENT]; i++)
+samplers[i] = >state.samplers[PIPE_SHADER_FRAGMENT][i];
+
+ samplers[fpv->drawpix_sampler] = 
+ if (sv[1])
+samplers[fpv->pixelmap_sampler] = 
+
+ cso_set_samplers(cso, PIPE_SHADER_FRAGMENT, num, samplers);
+  } else {
+ const struct pipe_sampler_state *samplers[2] = {, };
+
+ cso_set_samplers(cso, PIPE_SHADER_FRAGMENT, num_sampler_view, 
samplers);
+  }
}
 
/* viewport state: viewport matching window dims */
@@ -657,8 +674,21 @@ draw_textured_quad(struct gl_context *ctx, GLint x, GLint 
y, GLfloat z,
cso_set_vertex_elements(cso, 3, st->velems_util_draw);
cso_set_stream_outputs(st->cso_context, 0, NULL, NULL);
 
-   /* texture state: */
-   cso_set_sampler_views(cso, PIPE_SHADER_FRAGMENT, num_sampler_view, sv);
+   /* user textures, plus the drawpix textures */
+   if (fpv) {
+  struct pipe_sampler_view *sampler_views[PIPE_MAX_SAMPLERS];
+  uint num = MAX2(MAX2(fpv->drawpix_sampler, fpv->pixelmap_sampler) + 1,
+  st->state.num_sampler_views[PIPE_SHADER_FRAGMENT]);
+
+  memcpy(sampler_views, st->state.sampler_views[PIPE_SHADER_FRAGMENT],
+ sizeof(sampler_views));
+
+  sampler_views[fpv->drawpix_sampler] = sv[0];
+  if (sv[1])
+ sampler_views[fpv->pixelmap_sampler] = sv[1];
+  cso_set_sampler_views(cso, PIPE_SHADER_FRAGMENT, num, sampler_views);
+   } else
+  cso_set_sampler_views(cso, PIPE_SHADER_FRAGMENT, num_sampler_view, sv);
 
/* Compute Gallium window coords (y=0=top) with pixel zoom.
 * Recall that these coords are transformed by the current
@@ -953,6 +983,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
struct pipe_sampler_view *sv[2] = { NULL };
int num_sampler_view = 1;
struct gl_pixelstore_attrib clippedUnpack;
+   struct st_fp_variant *fpv = NULL;
 
/* Mesa state should be up to date by now */
assert(ctx->NewState == 0x0);
@@ -992,7 +1023,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   color = ctx->Current.RasterColor;
}
else {
-  struct st_fp_variant *fpv = get_color_fp_variant(st);
+  fpv = get_color_fp_variant(st);
 
   driver_fp = fpv->driver_shader;
   driver_vp = make_passthrough_vertex_shader(st, GL_FALSE);
@@ -1035,7 +1066,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
sv,
num_sampler_view,
driver_vp,
-   driver_fp,
+   driver_fp, fpv,

[Mesa-dev] [PATCH 01/17] mesa: call ProgramStringNotify for fixed-function vertex programs

From: Marek Olšák 

Drivers weren't notified about this at all.
This allows disabling on-demand compilation in drivers.
---
 src/mesa/main/ffvertex_prog.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index a6183b4..34cc921 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1690,11 +1690,10 @@ _mesa_get_fixed_func_vertex_program(struct gl_context 
*ctx)
   
ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS,
   ctx->Const.Program[MESA_SHADER_VERTEX].MaxTemps );
 
-#if 0
   if (ctx->Driver.ProgramStringNotify)
  ctx->Driver.ProgramStringNotify( ctx, GL_VERTEX_PROGRAM_ARB,
   >Base );
-#endif
+
   _mesa_program_cache_insert(ctx, ctx->VertexProgram.Cache,
  , sizeof(key), >Base);
}
-- 
2.1.4

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

[Mesa-dev] [PATCH 07/17] st/mesa: use TGSI utility to emulate features for FS variants

From: Marek Olšák 

---
 src/mesa/state_tracker/st_program.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 6ace352..bf6b492 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -620,8 +620,7 @@ st_translate_fragment_program(struct st_context *st,
 interpLocation[slot] = TGSI_INTERPOLATE_LOC_CENTER;
 
  if (stfp->Base.Base.SystemValuesRead & (SYSTEM_BIT_SAMPLE_ID |
- SYSTEM_BIT_SAMPLE_POS) ||
- key->persample_shading)
+ SYSTEM_BIT_SAMPLE_POS))
 interpLocation[slot] = TGSI_INTERPOLATE_LOC_SAMPLE;
 
  switch (attr) {
@@ -861,7 +860,7 @@ st_translate_fragment_program(struct st_context *st,
NULL,
fs_output_semantic_name,
fs_output_semantic_index, FALSE,
-   key->clamp_color );
+   false);
else
   st_translate_mesa_program(st->ctx,
 TGSI_PROCESSOR_FRAGMENT,
@@ -878,10 +877,26 @@ st_translate_fragment_program(struct st_context *st,
 outputMapping,
 fs_output_semantic_name,
 fs_output_semantic_index, FALSE,
-key->clamp_color);
+false);
 
-   variant->tgsi.tokens = ureg_get_tokens( ureg, NULL );
-   ureg_destroy( ureg );
+   variant->tgsi.tokens = ureg_get_tokens(ureg, NULL);
+   ureg_destroy(ureg);
+
+   /* Emulate features. */
+   if (key->clamp_color || key->persample_shading) {
+  const struct tgsi_token *tokens;
+  unsigned flags =
+ (key->clamp_color ? TGSI_EMU_CLAMP_COLOR_OUTPUTS : 0) |
+ (key->persample_shading ? TGSI_EMU_FORCE_PERSAMPLE_INTERP : 0);
+
+  tokens = tgsi_emulate(variant->tgsi.tokens, flags);
+
+  if (tokens) {
+ tgsi_free_tokens(variant->tgsi.tokens);
+ variant->tgsi.tokens = tokens;
+  } else
+ fprintf(stderr, "mesa: cannot emulate deprecated features\n");
+   }
 
if (ST_DEBUG & DEBUG_TGSI) {
   tgsi_dump(variant->tgsi.tokens, 0/*TGSI_DUMP_VERBOSE*/);
-- 
2.1.4

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

[Mesa-dev] [PATCH 02/17] tgsi: add a utility for emulating some GL features

From: Marek Olšák 

st/mesa will use this, but drivers can use it too.
---
 src/gallium/auxiliary/Makefile.sources|   2 +
 src/gallium/auxiliary/tgsi/tgsi_emulate.c | 168 ++
 src/gallium/auxiliary/tgsi/tgsi_emulate.h |  38 +++
 3 files changed, 208 insertions(+)
 create mode 100644 src/gallium/auxiliary/tgsi/tgsi_emulate.c
 create mode 100644 src/gallium/auxiliary/tgsi/tgsi_emulate.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 1fa3641..9df4e26 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -137,6 +137,8 @@ C_SOURCES := \
tgsi/tgsi_dump.h \
tgsi/tgsi_exec.c \
tgsi/tgsi_exec.h \
+   tgsi/tgsi_emulate.c \
+   tgsi/tgsi_emulate.h \
tgsi/tgsi_info.c \
tgsi/tgsi_info.h \
tgsi/tgsi_iterate.c \
diff --git a/src/gallium/auxiliary/tgsi/tgsi_emulate.c 
b/src/gallium/auxiliary/tgsi/tgsi_emulate.c
new file mode 100644
index 000..8190872
--- /dev/null
+++ b/src/gallium/auxiliary/tgsi/tgsi_emulate.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE
+ * SOFTWARE.
+ *
+ */
+
+#include "tgsi/tgsi_transform.h"
+#include "tgsi/tgsi_scan.h"
+#include "tgsi/tgsi_dump.h"
+#include "util/u_debug.h"
+
+#include "tgsi_emulate.h"
+
+struct tgsi_emulation_context {
+   struct tgsi_transform_context base;
+   struct tgsi_shader_info info;
+   unsigned flags;
+   bool first_instruction_emitted;
+};
+
+static inline struct tgsi_emulation_context *
+tgsi_emulation_context(struct tgsi_transform_context *tctx)
+{
+   return (struct tgsi_emulation_context *)tctx;
+}
+
+static void
+transform_decl(struct tgsi_transform_context *tctx,
+   struct tgsi_full_declaration *decl)
+{
+   struct tgsi_emulation_context *ctx = tgsi_emulation_context(tctx);
+
+   if (ctx->flags & TGSI_EMU_FORCE_PERSAMPLE_INTERP &&
+   decl->Declaration.File == TGSI_FILE_INPUT) {
+  assert(decl->Declaration.Interpolate);
+  decl->Interp.Location = TGSI_INTERPOLATE_LOC_SAMPLE;
+   }
+
+   tctx->emit_declaration(tctx, decl);
+}
+
+static void
+passthrough_edgeflag(struct tgsi_transform_context *tctx)
+{
+   struct tgsi_emulation_context *ctx = tgsi_emulation_context(tctx);
+   struct tgsi_full_declaration decl;
+   struct tgsi_full_instruction new_inst;
+
+   /* Input */
+   decl = tgsi_default_full_declaration();
+   decl.Declaration.File = TGSI_FILE_INPUT;
+   decl.Range.First = decl.Range.Last = ctx->info.num_inputs;
+   tctx->emit_declaration(tctx, );
+
+   /* Output */
+   decl = tgsi_default_full_declaration();
+   decl.Declaration.File = TGSI_FILE_OUTPUT;
+   decl.Declaration.Semantic = true;
+   decl.Range.First = decl.Range.Last = ctx->info.num_outputs;
+   decl.Semantic.Name = TGSI_SEMANTIC_EDGEFLAG;
+   decl.Semantic.Index = 0;
+   tctx->emit_declaration(tctx, );
+
+   /* MOV */
+   new_inst = tgsi_default_full_instruction();
+   new_inst.Instruction.Opcode = TGSI_OPCODE_MOV;
+
+   new_inst.Instruction.NumDstRegs = 1;
+   new_inst.Dst[0].Register.File  = TGSI_FILE_OUTPUT;
+   new_inst.Dst[0].Register.Index = ctx->info.num_outputs;
+   new_inst.Dst[0].Register.WriteMask = TGSI_WRITEMASK_XYZW;
+
+   new_inst.Instruction.NumSrcRegs = 1;
+   new_inst.Src[0].Register.File  = TGSI_FILE_INPUT;
+   new_inst.Src[0].Register.Index = ctx->info.num_inputs;
+   new_inst.Src[0].Register.SwizzleX = TGSI_SWIZZLE_X;
+   new_inst.Src[0].Register.SwizzleY = TGSI_SWIZZLE_X;
+   new_inst.Src[0].Register.SwizzleZ = TGSI_SWIZZLE_X;
+   new_inst.Src[0].Register.SwizzleW = TGSI_SWIZZLE_X;
+
+   tctx->emit_instruction(tctx, _inst);
+}
+
+static void
+transform_instr(struct tgsi_transform_context *tctx,
+   struct tgsi_full_instruction *inst)
+{
+   struct tgsi_emulation_context *ctx =

[Mesa-dev] [PATCH 00/17] Rework Mesa/ST shader compilation logic (Part 1)

Hi,

This is a start of reworking how st/mesa translates and creates shaders. The 
result of this patch series is this:

In LinkShader or ProgramStringNotify, the shader is translated to TGSI as-is. 
There are no shader code modifications for shader variants. The glsl-to-tgsi 
visitor is released.

We can't release the GLSL IR at this point yet, because core Mesa needs it for 
program resource queries at least.

That's the only place st/mesa interacts with Mesa IR and GLSL IR. After that, 
it only works with the TGSI representation.

When we get to a draw call, tgsi_transform_shader is used to modify shaders to 
produce shader variants. It does:
- feature emulation (color clamping, per-sample shading, edgeflags)
- adding glDrawPixels shader code
- adding glBitmap shader code

All the shader transformations are rewritten completely. There is no patching 
with Mesa IR or glsl-to-tgsi anymore.

It shouldn't be so difficult to add support for some new IR or phase out Mesa 
IR and GLSL IR support at some point.

The main motivations for this series are:
- translate to TGSI as soon as possible
- possibility to create gallium shaders after that if drivers don't need many 
variants
- if variants are needed, the path to get them is much simpler

There will be part 2 when it's ready.

Please review. Thanks.

 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/tgsi/tgsi_emulate.c| 168 
+
 src/gallium/auxiliary/tgsi/tgsi_emulate.h|  38 +++
 src/gallium/auxiliary/tgsi/tgsi_scan.c   |   2 +
 src/gallium/auxiliary/tgsi/tgsi_scan.h   |   1 +
 src/mesa/Makefile.sources|   2 +
 src/mesa/main/ffvertex_prog.c|   3 +-
 src/mesa/state_tracker/st_atom_pixeltransfer.c   | 225 
++-
 src/mesa/state_tracker/st_cb_bitmap.c| 145 
-
 src/mesa/state_tracker/st_cb_bitmap.h|  11 +-
 src/mesa/state_tracker/st_cb_bitmap_shader.c | 174 
++
 src/mesa/state_tracker/st_cb_drawpixels.c| 349 
+++-
 src/mesa/state_tracker/st_cb_drawpixels.h|  17 ++-
 src/mesa/state_tracker/st_cb_drawpixels_shader.c | 278 

 src/mesa/state_tracker/st_cb_program.c   |  12 ++-
 src/mesa/state_tracker/st_context.c  |   6 +-
 src/mesa/state_tracker/st_context.h  |   9 +-
 src/mesa/state_tracker/st_debug.c|   2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 258 
+---
 src/mesa/state_tracker/st_glsl_to_tgsi.h |  10 +-
 src/mesa/state_tracker/st_mesa_to_tgsi.c |  50 +
 src/mesa/state_tracker/st_mesa_to_tgsi.h |   4 +-
 src/mesa/state_tracker/st_program.c  | 566 
+
 src/mesa/state_tracker/st_program.h  |  47 
 24 files changed, 1178 insertions(+), 1201 deletions(-)

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

Re: [Mesa-dev] [PATCH] mesa/state_tracker: Fix draw-pixel-with-texture piglit test.

2015-10-05 Thread Matthew Dawson

On October 5, 2015 03:11:16 AM Marek Olšák wrote:
> Thank you for the patch, but it's not applicable on my (private)
> branch where I'm reworking st/mesa's shader compilation, including
> DrawPixels shaders. Your patch helped to fix it in the new
> implementation at least.
> 
> Sorry for ignoring it in the first place.
Glad to hear it helped at least.  I had a patch against piglit as well that 
made the draw-pixel-with-texture test better test the various functionality, 
but I don't believe that has been merged yet either.  Would you be able to 
pull that patch at least?
-- 
Matthew

smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/state_tracker: Fix draw-pixel-with-texture piglit test.

On Mon, Oct 5, 2015 at 11:27 PM, Matthew Dawson  wrote:
> On October 5, 2015 03:11:16 AM Marek Olšák wrote:
>> Thank you for the patch, but it's not applicable on my (private)
>> branch where I'm reworking st/mesa's shader compilation, including
>> DrawPixels shaders. Your patch helped to fix it in the new
>> implementation at least.
>>
>> Sorry for ignoring it in the first place.
> Glad to hear it helped at least.  I had a patch against piglit as well that
> made the draw-pixel-with-texture test better test the various functionality,
> but I don't believe that has been merged yet either.  Would you be able to
> pull that patch at least?

Yes, I've added it to my queue of things to look at. :)

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

[Mesa-dev] [PATCH] mesa: Remove GL_ARB_sampler_object depth compare error checking.

2015-10-05 Thread Stefan Dösinger

Version 3: Simplify the code comment, word wrap commit description.

Version 2: Return GL_FALSE if ARB_shadow is unsupported instead of
pretending to store the value as suggested by Brian Paul.

This fixes a GL error warning on r200 in Wine.

The GL_ARB_sampler_objects extension does not specify a dependency on
GL_ARB_shadow or GL_ARB_depth_texture for setting the depth texture
compare mode and function. Silently ignore attempts to change these
settings. They won't matter without a depth texture being assigned
anyway.
---
 src/mesa/main/samplerobj.c | 28 ++--
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index 9bcba60..676dd36 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -621,8 +621,12 @@ static GLuint
 set_sampler_compare_mode(struct gl_context *ctx,
  struct gl_sampler_object *samp, GLint param)
 {
+/* If GL_ARB_shadow is not supported, don't report an error.  The
+ * sampler object extension spec isn't clear on this extension interaction.
+ * Silences errors with Wine on older GPUs such as R200.
+ */
if (!ctx->Extensions.ARB_shadow)
-  return INVALID_PNAME;
+  return GL_FALSE;
 
if (samp->CompareMode == param)
   return GL_FALSE;
@@ -642,8 +646,12 @@ static GLuint
 set_sampler_compare_func(struct gl_context *ctx,
  struct gl_sampler_object *samp, GLint param)
 {
+/* If GL_ARB_shadow is not supported, don't report an error.  The
+ * sampler object extension spec isn't clear on this extension interaction.
+ * Silences errors with Wine on older GPUs such as R200.
+ */
if (!ctx->Extensions.ARB_shadow)
-  return INVALID_PNAME;
+  return GL_FALSE;
 
if (samp->CompareFunc == param)
   return GL_FALSE;
@@ -1329,13 +1337,9 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
pname, GLint *params)
   *params = IROUND(sampObj->LodBias);
   break;
case GL_TEXTURE_COMPARE_MODE:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareMode;
   break;
case GL_TEXTURE_COMPARE_FUNC:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareFunc;
   break;
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
@@ -1418,13 +1422,9 @@ _mesa_GetSamplerParameterfv(GLuint sampler, GLenum 
pname, GLfloat *params)
   *params = sampObj->LodBias;
   break;
case GL_TEXTURE_COMPARE_MODE:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = (GLfloat) sampObj->CompareMode;
   break;
case GL_TEXTURE_COMPARE_FUNC:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = (GLfloat) sampObj->CompareFunc;
   break;
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
@@ -1497,13 +1497,9 @@ _mesa_GetSamplerParameterIiv(GLuint sampler, GLenum 
pname, GLint *params)
   *params = (GLint) sampObj->LodBias;
   break;
case GL_TEXTURE_COMPARE_MODE:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareMode;
   break;
case GL_TEXTURE_COMPARE_FUNC:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareFunc;
   break;
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
@@ -1576,13 +1572,9 @@ _mesa_GetSamplerParameterIuiv(GLuint sampler, GLenum 
pname, GLuint *params)
   *params = (GLuint) sampObj->LodBias;
   break;
case GL_TEXTURE_COMPARE_MODE:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareMode;
   break;
case GL_TEXTURE_COMPARE_FUNC:
-  if (!ctx->Extensions.ARB_shadow)
- goto invalid_pname;
   *params = sampObj->CompareFunc;
   break;
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
-- 
2.4.9

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

Re: [Mesa-dev] [RFC] ARB_shader_clock, hardware counters and i965

2015-10-05 Thread Connor Abbott

On Mon, Oct 5, 2015 at 1:06 PM, Emil Velikov  wrote:
> On 5 October 2015 at 17:11, Connor Abbott  wrote:
>> On Mon, Oct 5, 2015 at 11:36 AM, Emil Velikov  
>> wrote:
>>> Hi all,
>>>
>>> I am looking at ARB_shader_clock with i965 in mind.
>>>
>>> So far I've got the most of the infra/plumbing, and a fancy a new intrinsic 
>>> :)
>>>
>>> On the hardware side, I was thinking about using the Observability
>>> Architecture (OA) counters. The fun part is that those tend to vary
>>> quite a bit based on the hardware generation. So far I'm leaning
>>> towards:
>>>  - "Count of XXX threads dispatched to EUs" for BRW and later.
>>>  - "XXX Shader Active Time" for earlier (SNB-HSW/VLV) hardware.
>>>
>>> Do there sound appropriate, or should we opt for the various knobs in
>>> 'Flexible EU event counters' ? Is there some alternative piece of
>>> hardware in i965, which I can use ?
>>>
>>>
>>> Going for OA has a small catch. Reading through the PRM, it is not
>>> obvious if one can track the same source twice (the
>>> GL_AMD_performance_monitor implementation comes to mind). I'm about to
>>> take a closer look into brw_performance_monitor.[ch] shortly, but if
>>> any gotchas/fancy interactions come to mind let me know.
>>>
>>> Thanks
>>> Emil
>>>
>>> P.S. Does anyone recall the consensus wrt adding the 2015 extensions
>>> to GL3.txt ?
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> Hi Emil,
>>
>> I don't think you want to use the OA counters to implement
>> ARB_shader_clock. They're not exposed to the shader directly, AFAIK,
>> and they only measure things on a per-invocation granularity, whereas
>> the intent of ARB_shader_clock is to be able to measure the number of
>> cycles that individual operations take with very low latency. Instead,
>> you should read from the ARF performance register -- see page 822 of
>> Vol 7 ("3D Media GPGPU") of the Broadwell PRM (page 858 of the PDF)
>> for more details.
>>
> I knew that there should be nicer piece of hardware for this, but
> could not find it looking through the spec. The timestamp register
> looks exactly like the thing we need there.
>
>> Another interesting thing is that you can atomically read from that
>> register and also get a bit that say whether there was some event,
>> such as a context switch, since the last time you read it that would
>> make your measurement invalid. It might be useful to expose this
>> through a GLSL extension as another set of overloads:
>>
>> uint64_t clockARB(out bool valid); //once we get int64 support
>> uvec2 clock2x32ARB(out bool valid);
>>
> Are you thinking about writing up another extension, or should we just
> wire things internally as someone else does it for us ? Would you have
> any preference how to handle things when a context switch has occurred
> (for the official functions) ?

I was thinking about adding a new extension; AFAIK no one else has
exposed this in an extension before, but at least Intel HW has it. If
by "the official functions" you mean the ones in ARB_shader_clock,
then they should just read the register without worrying about whether
there was a context switch or not. They should still reset the "is
this valid" state though, since that's what the HW does and it makes
sense for cases like the example below.

>
>> and a corresponding NIR intrinsic that outputs an extra component
>> that's a boolean (i.e. 0 or ~0). That would help with implementing
>> something like INTEL_DEBUG=shader_time generically with less outliers
>> to throw away.
>>
> Exposing it via INTEL_DEBUG will be great, but first I'd stick getting
> the extension bits in place.

Oh no, I meant replacing it entirely. That is, we'd have something
above Mesa or in core Mesa that inserts code like:

layout(binding = 0, std430) buffer {
   uint time[];
};

layout(binding = 1, offset = 0) uniform atomic_uint idx;

void main() {
   uint46_t start = clockARB(); //using uint64 for brevity even if we
don't support it now
   ... //the original shader
   bool valid;
   uint64_t end = clockARB(valid);
   if (valid && end > start) {
  time[atomicCounterIncrement(idx)] = end - start;
   }
}

and we could rip out all the code inside i965 to implement
INTEL_DEBUG=shader_time, which is fragile and often in the way of
refactors.

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

[Mesa-dev] [Bug 92221] Unintended code changes in _mesa_base_tex_format commit

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

--- Comment #4 from Nanley Chery  ---
(In reply to Nanley Chery from comment #2)
> (In reply to Mark Janes from comment #1)
> > Nanley, should there have been a piglit failure associated with ASTC
> > functionality that was disabled?
> 
> Not at the moment. The tests are still on the list and haven't been merged
> to master. Some others developers and I are working to get them integrated.

The tests are now integrated into piglit.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: remove unneeded error check in create_textures()

2015-10-05 Thread Mark Janes

I tested this patch and found:

regressions:
  spec.arb_shader_storage_buffer_object.layout-std140-write-shader  (BDW only)
expected[1] = 1.00. Read value: 0.00

  spec.arb_copy_image.arb_copy_image-srgb-copy  (assertion)
arb_copy_image-srgb-copy: src/mesa/main/texobj.c:1739:
  _mesa_BindTexture: Assertion `newTexObj->TargetIndex == targetIndex'
  failed.

fixes:
  spec.!opengl 1_0.gl-1.0-beginend-coverage
  spec.!opengl 1_0.gl-1.0-no-op-paths
  spec.arb_copy_image.arb_copy_image-formats

-Mark

Brian Paul  writes:

> Callers of create_texture() will either pass target=0 or a validated
> GL texture target enum so no need to do another error check inside
> the loop.
> ---
>  src/mesa/main/texobj.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
> index 173e43c..aa4b38c 100644
> --- a/src/mesa/main/texobj.c
> +++ b/src/mesa/main/texobj.c
> @@ -1211,6 +1211,7 @@ _mesa_create_nameless_texture(struct gl_context *ctx, 
> GLenum target)
>   * glCreateTextures should throw errors if target = 0. This is not exposed to
>   * the rest of Mesa to encourage Mesa internals to use nameless textures,
>   * which do not require expensive hash lookups.
> + * \param target  either 0 or a a valid / error-checked texture target enum
>   */
>  static void
>  create_textures(struct gl_context *ctx, GLenum target,
> @@ -1219,6 +1220,7 @@ create_textures(struct gl_context *ctx, GLenum target,
> GLuint first;
> GLint i;
> const char *func = dsa ? "Create" : "Gen";
> +   const GLint targetIndex = _mesa_tex_target_to_index(ctx, target);
>  
> if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
>_mesa_debug(ctx, "gl%sTextures %d\n", func, n);
> @@ -1241,7 +1243,6 @@ create_textures(struct gl_context *ctx, GLenum target,
> /* Allocate new, empty texture objects */
> for (i = 0; i < n; i++) {
>struct gl_texture_object *texObj;
> -  GLint targetIndex;
>GLuint name = first + i;
>texObj = ctx->Driver.NewTextureObject(ctx, name, target);
>if (!texObj) {
> @@ -1252,14 +1253,6 @@ create_textures(struct gl_context *ctx, GLenum target,
>  
>/* Initialize the target index if target is non-zero. */
>if (target != 0) {
> - targetIndex = _mesa_tex_target_to_index(ctx, texObj->Target);
> - if (targetIndex < 0) { /* Bad Target */
> -mtx_unlock(>Shared->Mutex);
> -_mesa_error(ctx, GL_INVALID_ENUM, "gl%sTextures(target = %s)",
> -func, _mesa_enum_to_string(texObj->Target));
> -return;
> - }
> - assert(targetIndex < NUM_TEXTURE_TARGETS);
>   texObj->TargetIndex = targetIndex;
>}
>  
> -- 
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/3] V2: Improve GLSL support of GL_ARB_separate_shader_objects

2015-10-05 Thread gregory hainaut

On Sat, 3 Oct 2015 11:59:49 +0200
gregory hainaut  wrote:

> On Sat, 03 Oct 2015 09:35:49 +
> Mike Lothian  wrote:
> 
> > Would it be better to have is_interstage=0 rather than a double negative?
> > 
> Yes. I think it just need to set 1 in the constructor (forget to 
> update it by the way...) as default value. Otherwise it can be 
> renamed to is_unlinked_io (or something similar).
> 
> > 
> > > > In short, SSO allow to match by name but you can't make any hypothesis
> > > on the
> > > > previous/next stage. Therefore you must consider all inputs and output 
> > > > as
> > > > actives.
> > >
> > > New version based on Ian's feedbacks.
> > > * Real interstage variables of the program are still optimized
> > > * Both output and input of the program remains active
> > > * An old bug still remains if name and explicit location rendezvous are
> > > mixed
> > >
> > > Commits decription:
> > > 1/ add a not_interstage parameter that will be 1 when variable is either 
> > > an
> > >input of output of the program. I didn't know where to put the
> > > ir_set_not_interstage_io
> > >function. Maybe it can be moved in linker.cpp.
> > > 2/ Set the interstage parameter based on the shader position in the
> > > pipeline
> > >program. Potentially can be squased with the previous one.
> > > 3/ Don't do deadcode removal of not_interstage variable with the exception
> > >of the built-in varyings because they don't impact location of others
> > > variables
> > >
> > > Gregory Hainaut (4):
> > >   glsl IR: add not_interstage attribute to ir_variable
> > >   glsl link: annotate not_interstage attribute of the ir_var after link
> > > phase
> > >   glsl IR: only allow optimization of interstage variable
> > >   allow compilation on my system
> > >
> > >  configure.ac   |  6 --
> > >  src/glsl/ir.h  |  6 ++
> > >  src/glsl/ir_optimization.h |  2 ++
> > >  src/glsl/linker.cpp| 47
> > > ++
> > >  src/glsl/opt_dead_code.cpp | 37 
> > >  5 files changed, 96 insertions(+), 2 deletions(-)
> > >
> > > --
> > > 2.1.4
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >

I found another issue with my application (lucky me).

out SHADER
{
vec4 t;
vec4 c;
flat vec4 fc;
} VSout;

in SHADER
{
vec4 t;
vec4 c;
flat vec4 fc;
} PSin;


will be transformed into the following interface in SSO (in 
varying_matches::record) to

out SHADER
{
flat vec4 t;
flat vec4 c;
flat vec4 fc;
} VSout;

in SHADER
{
vec4 t;
vec4 c;
flat vec4 fc;
} PSin;

It doesn't change the interpolation/rendering as it will use the one
from the FS. However it will affect the
match_comparator function. So the sorting in
varying_matches::assign_locations will 
behave differently for some parameters. I don't know how to handle
this. Either we could adapt the sort function
to mask the flat value. Or we mustn't add the flat qualifier. Any opinions or
other solutions?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: set glsl error if binding qualifier used on global scope

2015-10-05 Thread Samuel Iglesias Gonsálvez

Reviewed-by: Samuel Iglesias Gonsálvez 

On 05/10/15 12:02, Tapani Pälli wrote:
> Fixes following Piglit test:
>   global-scope-binding-qualifier.frag
> 
> Signed-off-by: Tapani Pälli 
> ---
>  src/glsl/glsl_parser.yy | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index f0abeb0..c1b 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -2786,6 +2786,17 @@ layout_defaults:
>if (!state->default_shader_storage_qualifier->merge_qualifier(& @1, 
> state, $1)) {
>   YYERROR;
>}
> +
> +  /* From the GLSL 4.50 spec, section 4.4.5:
> +   *
> +   * "It is a compile-time error to specify the binding identifier 
> for
> +   * the global scope or for block member declarations."
> +   */
> +  if (state->default_shader_storage_qualifier->flags.q.explicit_binding) 
> {
> + _mesa_glsl_error(& @1, state,
> +  "binding qualifier cannot be set for default 
> layout");
> +  }
> +
>$$ = NULL;
> }
>  
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: set glsl error if binding qualifier used on global scope

Fixes following Piglit test:
global-scope-binding-qualifier.frag

Signed-off-by: Tapani Pälli 
---
 src/glsl/glsl_parser.yy | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index f0abeb0..c1b 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -2786,6 +2786,17 @@ layout_defaults:
   if (!state->default_shader_storage_qualifier->merge_qualifier(& @1, 
state, $1)) {
  YYERROR;
   }
+
+  /* From the GLSL 4.50 spec, section 4.4.5:
+   *
+   * "It is a compile-time error to specify the binding identifier for
+   * the global scope or for block member declarations."
+   */
+  if (state->default_shader_storage_qualifier->flags.q.explicit_binding) {
+ _mesa_glsl_error(& @1, state,
+  "binding qualifier cannot be set for default 
layout");
+  }
+
   $$ = NULL;
}
 
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH] i965: Make vec4_visitor's destructor virtual

2015-10-05 Thread Iago Toral

On Mon, 2015-10-05 at 13:08 +0300, Francisco Jerez wrote:
> Iago Toral Quiroga  writes:
> 
> > We need a virtual destructor when at least one of the class' methods is 
> > virtual.
> > Failure to do so leads to undefined behavior when destructing derived 
> > classes.
> > Fixes the following warning:
> >
> > brw_vec4_gs_visitor.cpp: In function 'const unsigned int* 
> > brw::brw_gs_emit(brw_context*, gl_shader_program*, brw_gs_compile*, void*, 
> > unsigned int*)':
> > brw_vec4_gs_visitor.cpp:703:11: warning: deleting object of polymorphic 
> > class type 'brw::vec4_gs_visitor' which has non-virtual destructor might 
> > cause undefined behaviour [-Wdelete-non-virtual-dtor]
> > delete gs;
> 
> I don't think this was leading to an actual bug because AFAICT
> gen6_gs_visitor is the only subclass of vec4_visitor destroyed through a
> pointer of a base class (vec4_gs_visitor *), and its destructor is
> basically the same as its parent's.  Anyway it seems sensible to change
> this so it doesn't bite us in the future.  If you clarify that in the
> commit message this patch is:
> 
> Reviewed-by: Francisco Jerez 

Will do, thanks Curro!

Iago

> > ---
> >  src/mesa/drivers/dri/i965/brw_vec4.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
> > b/src/mesa/drivers/dri/i965/brw_vec4.h
> > index d1fa095..5e3500c 100644
> > --- a/src/mesa/drivers/dri/i965/brw_vec4.h
> > +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
> > @@ -76,7 +76,7 @@ public:
> > void *mem_ctx,
> >  bool no_spills,
> >  int shader_time_index);
> > -   ~vec4_visitor();
> > +   virtual ~vec4_visitor();
> >  
> > dst_reg dst_null_f()
> > {
> > -- 
> > 1.9.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 4/6] i965: dump scheduling cycle estimates

2015-10-05 Thread Iago Toral

On Fri, 2015-10-02 at 17:43 -0400, Connor Abbott wrote:
> On Fri, Oct 2, 2015 at 5:37 PM, Connor Abbott  wrote:
> > The heuristic we're using is rather lame, since it assumes everything is
> > non-uniform and loops execute 50 times, but it should be enough for
> > measuring improvements in the scheduler that don't result in a change in
> > the number of instructions.

Our spilling code assumes that loops run 10 times for the purpose of
evaluating spilling costs... shouldn't we use the same estimation
everywhere?

Iago 

> > Signed-off-by: Connor Abbott 
> > ---
> >  src/mesa/drivers/dri/i965/brw_cfg.h  |  4 
> >  src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 11 ++-
> >  .../drivers/dri/i965/brw_schedule_instructions.cpp   | 20 
> > 
> >  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  9 +
> >  4 files changed, 35 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h 
> > b/src/mesa/drivers/dri/i965/brw_cfg.h
> > index a094917..d0bdb00 100644
> > --- a/src/mesa/drivers/dri/i965/brw_cfg.h
> > +++ b/src/mesa/drivers/dri/i965/brw_cfg.h
> > @@ -90,6 +90,8 @@ struct bblock_t {
> > struct exec_list parents;
> > struct exec_list children;
> > int num;
> > +
> > +   unsigned cycle_count;
> >  };
> >
> >  static inline struct backend_instruction *
> > @@ -285,6 +287,8 @@ struct cfg_t {
> > int num_blocks;
> >
> > bool idom_dirty;
> > +
> > +   unsigned cycle_count;
> >  };
> >
> >  /* Note that this is implemented with a double for loop -- break will
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > index 6f8b75e..9540012 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > @@ -2181,9 +2181,9 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> > dispatch_width)
> >
> > if (unlikely(debug_flag)) {
> >fprintf(stderr, "Native code for %s\n"
> > -  "SIMD%d shader: %d instructions. %d loops. %d:%d 
> > spills:fills. Promoted %u constants. Compacted %d to %d"
> > +  "SIMD%d shader: %d instructions. %u cycles. %d loops. %d:%d 
> > spills:fills. Promoted %u constants. Compacted %d to %d"
> >" bytes (%.0f%%)\n",
> > -  shader_name, dispatch_width, before_size / 16, loop_count,
> > +  shader_name, dispatch_width, before_size / 16, 
> > cfg->cycle_count, loop_count,
> >spill_count, fill_count, promoted_constants, before_size, 
> > after_size,
> >100.0f * (before_size - after_size) / before_size);
> >
> > @@ -2193,12 +2193,13 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> > dispatch_width)
> > }
> >
> > compiler->shader_debug_log(log_data,
> > -  "%s SIMD%d shader: %d inst, %d loops, "
> > +  "%s SIMD%d shader: %d inst, %u cycles, %d 
> > loops, "
> >"%d:%d spills:fills, Promoted %u constants, "
> >"compacted %d to %d bytes.\n",
> >stage_abbrev, dispatch_width, before_size / 
> > 16,
> > -  loop_count, spill_count, fill_count,
> > -  promoted_constants, before_size, after_size);
> > +  cfg->cycle_count, loop_count, spill_count,
> > +  fill_count, promoted_constants, before_size,
> > +  after_size);
> >
> > return start_offset;
> >  }
> > diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
> > b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> > index 1652261..22a493f 100644
> > --- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> > @@ -1467,6 +1467,24 @@ 
> > instruction_scheduler::schedule_instructions(bblock_t *block)
> > if (block->end()->opcode == BRW_OPCODE_NOP)
> >block->end()->remove(block);
> > assert(instructions_to_schedule == 0);
> > +
> > +   block->cycle_count = time;
> > +}
> > +
> > +static unsigned get_cycle_count(cfg_t *cfg)
> > +{
> > +   unsigned count = 0, multiplier = 1;
> > +   foreach_block(block, cfg) {
> > +  if (block->start()->opcode == BRW_OPCODE_DO)
> > + multiplier *= 50; /* assume that loops have ~50 instructions */
> 
> Whoops, this should say "assume that loops are run ~50 times"...
> 
> > +
> > +  count += block->cycle_count * multiplier;
> > +
> > +  if (block->end()->opcode == BRW_OPCODE_WHILE)
> > + multiplier /= 50;
> > +   }
> > +
> > +   return count;
> >  }
> >
> >  void
> > @@ -1507,6 +1525,8 @@ instruction_scheduler::run(cfg_t *cfg)
> >post_reg_alloc);
> >bs->dump_instructions();
> > }
> >

Re: [Mesa-dev] [PATCH] i965: Make vec4_visitor's destructor virtual

2015-10-05 Thread Francisco Jerez

Iago Toral Quiroga  writes:

> We need a virtual destructor when at least one of the class' methods is 
> virtual.
> Failure to do so leads to undefined behavior when destructing derived classes.
> Fixes the following warning:
>
> brw_vec4_gs_visitor.cpp: In function 'const unsigned int* 
> brw::brw_gs_emit(brw_context*, gl_shader_program*, brw_gs_compile*, void*, 
> unsigned int*)':
> brw_vec4_gs_visitor.cpp:703:11: warning: deleting object of polymorphic class 
> type 'brw::vec4_gs_visitor' which has non-virtual destructor might cause 
> undefined behaviour [-Wdelete-non-virtual-dtor]
> delete gs;

I don't think this was leading to an actual bug because AFAICT
gen6_gs_visitor is the only subclass of vec4_visitor destroyed through a
pointer of a base class (vec4_gs_visitor *), and its destructor is
basically the same as its parent's.  Anyway it seems sensible to change
this so it doesn't bite us in the future.  If you clarify that in the
commit message this patch is:

Reviewed-by: Francisco Jerez 

> ---
>  src/mesa/drivers/dri/i965/brw_vec4.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_vec4.h
> index d1fa095..5e3500c 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
> @@ -76,7 +76,7 @@ public:
>   void *mem_ctx,
>  bool no_spills,
>  int shader_time_index);
> -   ~vec4_visitor();
> +   virtual ~vec4_visitor();
>  
> dst_reg dst_null_f()
> {
> -- 
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH v3 2/2] i965/fs: Handle non-const sample number in interpolateAtSample

2015-10-05 Thread Neil Roberts

If a non-const sample number is given to interpolateAtSample it will
now generate an indirect send message with the sample ID similar to
how non-const sampler array indexing works. Previously non-const
values were ignored and instead it ended up using a constant 0 value.

The generator will try to determine if the sample ID is dynamically
uniform via nir_src_is_dynamically_uniform. If not it will query the
pixel interpolator in a loop, once for each possible sample number.
This is necessary because the indirect send message doesn't seem to
have a way to specify a different value for each fragment.

The range of possible sample numbers is determined using
STATE_NUM_SAMPLES. When linking the shader it will now add a reference
to this state if any dynamically non-uniform calls to
interpolateAtSample are found.

This fixes the following two Piglit tests:

arb_gpu_shader5-interpolateAtSample-nonconst
arb_gpu_shader5-interpolateAtSample-dynamically-nonuniform

v2: Handle dynamically non-uniform sample ids.
v3: Remove the BREAK instruction and predicate the WHILE directly.
Make the tokens arrays const.
---

All three patches are also available in a branch here:

https://github.com/bpeel/mesa/tree/wip/nonconst-interpolate-at-sample

 src/mesa/drivers/dri/i965/brw_eu.h |   2 +-
 src/mesa/drivers/dri/i965/brw_eu_emit.c|  34 ---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp |   5 +-
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 127 +
 src/mesa/drivers/dri/i965/brw_program.c|  54 +++
 src/mesa/drivers/dri/i965/brw_program.h|   1 +
 src/mesa/drivers/dri/i965/brw_shader.cpp   |   2 +
 7 files changed, 193 insertions(+), 32 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 761aa0e..0ac1ad9 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -461,7 +461,7 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
  struct brw_reg mrf,
  bool noperspective,
  unsigned mode,
- unsigned data,
+ struct brw_reg data,
  unsigned msg_length,
  unsigned response_length);
 
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index dc699bb..9c38e99 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -3212,26 +3212,38 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
  struct brw_reg mrf,
  bool noperspective,
  unsigned mode,
- unsigned data,
+ struct brw_reg data,
  unsigned msg_length,
  unsigned response_length)
 {
const struct brw_device_info *devinfo = p->devinfo;
-   struct brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
+   struct brw_inst *insn;
+   uint16_t exec_size;
 
-   brw_set_dest(p, insn, dest);
-   brw_set_src0(p, insn, mrf);
-   brw_set_message_descriptor(p, insn, GEN7_SFID_PIXEL_INTERPOLATOR,
-  msg_length, response_length,
-  false /* header is never present for PI */,
-  false);
+   if (data.file == BRW_IMMEDIATE_VALUE) {
+  insn = next_insn(p, BRW_OPCODE_SEND);
+  brw_set_dest(p, insn, dest);
+  brw_set_src0(p, insn, mrf);
+  brw_set_message_descriptor(p, insn, GEN7_SFID_PIXEL_INTERPOLATOR,
+ msg_length, response_length,
+ false /* header is never present for PI */,
+ false);
+  brw_inst_set_pi_message_data(devinfo, insn, data.dw1.ud);
+   } else {
+  insn = brw_send_indirect_message(p,
+   GEN7_SFID_PIXEL_INTERPOLATOR,
+   dest,
+   mrf,
+   vec1(data));
+  brw_inst_set_mlen(devinfo, insn, msg_length);
+  brw_inst_set_rlen(devinfo, insn, response_length);
+   }
 
-   brw_inst_set_pi_simd_mode(
- devinfo, insn, brw_inst_exec_size(devinfo, insn) == BRW_EXECUTE_16);
+   exec_size = brw_inst_exec_size(devinfo, p->current);
+   brw_inst_set_pi_simd_mode(devinfo, insn, exec_size == BRW_EXECUTE_16);
brw_inst_set_pi_slot_group(devinfo, insn, 0); /* zero unless 32/64px 
dispatch */
brw_inst_set_pi_nopersp(devinfo, insn, noperspective);
brw_inst_set_pi_message_type(devinfo, insn, mode);
-   brw_inst_set_pi_message_data(devinfo, insn, data);
 }
 
 void
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 6f8b75e..17e19cf 100644

[Mesa-dev] [PATCH 1/2] i965: Add a second successor to BRW_OPCODE_WHILE

2015-10-05 Thread Neil Roberts

It is possible to directly predicate the WHILE instruction. In this
case there will be a second successor block because the execution can
resume from the instruction after the loop. This will be used in a
subsequent patch.
---
 src/mesa/drivers/dri/i965/brw_cfg.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp 
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 91d53ef..531fa16 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -305,6 +305,10 @@ cfg_t::cfg_t(exec_list *instructions)
 
  assert(cur_do != NULL && cur_while != NULL);
 cur->add_successor(mem_ctx, cur_do);
+
+ if (inst->predicate)
+cur->add_successor(mem_ctx, cur_while);
+
 set_next_block(, cur_while, ip);
 
 /* Pop the stack so we're in the previous loop */
-- 
1.9.3

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

Re: [Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

2015-10-05 Thread Roland Scheidegger

FWIW from a high level point of view this makes all sense to me. It is
however definitely not my field of expertise, but whatever makes it
easier to have multiple drivers installed is imho a good thing...
Some more feedback from mesa people which are more familiar with the gl
api dispatch stuff (albeit there's probably not that many...) would
probably be nice...

Roland

Am 30.09.2015 um 22:07 schrieb Kyle Brenneman:
> I'm working on libglvnd, a vendor-neutral dispatch library for OpenGL,
> and I wanted to see if anyone had any comments or suggestions about it.
> Right now, I'm trying to get the GLX interface wrapped up, but I'd like
> to get some feedback from the Mesa community before I'd be confidant in
> calling it ready.
> 
> A bit of background: Libglvnd was originally proposed back at XDC 2013.
> It's hosted on Github here:
> https://github.com/NVIDIA/libglvnd
> 
> The goal for libglvnd is to allow multiple OpenGL implementations from
> different vendors to coexist on the same system, without interfering
> with each other or requiring any manual configuration.
> 
> With libglvnd, libGL.so is a vendor-independent dispatch library, not
> part of any driver. Each vendor provides its OpenGL implementation in a
> separate library. An application still links to libGL.so just like it
> does now, but then libGL.so will figure out which vendor library to use,
> and will dispatch any OpenGL and GLX calls to that library.
> 
> The libglvnd libraries make as few assumptions as possible about how the
> vendor libraries work, so that (hopefully) it's easy to port any
> existing OpenGL implementation to it. In some cases, a simple wrapper
> library around an existing libGL.so library would be enough.
> 
> As it's currently implemented, libglvnd selects a vendor library for
> each X screen. So, you could have two X screens that each use a
> different vendor library, and a single process could create and use
> rendering contexts on both. It doesn't handle two different vendor
> libraries for the same X screen, although the ABI is set up such that it
> would be possible to add that capability later on.
> 
> The EGL interface is still in its really early design stages. Any
> comments or requirements that I might have forgotten are more than welcome.
> 
> In addition, I've put together a proof-of-concept version of Mesa that
> can use libglvnd. It's still a work in progress, but hopefully it will
> provide a more concrete example of how libglvnd works. I've got it
> checked into Github here:
> https://github.com/kbrenneman/mesa-libglvnd
> 
> Internally, it's broken down into a few different libraries:
> libGLX handles GLX functions, and is responsible for keeping track of
> GLX contexts, selecting and loading vendor libraries, and setting up the
> dispatch table for OpenGL functions. This is the only library that a
> vendor library directly talks to.
> 
> libGLdispatch is responsible for dispatching OpenGL calls to the correct
> library based on the thread's current rendering context. It uses a
> dispatch table derived from Mesa's GLAPI layer. libGLdispatch is purely
> internal -- the vendor libraries go through libGLX to set up dispatch
> tables, and an application would call into libGL.so or libOpenGL.so to
> call any OpenGL functions.
> 
> libGL.so is a wrapper around libGLX and libGLdispatch. Conceptually, it
> just exports GL and GLX functions and forwards them to libGLX and
> libGLdispatch to deal with. The implementation is a bit more complicated
> to avoid the overhead of an extra indirect jump every time an app calls
> an OpenGL function.
> 
> In addition, there's a new library, libOpenGL.so. It's basically the
> same as libGL.so, except that it only exports the OpenGL functions, not
> GLX. It also doesn't depend on libGLX, so it could also be used with an
> EGL or GLX application. The hope is that future applications will link
> against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a
> cleaner separation of OpenGL from the window system binding. But,
> libGL.so will be kept around indefinitely for backwards compatibility.
> 
> Comments, questions, and suggestions are all welcome.
> 
> Thanks,
> -Kyle Brenneman
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

[Mesa-dev] [Bug 92286] Distant geometry renders in front of closer geometry (depth test fail) in DarkRadiant / wxWidgets

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

MirceaKitsune  changed:

   What|Removed |Added

 CC||sonichedgehog_hyperblast00@
   ||yahoo.com

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

[Mesa-dev] [Bug 92286] Distant geometry renders in front of closer geometry (depth test fail) in DarkRadiant / wxWidgets

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

Bug ID: 92286
Summary: Distant geometry renders in front of closer geometry
(depth test fail) in DarkRadiant / wxWidgets
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
Assignee: mesa-dev@lists.freedesktop.org
Reporter: sonichedgehog_hyperblas...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118669
--> https://bugs.freedesktop.org/attachment.cgi?id=118669=edit
Screenshot of the depth sorting issue

Mesa users appear to experience a strange problem with Dark Radiant (the map
editor of The Dark Mod): Depth testing does not work, causing surfaces hidden
behind over surfaces to render through them in a random order.

I decided to report the problem here since it only happens on Linux and the
free graphics driver. I experience it on my Radeon 6870 card, and someone else
reported the same issue on an Intel card. Currently I am running Mesa 10.3.7. I
looked through the DarkRadiant code and did intensive testing, but nothing I
found appears to be related to this, and the source of the problem is a
complete mystery to everyone.

Important highlights: The problem persists if I disable transparency on all
surfaces, despite this potentially being an alpha sorting issue. It also occurs
regardless of rendering mode (wireframe / solid / textured / lighting).
Surfaces in a single model can overlap each other too, so it's not just some
objects overlapping others. Any DarkRadiant window that renders geometry is
affected, not only the viewport. Also note that DarkRadiant uses wxWidgets, and
its older GTK variant does not have the problem... meaning it might be
wxWidgets related in addition.

Please follow my reports on the TDM forum and bug tracker as well, which
contain even more information and might get updated more timely:

http://forums.thedarkmod.com/topic/16848-distant-geometry-renders-in-front-of-closer-geometry/

http://bugs.thedarkmod.com/view.php?id=4017

--
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/2] Use hash tables for opt_constant_propagation() acp sets

2015-10-05 Thread Rhys Kidd

On 20 September 2015 at 19:54, Rhys Kidd  wrote:

> Kenneth Graunke in 4654439fdd766f79a78fe0d812fd916f5815e7e6 refactored
> kill sets in opt_constant_propagation() to use hash tables. This patch set
> makes the suggested changes to use hash tables for acp sets, as well as
> correcting documentation within the file for recent hash table changes.
>
> RFC as I do not have access to hardware sufficient to test performance
> improvements to the shader suggested in #91857 (GLSL 3.30 required).
>
> No piglit regressions on Intel Ironlake.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91857
> Signed-off-by: Rhys Kidd 
>
> Rhys Kidd (2):
>   glsl: Use hash tables for opt_constant_propagation() acp sets.
>   glsl: Update kill set comments for opt_constant_propagation() hash
> table.
>
>  src/glsl/opt_constant_propagation.cpp | 69
> +--
>  1 file changed, 41 insertions(+), 28 deletions(-)
>
> --
> 2.1.4
>
>
Friendly ping?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ARB_shader_clock, hardware counters and i965

2015-10-05 Thread Connor Abbott

On Mon, Oct 5, 2015 at 11:36 AM, Emil Velikov  wrote:
> Hi all,
>
> I am looking at ARB_shader_clock with i965 in mind.
>
> So far I've got the most of the infra/plumbing, and a fancy a new intrinsic :)
>
> On the hardware side, I was thinking about using the Observability
> Architecture (OA) counters. The fun part is that those tend to vary
> quite a bit based on the hardware generation. So far I'm leaning
> towards:
>  - "Count of XXX threads dispatched to EUs" for BRW and later.
>  - "XXX Shader Active Time" for earlier (SNB-HSW/VLV) hardware.
>
> Do there sound appropriate, or should we opt for the various knobs in
> 'Flexible EU event counters' ? Is there some alternative piece of
> hardware in i965, which I can use ?
>
>
> Going for OA has a small catch. Reading through the PRM, it is not
> obvious if one can track the same source twice (the
> GL_AMD_performance_monitor implementation comes to mind). I'm about to
> take a closer look into brw_performance_monitor.[ch] shortly, but if
> any gotchas/fancy interactions come to mind let me know.
>
> Thanks
> Emil
>
> P.S. Does anyone recall the consensus wrt adding the 2015 extensions
> to GL3.txt ?
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Hi Emil,

I don't think you want to use the OA counters to implement
ARB_shader_clock. They're not exposed to the shader directly, AFAIK,
and they only measure things on a per-invocation granularity, whereas
the intent of ARB_shader_clock is to be able to measure the number of
cycles that individual operations take with very low latency. Instead,
you should read from the ARF performance register -- see page 822 of
Vol 7 ("3D Media GPGPU") of the Broadwell PRM (page 858 of the PDF)
for more details.

Another interesting thing is that you can atomically read from that
register and also get a bit that say whether there was some event,
such as a context switch, since the last time you read it that would
make your measurement invalid. It might be useful to expose this
through a GLSL extension as another set of overloads:

uint64_t clockARB(out bool valid); //once we get int64 support
uvec2 clock2x32ARB(out bool valid);

and a corresponding NIR intrinsic that outputs an extra component
that's a boolean (i.e. 0 or ~0). That would help with implementing
something like INTEL_DEBUG=shader_time generically with less outliers
to throw away.

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

[Mesa-dev] [PATCH] i915/aa: fixing anti-aliasing bug for thinnest width lines

2015-10-05 Thread Marius Predut

On PNV platform, for 1 pixel line thickness or less,
the general anti-aliasing algorithm gives up, and a garbage line is generated.
Setting a Line Width of 0.0 specifies the rasterization
of the "thinnest" (one-pixel-wide), non-antialiased lines.
Lines rendered with zero Line Width are rasterized using
Grid Intersection Quantization rules as specified by
2.8.4.1 Zero-Width (Cosmetic) Line Rasterization from volume 1f of the GEN3
docs.
The patch was tested on Intel Atom CPU N455.

This patch follow the same rules as patches fixing the
https://bugs.freedesktop.org/show_bug.cgi?id=28832
bug.

v1: Eduardo Lima Mitev:  Wrong indentation inside the if clause.
v2: Ian Romanick: comments fix.

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

Signed-off-by: Marius Predut 
---
 src/mesa/drivers/dri/i915/i915_state.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/i915_state.c 
b/src/mesa/drivers/dri/i915/i915_state.c
index 4c83073..897eb59 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -599,6 +599,21 @@ i915LineWidth(struct gl_context * ctx, GLfloat widthf)

width = (int) (widthf * 2);
width = CLAMP(width, 1, 0xf);
+
+   if (ctx->Line.Width < 1.5 || widthf < 1.5) {
+ /* For 1 pixel line thickness or less, the general
+  * anti-aliasing algorithm gives up, and a garbage line is
+  * generated.  Setting a Line Width of 0.0 specifies the
+  * rasterization of the "thinnest" (one-pixel-wide),
+  * non-antialiased lines.
+  *
+  * Lines rendered with zero Line Width are rasterized using
+  * Grid Intersection Quantization rules as specified by
+  * volume 1f of the GEN3 docs,
+  * 2.8.4.1 Zero-Width (Cosmetic) Line Rasterization. 
+  */
+  width = 0;
+   }
lis4 |= width << S4_LINE_WIDTH_SHIFT;
 
if (lis4 != i915->state.Ctx[I915_CTXREG_LIS4]) {
-- 
1.9.1

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

[Mesa-dev] [Bug 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2

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

--- Comment #2 from Neil Roberts  ---
I think the general problem is that if you install an old version of Mesa
somewhere and then try and build a new version while specifying the install
prefix of the old version as an include path with -I in the CPPFLAGS then it
will end up picking up the old installed headers instead of the ones that are
internal to the Mesa source tree. In this case the problematic header is
GL/internal/dri_interface.h, but there are others. It doesn't seem like this is
such an unusual thing to do so it would be nice if it worked.

Note, in this case it was being built out-of-tree, but I'm not sure if that's
necessary to replicate the bug.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2

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

--- Comment #4 from Emil Velikov  ---
As a quick test, I would suggest dropping the CPPFLAGS and (optionally
LDFLAGS). PKG_CONFIG_PATH will provide the relevant bits as needed.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] ARB_shader_clock, hardware counters and i965

2015-10-05 Thread Emil Velikov

Hi all,

I am looking at ARB_shader_clock with i965 in mind.

So far I've got the most of the infra/plumbing, and a fancy a new intrinsic :)

On the hardware side, I was thinking about using the Observability
Architecture (OA) counters. The fun part is that those tend to vary
quite a bit based on the hardware generation. So far I'm leaning
towards:
 - "Count of XXX threads dispatched to EUs" for BRW and later.
 - "XXX Shader Active Time" for earlier (SNB-HSW/VLV) hardware.

Do there sound appropriate, or should we opt for the various knobs in
'Flexible EU event counters' ? Is there some alternative piece of
hardware in i965, which I can use ?


Going for OA has a small catch. Reading through the PRM, it is not
obvious if one can track the same source twice (the
GL_AMD_performance_monitor implementation comes to mind). I'm about to
take a closer look into brw_performance_monitor.[ch] shortly, but if
any gotchas/fancy interactions come to mind let me know.

Thanks
Emil

P.S. Does anyone recall the consensus wrt adding the 2015 extensions
to GL3.txt ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] ARB_shader_clock, hardware counters and i965

2015-10-05 Thread Emil Velikov

On 5 October 2015 at 17:11, Connor Abbott  wrote:
> On Mon, Oct 5, 2015 at 11:36 AM, Emil Velikov  
> wrote:
>> Hi all,
>>
>> I am looking at ARB_shader_clock with i965 in mind.
>>
>> So far I've got the most of the infra/plumbing, and a fancy a new intrinsic 
>> :)
>>
>> On the hardware side, I was thinking about using the Observability
>> Architecture (OA) counters. The fun part is that those tend to vary
>> quite a bit based on the hardware generation. So far I'm leaning
>> towards:
>>  - "Count of XXX threads dispatched to EUs" for BRW and later.
>>  - "XXX Shader Active Time" for earlier (SNB-HSW/VLV) hardware.
>>
>> Do there sound appropriate, or should we opt for the various knobs in
>> 'Flexible EU event counters' ? Is there some alternative piece of
>> hardware in i965, which I can use ?
>>
>>
>> Going for OA has a small catch. Reading through the PRM, it is not
>> obvious if one can track the same source twice (the
>> GL_AMD_performance_monitor implementation comes to mind). I'm about to
>> take a closer look into brw_performance_monitor.[ch] shortly, but if
>> any gotchas/fancy interactions come to mind let me know.
>>
>> Thanks
>> Emil
>>
>> P.S. Does anyone recall the consensus wrt adding the 2015 extensions
>> to GL3.txt ?
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Hi Emil,
>
> I don't think you want to use the OA counters to implement
> ARB_shader_clock. They're not exposed to the shader directly, AFAIK,
> and they only measure things on a per-invocation granularity, whereas
> the intent of ARB_shader_clock is to be able to measure the number of
> cycles that individual operations take with very low latency. Instead,
> you should read from the ARF performance register -- see page 822 of
> Vol 7 ("3D Media GPGPU") of the Broadwell PRM (page 858 of the PDF)
> for more details.
>
I knew that there should be nicer piece of hardware for this, but
could not find it looking through the spec. The timestamp register
looks exactly like the thing we need there.

> Another interesting thing is that you can atomically read from that
> register and also get a bit that say whether there was some event,
> such as a context switch, since the last time you read it that would
> make your measurement invalid. It might be useful to expose this
> through a GLSL extension as another set of overloads:
>
> uint64_t clockARB(out bool valid); //once we get int64 support
> uvec2 clock2x32ARB(out bool valid);
>
Are you thinking about writing up another extension, or should we just
wire things internally as someone else does it for us ? Would you have
any preference how to handle things when a context switch has occurred
(for the official functions) ?

> and a corresponding NIR intrinsic that outputs an extra component
> that's a boolean (i.e. 0 or ~0). That would help with implementing
> something like INTEL_DEBUG=shader_time generically with less outliers
> to throw away.
>
Exposing it via INTEL_DEBUG will be great, but first I'd stick getting
the extension bits in place.

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

[Mesa-dev] [Bug 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2

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

--- Comment #3 from Emil Velikov  ---
(In reply to marius predut from comment #1)
> Created attachment 118675 [details]
> attachment-24069-0.html
> 
> Seems dri_interface.h is missing from intel_screen.c file.
> But even adding it ,mesa have compilation error: no rule to make target
> nir/nir_...
> 
Can you open a separate bug for this ? I'm suspecting that something strange is
happening on your setup, as I haven't seen such problems for a very long time.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] i915/aa: fixing anti-aliasing bug for thinnest width lines

2015-10-05 Thread Predut, Marius

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
> Ian Romanick
> Sent: Wednesday, September 09, 2015 9:11 PM
> To: Predut, Marius; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v2] i915/aa: fixing anti-aliasing bug for
> thinnest width lines
> 
> On 09/09/2015 06:59 AM, Marius Predut wrote:
> > On PNV platform, for 1 pixel line thickness or less,
> > the general anti-aliasing algorithm gives up, and a garbage line is
> generated.
> > Setting a Line Width of 0.0 specifies the rasterization
> > of the "thinnest" (one-pixel-wide), non-antialiased lines.
> > Lines rendered with zero Line Width are rasterized using
> > Grid Intersection Quantization rules as specified by bspec G45: Volume 2:
> 3D/Media,
> > 7.3.13.1 Zero-Width (Cosmetic) Line Rasterization section.
> >
> > This patch follow the same rules as patches fixing the
> > https://bugs.freedesktop.org/show_bug.cgi?id=28832
> > bug.
> >
> > v1: Eduardo Lima Mitev:  Wrong indentation inside the if clause.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90367
> >
> > Signed-off-by: Marius Predut 
> > ---
> >  src/mesa/drivers/dri/i915/i915_state.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i915/i915_state.c
> b/src/mesa/drivers/dri/i915/i915_state.c
> > index 4c83073..ebb4e9a 100644
> > --- a/src/mesa/drivers/dri/i915/i915_state.c
> > +++ b/src/mesa/drivers/dri/i915/i915_state.c
> > @@ -599,6 +599,21 @@ i915LineWidth(struct gl_context * ctx, GLfloat widthf)
> >
> > width = (int) (widthf * 2);
> > width = CLAMP(width, 1, 0xf);
> > +
> > +   if (ctx->Line.Width < 1.5 || widthf < 1.5) {
> > + /* For 1 pixel line thickness or less, the general
> > +  * anti-aliasing algorithm gives up, and a garbage line is
> > +  * generated.  Setting a Line Width of 0.0 specifies the
> > +  * rasterization of the "thinnest" (one-pixel-wide),
> > +  * non-antialiased lines.
> > +  *
> > +  * Lines rendered with zero Line Width are rasterized using
> > +  * Grid Intersection Quantization rules as specified by
> > +  * bspec G45: Volume 2: 3D/Media,
> 
> Eh... Isn't G45 actually i965-class hardware?  GEN4.5, right?  I don't
> see how a GEN4 bspec reference is useful (or correct?) in the GEN3
> driver.  I think you want "2.8.4.1 Zero-Width (Cosmetic) Line
> Rasterization" from volume 1f of the GEN3 docs.

I used this reference specs because I was unable to find dedicated specs for 
gen 3.
Send v2 patch.

> 
> I looked at section 2.8.4.3 Anti-aliased Line Rasterization of volume 1f
> of the GEN3 docs that I have.  I don't see any mention of this
> restriction.  Is it documented anywhere?

my knowledge says no 

> 
> It also seems like this will affect non-antialised wide lines.  Is that
> correct?

Yes, for Line.Width < 1.5,

But seems this is the normal behavior.(for width = 0 , antialiased is disabled)


> 
> > +  * 7.3.13.1 Zero-Width (Cosmetic) Line Rasterization section
> > +  */
> > +  width = 0;
> > +   }
> > lis4 |= width << S4_LINE_WIDTH_SHIFT;
> >
> > if (lis4 != i915->state.Ctx[I915_CTXREG_LIS4]) {
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2

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

Bug ID: 92293
   Summary: A compilation error happen when update mesa from
10.6.7 to 11.0.2
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: olivierx.berth...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118674
  --> https://bugs.freedesktop.org/attachment.cgi?id=118674=edit
full build log

Setup:
--

kernel 4.3.0-rc3-drm-intel-nightly+
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa-11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver

Steps:
--
1. Update mesa sources to 11.0.2 tag and clean the build directory
2. Configure mesa :

/home/qa/dev/graphic/stack/mesa/mesa/autogen.sh ACLOCAL="aclocal -I
/home/qa/dev/graphic/build/usr/local/share/aclocal"
LDFLAGS="-L/home/qa/dev/graphic/build/usr/local/lib"
CPPFLAGS="-I/home/qa/dev/graphic/build/usr/local/include/"
PKG_CONFIG_PATH="/home/qa/dev/graphic/build/usr/local/share/pkgconfig:/home/qa/dev/graphic/build/usr/local/lib/pkgconfig:/home/qa/dev/graphic/build/usr/local/lib/x86_64-linux-gnu/pkgconfig"
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--prefix=/home/qa/dev/graphic/build/usr/local 
--libdir=/home/qa/dev/graphic/build/usr/local/lib
--includedir=/home/qa/dev/graphic/build/usr/local/include --disable-static
--enable-debug --disable-docs  --with-dri-drivers='i915 i965 swrast'
--enable-gles1 --enable-gles2 --enable-shared-glapi
--with-egl-platforms=x11,drm --enable-texture-float --enable-gbm
--enable-glx-tls --disable-dri2 --disable-dri3 --with-gallium-drivers=''
--disable-gallium-llvm
--with-dri-driverdir=/home/qa/dev/graphic/build/usr/local/lib/dri

3. Run make
4. Remove the GL, EGL, GLES, GLES2 and GLES3 directories from include path
(/home/qa/dev/graphic/build/usr/local/include/).
5. Replay the steps 2 and 3.

Actual result:
---
At the step 3, the compilation fail :

...
...
make[5]: Entering directory
`/home/qa/dev/graphic/tmp/mesa/mesa/build/amd64/src/mesa/drivers/dri/i965'
  CC   brw_binding_tables.lo
  CXX  brw_blorp_blit.lo
  CXX  brw_blorp_blit_eu.lo
  CC   brw_cc.lo
  CXX  brw_blorp.lo
  CXX  brw_cfg.lo
  CC   brw_clear.lo
  CC   brw_clip.lo
  CC   brw_clip_line.lo
  CC   brw_clip_point.lo
  CC   brw_clip_state.lo
  CC   brw_clip_tri.lo
  CC   brw_clip_unfilled.lo
  CC   brw_clip_util.lo
  CC   brw_compute.lo
  CC   brw_conditional_render.lo
  CXX  brw_cs.lo
  CC   brw_context.lo
  CC   brw_curbe.lo
  CXX  brw_cubemap_normalize.lo
  CXX  brw_dead_control_flow.lo
  CC   brw_device_info.lo
  CC   brw_disasm.lo
  CC   brw_draw.lo
  CC   brw_draw_upload.lo
  CC   brw_eu.lo
  CC   brw_eu_compact.lo
  CC   brw_eu_emit.lo
  CC   brw_eu_util.lo
  CC   brw_ff_gs.lo
  CC   brw_ff_gs_emit.lo
  CXX  brw_fs_channel_expressions.lo
  CXX  brw_fs_cmod_propagation.lo
  CXX  brw_fs_combine_constants.lo
  CXX  brw_fs_copy_propagation.lo
  CXX  brw_fs.lo
  CXX  brw_fs_cse.lo
  CXX  brw_fs_dead_code_eliminate.lo
  CXX  brw_fs_generator.lo
  CXX  brw_fs_live_variables.lo
  CXX  brw_fs_nir.lo
  CXX  brw_fs_peephole_predicated_break.lo
  CXX  brw_fs_reg_allocate.lo
  CXX  brw_fs_register_coalesce.lo
  CXX  brw_fs_sel_peephole.lo
  CXX  brw_fs_saturate_propagation.lo
  CXX  brw_fs_surface_builder.lo
  CXX  brw_fs_vector_splitting.lo
  CXX  brw_fs_visitor.lo
  CC   brw_gs.lo
  CC   brw_gs_state.lo
  CC   brw_gs_surface_state.lo
  CC   brw_interpolation_map.lo
  CXX  brw_lower_texture_gradients.lo
  CXX  brw_lower_unnormalized_offset.lo
  CC   brw_meta_fast_clear.lo
  CC   brw_meta_stencil_blit.lo
  CC   brw_meta_updownsample.lo
  CC   brw_meta_util.lo
  CC   brw_nir.lo
  CC   brw_misc_state.lo
  CC

[Mesa-dev] [Bug 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2