Re: [Mesa-dev] [Xcb] [PATCH] fix deadlock with libX11

[Uli Schlachter]

Hi,

why is mesa-dev CC'd to this mail? I guess that mesa run into this problem and
there is a thread on mesa-dev which could be provided in the commit message as
an extra reference? (This also means that this mail will end up in mesa-dev's
moderation queue...)

On 08.05.2013 14:58, Christian König wrote:
> libX11 acquires the display lock before calling "xcb_take_socket" and inside
> the "return_socket" callback, this can lead to a classic deadlock situation
> with the XCB iolock. [...]

I fail to see the classic deadlock situation here. In one place, mutex A is
acquired before mutex B and another code path does it the other way around, 
right?

However, where is this? XCB releases its iolock before calling the callback and
no there are no other callbacks, so it is impossible to first acquire the iolock
and the Display*'s lock, thus it should be impossible to deadlock.

Could you add the relevant backtraces and some more information about the
deadlock to the commit message?

Ah, after writing the rest of this mail, I just had this idea:

- X11 has taken the socket
- Thread A has locked the display.
- Thread B does xcb_no_operation() and thus ends up in libX11's return_socket(),
waiting for the display lock.
- Thread A calls e.g. xcb_no_operation(), too, ends up in return_socket() and
because socket_moving == 1, ends up waiting for thread B

=> Deadlock

Is this the issue you are seeing and which should be described better in the
commit message? What are the actual functions involved in this? How mad would
you be if I blamed libX11 for this? ;-)

> This patch removes the unnecessary extra signaling and just documents that
> "return_socket" might be called by multiple threads at the same time (which
> works fine with how libX11 is using the interface).

Well, this breaks the API, because not only libX11 uses xcb_take_socket(). It is
the reason that this function exists, but e.g. cairo's xcb backend also used
this function (before version 1.11.2; to simulate XLockDisplay()). I am not sure
if it would break.

> Signed-off-by: Christian König 
> ---
>  src/xcb_out.c |   36 +++-
>  src/xcbext.h  |6 --
>  src/xcbint.h  |7 ---
>  3 files changed, 27 insertions(+), 22 deletions(-)
[...]
> diff --git a/src/xcbext.h b/src/xcbext.h
> index 98b3c93..f8520a0 100644
> --- a/src/xcbext.h
> +++ b/src/xcbext.h
> @@ -66,8 +66,10 @@ unsigned int xcb_send_request(xcb_connection_t *c, int 
> flags, struct iovec *vect
>   * callback which XCB can call when it wants the write side of the
>   * socket back to make a request. This callback synchronizes with the
>   * external socket owner and flushes any output queues if appropriate.
> - * If you are sending requests which won't cause a reply, please note the
> - * comment for xcb_writev which explains some sequence number wrap issues.
> + * It is called without any locks held and so might be called from different
> + * threads at the same time. If you are sending requests which won't
> + * cause a reply, please note the comment for xcb_writev which explains
> + * some sequence number wrap issues.
>   * */

Instead of "It", "The callback function is called without any locks held".
However, that was true before, too. Also, this is no reason for "might be called
by different threads at the same time", because previously XCB did this, too.

>  int xcb_take_socket(xcb_connection_t *c, void (*return_socket)(void 
> *closure), void *closure, int flags, uint64_t *sent);
>  
> diff --git a/src/xcbint.h b/src/xcbint.h
> index f9e5a52..c68b2fa 100644
> --- a/src/xcbint.h
> +++ b/src/xcbint.h
> @@ -79,14 +79,15 @@ void *_xcb_map_remove(_xcb_map *q, unsigned int key);
>  
>  /* xcb_out.c */
>  
> +typedef void (*xcb_return_socket_func_t)(void *closure);

Uhm, why?

>  typedef struct _xcb_out {
>  pthread_cond_t cond;
>  int writing;
>  
> -pthread_cond_t socket_cond;
> -void (*return_socket)(void *closure);
> +xcb_return_socket_func_t return_socket;
>  void *socket_closure;
> -int socket_moving;
> +int socket_seq;

unsigned int please, overflow of signed integers is unspecified.

>  char queue[XCB_QUEUE_BUFFER_SIZE];
>  int queue_len;

Cheers,
Uli
-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] r600g missing Bump mapping

[Vadim Girlin]

On 05/09/2013 05:42 AM, Dragomir Ivanov wrote:

Hmm, Vadim... it works indeed. I can't push up to Ultra, but I see the
difference as on your screenshots.
Interestingly when I play it on win with catalyst, everything is WOW, on
r600g is Meh...
Unfortunately I erased windows, so I can't supply screenshot, but
subjectively it was way more beautiful on the same graphics level.


IIRC Doom3 tries to autodetect some settings and I guess there are 
differences in the game configuration with different drivers. Possibly 
some settings are misdetected with r600g, in this case I guess running 
it with the configuration file created for catalyst might help.


Also you might want to check game's console output for any hints, e.g. 
like this:


guessing video ram ( use +set sys_videoRam to force ) ..
guess failed, return default low-end VRAM setting ( 64MB VRAM )

Though I don't see this message with 64-bit port, looks like detection 
logic was changed there.


Vadim




On Thu, May 9, 2013 at 4:15 AM, Vadim Girlin  wrote:


On 05/09/2013 02:42 AM, Dragomir Ivanov wrote:


Hi there,
I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
r600g progress.
Game runs fine, but I can't see bump mapping effects as on Catalyst under
windows. They are enabled in the options. Does Mesa/r600g support bumps?
AMD E-350 here. Evergreen class GPU.



Here are two screenshots made with git mesa on evergreen with Ultra
settings, the only difference is toggled bump mapping option:

http://i.imgur.com/Cl0hamf.jpg
http://i.imgur.com/4IsjrR3.jpg

To me it looks like bump mapping works. Could you provide more detailed
info (with screenshots etc) to demonstrate your issue? Also you might want
to try resetting game options to default to make sure that you don't have
any nonstandard tweaks.

Vadim



OpenGL renderer string: Gallium 0.4 on AMD PALM


OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2


OpenGL core profile shading language version string: 1.40

Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013
x86_64 GNU/Linux



__**_
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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] draw: don't crash on vertex buffer overflow

[Zack Rusin]

We would crash when stride was bigger than the size of the buffer.
The correct behavior is to just fetch zero's in this case.
Unfortunatly gallium allows user_buffers in vertex_buffers and we
can't figure out the sizes of those, so we need to null check
the buffer to see if we can at all perform the check.

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_llvm.c |  145 +---
 src/gallium/auxiliary/draw/draw_llvm.h |   16 
 src/gallium/auxiliary/draw/draw_pt.c   |3 +-
 3 files changed, 151 insertions(+), 13 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index d2821a1..194854d 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -78,6 +78,58 @@ draw_gs_llvm_iface(const struct lp_build_tgsi_gs_iface 
*iface)
 }
 
 /**
+ * Create LLVM type for pipe_resource, which is inside the
+ * pipe_vertex_buffer
+ */
+static LLVMTypeRef
+create_jit_resource_type(struct gallivm_state *gallivm,
+ const char *struct_name)
+{
+   LLVMTargetDataRef target = gallivm->target;
+   LLVMTypeRef resource_type;
+   LLVMTypeRef elem_types[DRAW_JIT_RESOURCE_NUM_FIELDS];
+   LLVMTypeRef int32_type = LLVMInt32TypeInContext(gallivm->context);
+
+   elem_types[DRAW_JIT_RESOURCE_REFERENCE] = int32_type;
+   elem_types[DRAW_JIT_RESOURCE_SCREEN] =
+  LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 0);
+   
+   elem_types[DRAW_JIT_RESOURCE_TARGET] = int32_type;
+   elem_types[DRAW_JIT_RESOURCE_FORMAT] = int32_type;
+   elem_types[DRAW_JIT_RESOURCE_WIDTH0] = int32_type;
+
+   resource_type = LLVMStructTypeInContext(gallivm->context, elem_types,
+   Elements(elem_types), 0);
+
+#if HAVE_LLVM < 0x0300
+   LLVMAddTypeName(gallivm->module, struct_name, resource_type);
+
+   /* Make sure the target's struct layout cache doesn't return
+* stale/invalid data.
+*/
+   LLVMInvalidateStructLayout(gallivm->target, resource_type);
+#endif
+
+   LP_CHECK_MEMBER_OFFSET(struct pipe_resource, reference,
+  target, resource_type,
+  DRAW_JIT_RESOURCE_REFERENCE);
+   LP_CHECK_MEMBER_OFFSET(struct pipe_resource, screen,
+  target, resource_type,
+  DRAW_JIT_RESOURCE_SCREEN);
+   LP_CHECK_MEMBER_OFFSET(struct pipe_resource, target,
+  target, resource_type,
+  DRAW_JIT_RESOURCE_TARGET);
+   LP_CHECK_MEMBER_OFFSET(struct pipe_resource, format,
+  target, resource_type,
+  DRAW_JIT_RESOURCE_FORMAT);
+   LP_CHECK_MEMBER_OFFSET(struct pipe_resource, width0,
+  target, resource_type,
+  DRAW_JIT_RESOURCE_WIDTH0);
+
+   return resource_type;
+}
+
+/**
  * Create LLVM type for struct draw_jit_texture
  */
 static LLVMTypeRef
@@ -328,7 +380,9 @@ create_gs_jit_input_type(struct gallivm_state *gallivm)
  * Create LLVM type for struct pipe_vertex_buffer
  */
 static LLVMTypeRef
-create_jit_vertex_buffer_type(struct gallivm_state *gallivm, const char 
*struct_name)
+create_jit_vertex_buffer_type(struct gallivm_state *gallivm,
+  LLVMTypeRef resource_type,
+  const char *struct_name)
 {
LLVMTargetDataRef target = gallivm->target;
LLVMTypeRef elem_types[4];
@@ -336,8 +390,8 @@ create_jit_vertex_buffer_type(struct gallivm_state 
*gallivm, const char *struct_
 
elem_types[0] =
elem_types[1] = LLVMInt32TypeInContext(gallivm->context);
-   elem_types[2] =
-   elem_types[3] = LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 
0); /* vs_constants */
+   elem_types[2] = LLVMPointerType(resource_type, 0);
+   elem_types[3] = LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 0);
 
vb_type = LLVMStructTypeInContext(gallivm->context, elem_types,
  Elements(elem_types), 0);
@@ -351,6 +405,8 @@ create_jit_vertex_buffer_type(struct gallivm_state 
*gallivm, const char *struct_
   target, vb_type, 0);
LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, buffer_offset,
   target, vb_type, 1);
+   LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, buffer,
+  target, vb_type, 2);
 
LP_CHECK_STRUCT_SIZE(struct pipe_vertex_buffer, target, vb_type);
 
@@ -422,7 +478,8 @@ static void
 create_jit_types(struct draw_llvm_variant *variant)
 {
struct gallivm_state *gallivm = variant->gallivm;
-   LLVMTypeRef texture_type, sampler_type, context_type, buffer_type, vb_type;
+   LLVMTypeRef texture_type, sampler_type, context_type, buffer_type,
+  vb_type, resource_type;
 
texture_type = create_jit_texture_type(gallivm, "texture");
sampler_type = create_jit_sampler_type(gallivm, "sampler");
@@ -434,7 +491,10 @@ create_jit

Re: [Mesa-dev] [PATCH] i965: verify depth render buffer depth when in fast clear WIP

[Tapani Pälli]

On 05/08/2013 08:06 PM, Eric Anholt wrote:
> Tapani Pälli  writes:
> 
>> Patch makes sure in conservative way that the depth_clear_value
>> is correct and represents max depth of current depth buffer.
>>
>> This fixes the case where user has 16bit color buffer but 24bit
>> depth buffer and 'fb->_DepthMax' has a wrong value. I'm currently
>> investigating how to get _DepthMax corrected on mesa side, but
>> meanwhile this patch will enable correct rendering results for
>> 16bit benchmarks instead of displaying only white color on the
>> screen. This bug does not happen with user created framebuffers,
>> only with window system ones.
> 
> _DepthMax should actually get fixed, instead.  _DepthMax should have
> nothing to do with color bits per pixel.
> 


Yes I agree, I'm investigating the root cause in framebuffer
renderbuffer mgmt. I know color buffer depth should not matter here but
that is basically the environment where bug is currently reproduced.

// Tapani




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

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Roland Scheidegger]

Am 09.05.2013 03:55, schrieb Bryan Cain:
> On 05/08/2013 03:26 PM, Roland Scheidegger wrote:
>> There's some other
>> somewhat bogus code with comments saying UCMP should be used instead of
>> some poor emulation with i2f instructions.
> 
> Yeah, sorry about that.  I wrote that code (and comment) a few days
> before the UCMP opcode was added to TGSI, and didn't notice until today
> that it was never updated to actually use UCMP.  There are a few changes
> and clean-ups I've been wanting to make to glsl_to_tgsi anyway - I'll
> include an update to emit UCMP if someone hasn't already done so by the
> time I finish that and send out a patch set.
> 

I looked at it and it's not really that bogus after all just suboptimal.
But seemed to require too much effort to fix quickly, so I only bothered
to fix the weird USNE/UCMP with negation sequence.

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

[Mesa-dev] [PATCH] glsl: Optimize AND/OR reductions used in vec4 comparisons.

[Matt Turner]

For vec4 equality comparisons we emit

   (and (and (and a b) c) d)

which leads to three dependent instructions. We can reassociate the
operands which allows the first two instructions to be issued
independently. Turn it into:

   (and (and a b) (and c d))

Do the same thing for ORs, used in vec4 inequality comparisons.
---
Maybe we should generally recognize reduction operations and reassociate
operands to reduce tree depth? Do we see large reductions in real shaders?

 src/glsl/opt_algebraic.cpp | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index d706a6a..af0229c 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -32,8 +32,11 @@
 #include "ir_visitor.h"
 #include "ir_rvalue_visitor.h"
 #include "ir_optimization.h"
+#include "ir_builder.h"
 #include "glsl_types.h"
 
+using namespace ir_builder;
+
 namespace {
 
 /**
@@ -351,6 +354,20 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   } else if (is_vec_zero(op_const[0]) || is_vec_zero(op_const[1])) {
 this->progress = true;
 return ir_constant::zero(mem_ctx, ir->type);
+  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_and) {
+ /* Translates (and (and (and a b) c) d) into
+  *(and (and a b) (and c d)).
+  * This allows the independent ANDs to be issued at the same time.
+  */
+ ir_expression *expr = op_expr[1]->operands[1]->as_expression();
+
+ if (expr && expr->operation == ir_binop_logic_and) {
+ir->operands[0] = logic_and(ir->operands[0],
+
ir->operands[1]->as_expression()->operands[0]);
+ir->operands[1] = logic_and(expr->operands[0],
+expr->operands[1]);
+this->progress = true;
+ }
   }
   break;
 
@@ -389,6 +406,20 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
 
 this->progress = true;
 return new(mem_ctx) ir_constant(ir->type, &data);
+  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_or) {
+ /* Translates (or (or (or a b) c) d) into
+  *(or (or a b) (or c d)).
+  * This allows the independent ORs to be issued at the same time.
+  */
+ ir_expression *expr = op_expr[1]->operands[1]->as_expression();
+
+ if (expr && expr->operation == ir_binop_logic_or) {
+ir->operands[0] = logic_or(ir->operands[0],
+   
ir->operands[1]->as_expression()->operands[0]);
+ir->operands[1] = logic_or(expr->operands[0],
+   expr->operands[1]);
+this->progress = true;
+ }
   }
   break;
 
-- 
1.8.1.5

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

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Bryan Cain]

On 05/08/2013 03:26 PM, Roland Scheidegger wrote:
> There's some other
> somewhat bogus code with comments saying UCMP should be used instead of
> some poor emulation with i2f instructions.

Yeah, sorry about that.  I wrote that code (and comment) a few days
before the UCMP opcode was added to TGSI, and didn't notice until today
that it was never updated to actually use UCMP.  There are a few changes
and clean-ups I've been wanting to make to glsl_to_tgsi anyway - I'll
include an update to emit UCMP if someone hasn't already done so by the
time I finish that and send out a patch set.

Bryan

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

Re: [Mesa-dev] r600g missing Bump mapping

[Dragomir Ivanov]

Hmm, Vadim... it works indeed. I can't push up to Ultra, but I see the
difference as on your screenshots.
Interestingly when I play it on win with catalyst, everything is WOW, on
r600g is Meh...
Unfortunately I erased windows, so I can't supply screenshot, but
subjectively it was way more beautiful on the same graphics level.


On Thu, May 9, 2013 at 4:15 AM, Vadim Girlin  wrote:

> On 05/09/2013 02:42 AM, Dragomir Ivanov wrote:
>
>> Hi there,
>> I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
>> r600g progress.
>> Game runs fine, but I can't see bump mapping effects as on Catalyst under
>> windows. They are enabled in the options. Does Mesa/r600g support bumps?
>> AMD E-350 here. Evergreen class GPU.
>>
>
> Here are two screenshots made with git mesa on evergreen with Ultra
> settings, the only difference is toggled bump mapping option:
>
> http://i.imgur.com/Cl0hamf.jpg
> http://i.imgur.com/4IsjrR3.jpg
>
> To me it looks like bump mapping works. Could you provide more detailed
> info (with screenshots etc) to demonstrate your issue? Also you might want
> to try resetting game options to default to make sure that you don't have
> any nonstandard tweaks.
>
> Vadim
>
>
>> OpenGL renderer string: Gallium 0.4 on AMD PALM
>>
>>
>> OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2
>>
>>
>> OpenGL core profile shading language version string: 1.40
>>
>> Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013
>> x86_64 GNU/Linux
>>
>>
>>
>> __**_
>> 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] r600g missing Bump mapping

[Vadim Girlin]

On 05/09/2013 02:42 AM, Dragomir Ivanov wrote:

Hi there,
I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
r600g progress.
Game runs fine, but I can't see bump mapping effects as on Catalyst under
windows. They are enabled in the options. Does Mesa/r600g support bumps?
AMD E-350 here. Evergreen class GPU.


Here are two screenshots made with git mesa on evergreen with Ultra 
settings, the only difference is toggled bump mapping option:


http://i.imgur.com/Cl0hamf.jpg
http://i.imgur.com/4IsjrR3.jpg

To me it looks like bump mapping works. Could you provide more detailed 
info (with screenshots etc) to demonstrate your issue? Also you might 
want to try resetting game options to default to make sure that you 
don't have any nonstandard tweaks.


Vadim



OpenGL renderer string: Gallium 0.4 on AMD PALM


OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2


OpenGL core profile shading language version string: 1.40

Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013
x86_64 GNU/Linux



___
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] intel: Fix render-to-texture in non-FinishRenderTexture cases.

[Kenneth Graunke]

On 05/07/2013 03:53 PM, Eric Anholt wrote:

With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
renderbuffers that are also textures, so the core Mesa FinishRenderTexture
hook doesn't get called.  That hook also wasn't called in various cases
within the driver where we'd update texture contents using the render
cache (like glCopyTexSubImage) that resulted in
intel_batchbuffer_emit_mi_flush().

To fix it, track a set of rendered-to BOs in our context, which is
cleared at batch wrap or emit_mi_flush time, and do an emit_mi_flush if
one of our textures is in that set.

This change doesn't turn the other emit_mi_flushes (such as intel_blit.c
operations) into render_cache_set operations yet, as that would increase the
size of our set and we expect that those operations get immediately flushed
anyway.

No statistically significant performance difference in cairo-gl (n=53/54, slow
turbo outliers removed), despite spending ~1% CPU in these set operations.


I noticed that you call intel_render_cache_set_check_flush() for 
0..BRW_MAX_TEX_UNITS.  Each of those calls computes the hash pointer and 
searches the cache, which isn't free...but if you ever find an entry, 
you clear the whole cache.


You might be able to speed this up slightly by maintaining a boolean "is 
the set empty?" flag.  Just flag it in add, and unflag it in clear.


The i965 parts of this are:
Reviewed-by: Kenneth Graunke 

I'll try and test it tomorrow.

I have no idea about the 8xx/9xx code.  I'll trust you on that.



Fixes piglit EGL_KHR_gl_renderbuffer_image/renderbuffer-texture.
---
  src/mesa/drivers/dri/i915/i830_texstate.c  |  3 ++
  src/mesa/drivers/dri/i915/i915_texstate.c  |  3 ++
  src/mesa/drivers/dri/i915/intel_tris.c | 22 
  src/mesa/drivers/dri/i965/brw_draw.c   | 23 +---
  src/mesa/drivers/dri/i965/brw_misc_state.c |  5 +++
  src/mesa/drivers/dri/intel/intel_batchbuffer.c |  5 +++
  src/mesa/drivers/dri/intel/intel_context.h |  7 
  src/mesa/drivers/dri/intel/intel_fbo.c | 49 ++
  src/mesa/drivers/dri/intel/intel_fbo.h |  6 
  9 files changed, 112 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i830_texstate.c 
b/src/mesa/drivers/dri/i915/i830_texstate.c
index f186fac..6b1dbf0 100644
--- a/src/mesa/drivers/dri/i915/i830_texstate.c
+++ b/src/mesa/drivers/dri/i915/i830_texstate.c
@@ -33,6 +33,7 @@

  #include "intel_mipmap_tree.h"
  #include "intel_tex.h"
+#include "intel_fbo.h"

  #include "i830_context.h"
  #include "i830_reg.h"
@@ -128,6 +129,8 @@ i830_update_tex_unit(struct intel_context *intel, GLuint 
unit, GLuint ss3)
 GLubyte border[4];
 GLuint dst_x, dst_y;

+   intel_render_cache_set_check_flush(intel, intelObj->mt->region->bo);
+
 memset(state, 0, sizeof(*state));

 /*We need to refcount these. */
diff --git a/src/mesa/drivers/dri/i915/i915_texstate.c 
b/src/mesa/drivers/dri/i915/i915_texstate.c
index 43c802b..148da15 100644
--- a/src/mesa/drivers/dri/i915/i915_texstate.c
+++ b/src/mesa/drivers/dri/i915/i915_texstate.c
@@ -33,6 +33,7 @@

  #include "intel_mipmap_tree.h"
  #include "intel_tex.h"
+#include "intel_fbo.h"

  #include "i915_context.h"
  #include "i915_reg.h"
@@ -151,6 +152,8 @@ i915_update_tex_unit(struct intel_context *intel, GLuint 
unit, GLuint ss3)
 GLubyte border[4];
 GLfloat maxlod;

+   intel_render_cache_set_check_flush(intel, intelObj->mt->region->bo);
+
 memset(state, 0, sizeof(*state));

 /*We need to refcount these. */
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c 
b/src/mesa/drivers/dri/i915/intel_tris.c
index 7c60d84..1f27243 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -52,6 +52,8 @@
  #include "intel_batchbuffer.h"
  #include "intel_buffers.h"
  #include "intel_reg.h"
+#include "intel_fbo.h"
+#include "intel_mipmap_tree.h"
  #include "i830_context.h"
  #include "i830_reg.h"
  #include "i915_context.h"
@@ -61,6 +63,22 @@ static void intelRasterPrimitive(struct gl_context * ctx, 
GLenum rprim,
   GLuint hwprim);

  static void
+mark_render_cache(struct intel_context *intel)
+{
+   struct gl_context *ctx = &intel->ctx;
+   struct gl_framebuffer *fb = ctx->DrawBuffer;
+   struct intel_renderbuffer *depth_irb =
+  intel_get_renderbuffer(fb, BUFFER_DEPTH);
+   struct intel_renderbuffer *color_irb =
+  intel_renderbuffer(fb->_ColorDrawBuffers[0]);
+
+   if (color_irb)
+  intel_render_cache_set_add_bo(intel, color_irb->mt->region->bo);
+   if (depth_irb)
+  intel_render_cache_set_add_bo(intel, depth_irb->mt->region->bo);
+}
+
+static void
  intel_flush_inline_primitive(struct intel_context *intel)
  {
 GLuint used = intel->batch.used - intel->prim.start_ptr;
@@ -75,6 +93,8 @@ intel_flush_inline_primitive(struct intel_context *intel)
 intel->batch.map[intel->prim.start_ptr] =
_3DPRIMITIVE | intel->prim.primit

[Mesa-dev] [PATCH] R600: Expand SUB for v2i32/v4i32

[Aaron Watry]

Signed-off-by: Aaron Watry 
---
 lib/Target/R600/R600ISelLowering.cpp |2 ++
 test/CodeGen/R600/sub.ll |   15 +++
 2 files changed, 17 insertions(+)
 create mode 100644 test/CodeGen/R600/sub.ll

diff --git a/lib/Target/R600/R600ISelLowering.cpp 
b/lib/Target/R600/R600ISelLowering.cpp
index b982279..7252235 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -54,6 +54,8 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
   setOperationAction(ISD::SRL, MVT::v2i32, Expand);
   setOperationAction(ISD::SRA, MVT::v4i32, Expand);
   setOperationAction(ISD::SRA, MVT::v2i32, Expand);
+  setOperationAction(ISD::SUB, MVT::v4i32, Expand);
+  setOperationAction(ISD::SUB, MVT::v2i32, Expand);
   setOperationAction(ISD::UINT_TO_FP, MVT::v4i32, Expand);
   setOperationAction(ISD::UDIV, MVT::v4i32, Expand);
   setOperationAction(ISD::UREM, MVT::v4i32, Expand);
diff --git a/test/CodeGen/R600/sub.ll b/test/CodeGen/R600/sub.ll
new file mode 100644
index 000..12bfba3
--- /dev/null
+++ b/test/CodeGen/R600/sub.ll
@@ -0,0 +1,15 @@
+;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
+
+;CHECK: SUB_INT T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: SUB_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+
+define void @test(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* %in) {
+  %b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
+  %a = load <4 x i32> addrspace(1) * %in
+  %b = load <4 x i32> addrspace(1) * %b_ptr
+  %result = sub <4 x i32> %a, %b
+  store <4 x i32> %result, <4 x i32> addrspace(1)* %out
+  ret void
+}
-- 
1.7.10.4

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

[Mesa-dev] [PATCH] st/mesa: fix weird UCMP opcode use for bool ubo load

[sroland]

From: Roland Scheidegger 

I don't know what this code was trying to do but whatever it was it couldn't
have worked since negation of integer boolean inputs while not specified as
outright illegal (not yet at least) won't do anything since it doesn't affect
the result of comparison with zero at all. In fact it looks like the whole
instruction can just be omitted.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f2eb3e7..08b2d7a 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1945,8 +1945,6 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
 
   if (ir->type->base_type == GLSL_TYPE_BOOL) {
  emit(ir, TGSI_OPCODE_USNE, result_dst, cbuf, st_src_reg_for_int(0));
- result_src.negate = 1;
- emit(ir, TGSI_OPCODE_UCMP, result_dst, result_src, 
st_src_reg_for_int(~0), st_src_reg_for_int(0));
   } else {
  emit(ir, TGSI_OPCODE_MOV, result_dst, cbuf);
   }
@@ -2388,8 +2386,8 @@ glsl_to_tgsi_visitor::visit(ir_assignment *ir)
  if (native_integers) {
 /* This is necessary because TGSI's CMP instruction expects the
  * condition to be a float, and we store booleans as integers.
- * If TGSI had a UCMP instruction or similar, this extra
- * instruction would not be necessary.
+ * TODO: really want to avoid i2f path and use UCMP. Requires
+ * changes to process_move_condition though too.
  */
 condition_temp = get_temp(glsl_type::vec4_type);
 condition.negate = 0;
-- 
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] glsl/linker: Fail if gl_FragDepth layouts don't match.

[Fabian Bieler]

This fixes Piglit test shaders/link-mismatch-layout-02.
---
 src/glsl/linker.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 4415b8d..4bc0eee 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -561,6 +561,7 @@ cross_validate_globals(struct gl_shader_program *prog,
   "All redeclarations of gl_FragDepth in all "
   "fragment shaders in a single program must have "
   "the same set of qualifiers.");
+ return false;
   }
 
   if (var->used && layout_differs) {
@@ -570,6 +571,7 @@ cross_validate_globals(struct gl_shader_program *prog,
   "redeclared with the same layout qualifier in "
   "all fragment shaders that have assignments to "
   "gl_FragDepth");
+ return false;
   }
}
 
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 4/5] glsl/linker: Fail if gl_FragCoord layouts don't match.

[Fabian Bieler]

Fail linking if gl_FragCoord is used with different layout qualifiers in
seperate shader objects.

This fixes Piglit test shaders/link-mismatch-layout-01.
---
 src/glsl/linker.cpp | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 2b30d2b..4415b8d 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -646,6 +646,40 @@ cross_validate_globals(struct gl_shader_program *prog,
mode_string(var), var->name);
return false;
 }
+
+   /* Validate layout qualifiers for gl_FragCoord.
+*
+* From the ARB_fragment_coord_conventions specs:
+*
+*"If gl_FragCoord is redeclared in any fragment shader in a 
program,
+*it must be redeclared in all the fragment shaders in that 
program
+*that have a static use of gl_FragCoord. All redeclarations of
+*gl_FragCoord in all fragment shaders in a single program must 
have
+*the same set of qualifiers."
+*/
+   if (strcmp(var->name, "gl_FragCoord") == 0) {
+  const bool layout_differs = var->pixel_center_integer != 
existing->pixel_center_integer ||
+  var->origin_upper_left != 
existing->origin_upper_left;
+
+  if (var->redeclared && layout_differs) {
+ linker_error(prog,
+  "All redeclarations of gl_FragCoord in all "
+  "fragment shaders in a single program must have "
+  "the same set of qualifiers.");
+ return false;
+  }
+
+  if (var->used && layout_differs) {
+ linker_error(prog,
+  "If gl_FragCoord is redeclared with a layout "
+  "qualifier in any fragment shader, it must be "
+  "redeclared with the same layout qualifier in "
+  "all fragment shaders that read from "
+  "gl_FragCoord.");
+ return false;
+  }
+   }
+
 } else
variables.add_variable(var);
   }
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 3/5] glsl: Fail if gl_FragCoord layouts don't match.

[Fabian Bieler]

Fail compile if gl_FragCoord is redeclared with different layout qualifiers in
one shader.
---
 src/glsl/ast_to_hir.cpp | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 63fbd5a..d6362b0 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2213,6 +2213,16 @@ get_variable_being_redeclared(ir_variable *var, 
ast_declaration *decl,
   /* Allow redeclaration of gl_FragCoord for ARB_fcc layout
* qualifiers.
*/
+
+  /* Prevent inconsistent redeclaration of layout qualifier. */
+  if (earlier->redeclared
+ && (earlier->origin_upper_left != var->origin_upper_left ||
+ earlier->pixel_center_integer != var->pixel_center_integer)) {
+_mesa_glsl_error(&loc, state,
+ "`gl_FragCoord' redeclared with different layout "
+ "qualifier");
+  }
+
   earlier->origin_upper_left = var->origin_upper_left;
   earlier->pixel_center_integer = var->pixel_center_integer;
 
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 2/5] glsl: Add redeclation flag to ir_variable.

[Fabian Bieler]

It is illegal to redeclare builtin variables with incompatible layout
qualifiers in seprerate shader objects that are linked together. Since a
redeclaration without any layout qualifiers can be incompatible with another
redeclartion where no redeclaration wouldn't be, it can be necessary to know
wether a variable was redeclared.
---
 src/glsl/ast_to_hir.cpp | 1 +
 src/glsl/ir.cpp | 1 +
 src/glsl/ir.h   | 7 +++
 src/glsl/ir_clone.cpp   | 1 +
 4 files changed, 10 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 9ef73b5..63fbd5a 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2271,6 +2271,7 @@ get_variable_being_redeclared(ir_variable *var, 
ast_declaration *decl,
   _mesa_glsl_error(&loc, state, "`%s' redeclared", decl->identifier);
}
 
+   earlier->redeclared = true;
return earlier;
 }
 
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 2c54525..c535c5e 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1536,6 +1536,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
const char *name,
this->pixel_center_integer = false;
this->depth_layout = ir_depth_layout_none;
this->used = false;
+   this->redeclared = false;
 
if (type && type->base_type == GLSL_TYPE_SAMPLER)
   this->read_only = true;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 6783eca..fae0c30 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -415,6 +415,13 @@ public:
unsigned invariant:1;
 
/**
+* Was this variable redeclared?
+*
+* This is only maintained in the ast_to_hir.cpp path.
+*/
+   unsigned redeclared:1;
+
+   /**
 * Has this variable been used for reading or writing?
 *
 * Several GLSL semantic checks require knowledge of whether or not a
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index 5b42935..2abf62f 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -47,6 +47,7 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
var->read_only = this->read_only;
var->centroid = this->centroid;
var->invariant = this->invariant;
+   var->redeclared = this->redeclared;
var->interpolation = this->interpolation;
var->location = this->location;
var->index = this->index;
-- 
1.8.1.2

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

[Mesa-dev] [PATCH 1/5] glsl: Overwrite storage qualifier of builtin redeclarations.

[Fabian Bieler]

Prior to GLSL version 1.3 builtin variables such as gl_Position have no storage
qualifiers (in or out). However, the internal declarations in Mesa have storage
qualifiers regardless of version.

As the code to identify a redeclaration checks for identical storage qualifiers
you cannot redeclare builtins in GLSL 1.1 and 1.2.

To work around this, this patch copies the storage qualifier from the internal
declaration to the redeclaration.
---
 src/glsl/ast_to_hir.cpp | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index e595110..9ef73b5 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2168,6 +2168,19 @@ get_variable_being_redeclared(ir_variable *var, 
ast_declaration *decl,
 
YYLTYPE loc = decl->get_location();
 
+   /* Prior to version GLSL 1.3 builtin variables were not declared with
+* storage qualifiers, however our predeclarations have storage qualifiers
+* regardless of version. When a builtin is redeclared the code below checks
+* that the two declarations have identical storage qualifiers.
+*
+* To work around this copy the storage qualifier to the redeclaration.
+*/
+   if (!state->is_version(130, 300)
+   && strncmp(var->name, "gl_", 3) == 0
+   && var->mode == ir_var_auto) {
+  var->mode = earlier->mode;
+   }
+
/* From page 24 (page 30 of the PDF) of the GLSL 1.50 spec,
 *
 * "It is legal to declare an array without a size and then
-- 
1.8.1.2

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

[Mesa-dev] r600g missing Bump mapping

[Dragomir Ivanov]

Hi there,
I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
r600g progress.
Game runs fine, but I can't see bump mapping effects as on Catalyst under
windows. They are enabled in the options. Does Mesa/r600g support bumps?
AMD E-350 here. Evergreen class GPU.

OpenGL renderer string: Gallium 0.4 on AMD PALM


OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2


OpenGL core profile shading language version string: 1.40

Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013
x86_64 GNU/Linux
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Treat Haswell as 75 in the surface format table.

[Matt Turner]

On Wed, May 8, 2013 at 2:39 PM, Kenneth Graunke  wrote:
> Much like we do for G45.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index ee2c9f1..09c0a9a 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -488,7 +488,7 @@ brw_init_surface_formats(struct brw_context *brw)
> gl_format format;
>
> gen = intel->gen * 10;
> -   if (intel->is_g4x)
> +   if (intel->is_g4x || intel->is_haswell)
>gen += 5;
>
> for (format = MESA_FORMAT_NONE + 1; format < MESA_FORMAT_COUNT; format++) 
> {
> --

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

[Mesa-dev] [PATCH] i965: Treat Haswell as 75 in the surface format table.

[Kenneth Graunke]

Much like we do for G45.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index ee2c9f1..09c0a9a 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -488,7 +488,7 @@ brw_init_surface_formats(struct brw_context *brw)
gl_format format;
 
gen = intel->gen * 10;
-   if (intel->is_g4x)
+   if (intel->is_g4x || intel->is_haswell)
   gen += 5;
 
for (format = MESA_FORMAT_NONE + 1; format < MESA_FORMAT_COUNT; format++) {
-- 
1.8.2.1

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

Re: [Mesa-dev] [PATCH mesa] wayland: Disable prime support on buggy kernels

[Jonas Ådahl]

On Tue, Apr 23, 2013 at 3:54 PM, Ander Conselvan de Oliveira
 wrote:
> Linux kernel 3.8 shipped with a bug in the prime fd passing code that
> makes it unreliable. As of this writing, it seems unlikely that 3.9
> will contain the fix for the issue.
>
> This patch disable prime support when running on top of those kernels,
> in order to prevent unexpected behavior when running a Wayland
> compositor.
>
> Commit be8a42ae60addd8b6092535c11b42d099d6470ec in Linus tree introduces
> the problem, which can be fixed by the patch below (not upstream yet):
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037716.html
> ---
>  src/egl/drivers/dri2/egl_dri2.c |   36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 06a21d7..13b9107 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "egl_dri2.h"
>
> @@ -1557,6 +1558,38 @@ static struct wayland_drm_callbacks wl_drm_callbacks = 
> {
>  };
>
>  static EGLBoolean
> +kernel_prime_support_not_buggy()
> +{
> +   struct utsname un;
> +
> +   /* Linux kernel 3.8 shipped with a bug in the prime fd passing code that
> +* makes it unreliable. As of this writing, it seems unlikely that 3.9
> +* will contain the fix for the issue. Disable prime support when running
> +* on top of those kernels, in order to prevent unexpected behavior when
> +* running a Wayland compositor.
> +*
> +* Commit be8a42ae60addd8b6092535c11b42d099d6470ec in Linus tree 
> introduces
> +* the problem, which can be fixed by the patch below (not upstream yet):
> +* http://lists.freedesktop.org/archives/dri-devel/2013-April/037716.html
> +*/
> +   if (uname(&un) == -1) {
> +  _eglLog(_EGL_INFO,
> +  "DRI2: wayland prime support disabled: unknown kernel 
> version");
> +  return EGL_FALSE;
> +   }
> +
> +   if (strncmp(un.sysname, "Linux", strlen("Linux")) == 0 &&
> +   (strncmp(un.release, "3.8.", strlen("3.8.")) == 0 ||
> +strncmp(un.release, "3.9.", strlen("3.9.")) == 0)) {

I think if we should test against kernel releases we can disable for
anything older than the first release that has the fix as it doesn't
seem to work on older versions either. At least in my case I get what
looks like the same issue when prime support enabled when running
kernel version 3.5.

Jonas

> + _eglLog(_EGL_INFO,
> + "DRI2: wayland prime support disabled: buggy kernel");
> + return EGL_FALSE;
> +   }
> +
> +   return EGL_TRUE;
> +}
> +
> +static EGLBoolean
>  dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay *disp,
>  struct wl_display *wl_dpy)
>  {
> @@ -1575,7 +1608,8 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, 
> _EGLDisplay *disp,
> ret = drmGetCap(dri2_dpy->fd, DRM_CAP_PRIME, &cap);
> if (ret == 0 && cap == (DRM_PRIME_CAP_IMPORT | DRM_PRIME_CAP_EXPORT) &&
> dri2_dpy->image->base.version >= 7 &&
> -   dri2_dpy->image->createImageFromFds != NULL)
> +   dri2_dpy->image->createImageFromFds != NULL &&
> +   kernel_prime_support_not_buggy())
>flags |= WAYLAND_DRM_PRIME;
>
> dri2_dpy->wl_server_drm =
> --
> 1.7.10.4
>
> ___
> 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 1/2] glx: Ensure that glXWaitX actually waits for X.

[Eric Anholt]

Fredrik Höglund  writes:

> On Tuesday 07 May 2013, Eric Anholt wrote:
>> Ever since fake front was introduced in
>> 63b51b5cf17ddde09b72a2811296f37b9a4c5ad2, we were skipping the XSync() in
>> the non-fake-front path, so compositors like Firefox's GL canvas were
>> having to manually put it in outside of glXWaitX().
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52930
>> ---
>>  src/glx/dri2_glx.c | 21 +
>>  1 file changed, 17 insertions(+), 4 deletions(-)
>> 
>> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
>> index 7ce5775..3cdd249 100644
>> --- a/src/glx/dri2_glx.c
>> +++ b/src/glx/dri2_glx.c
>> @@ -639,10 +639,23 @@ dri2_wait_x(struct glx_context *gc)
>> struct dri2_drawable *priv = (struct dri2_drawable *)
>>GetGLXDRIDrawable(gc->currentDpy, gc->currentDrawable);
>>  
>> -   if (priv == NULL || !priv->have_fake_front)
>> -  return;
>> -
>> -   dri2_copy_drawable(priv, DRI2BufferFakeFrontLeft, DRI2BufferFrontLeft);
>> +   if (priv != NULL && priv->have_fake_front) {
>> +  /* Ask the server to update our copy of the front buffer from the real
>> +   * front buffer.  This will round-trip with the server, so we can skip
>> +   * the XSync().
>> +   */
>> +  dri2_copy_drawable(priv, DRI2BufferFakeFrontLeft, 
>> DRI2BufferFrontLeft);
>> +   } else {
>> +  /* From the GLX 1.4 spec, page 33:
>> +   *
>> +   * "X rendering calls made prior to glXWaitX are guaranteed to be
>> +   *  executed before OpenGL rendering calls made after
>> +   *  glXWaitX. While the same result can be achieved using XSync,
>> +   *  glXWaitX does not require a round trip to the server, and may
>> +   *  therefore be more efficient."
>> +   */
>> +  XSync(gc->currentDpy, False);
>
> I think this could be improved a bit by calling xcb_get_input_focus() followed
> by xcb_flush() here, and forcing the reply the next time the command buffer
> is about to be flushed.

That would require plumbing this bit of GLX down to the driver's
batchbuffer flushing, which is a fair chunk of work.


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

Re: [Mesa-dev] Improved Patch review using Gerrit

[Eric Anholt]

Christoph Brill  writes:

> Hi list,
>
> I'm trying to follow the patches and patchsets sent to mesa-dev and
> really like the process of how they get reviewed. It's a good way of
> catching bugs before they get committed. But currently this approach
> has a downside (at least for me): It's easy to miss a patch and
> happens from time to time to others as well (see
> http://lists.freedesktop.org/archives/mesa-dev/2013-May/039178.html )
>
> Has anyone thought about using Gerrit for code reviews (like done for
> Libreoffice at https://gerrit.libreoffice.org/ )? I like the way it
> integrates with git and might be a good idea to use for mesa-dev (and
> maybe even dri-devel) as well.

Yeah, we've thought about it, and even asked fdo admins to install a
jenkins setup for continuous integration as a prelude to possibly
putting in gerrit to get testing along with the review process.  The
major downside to gerritt that I see is the loss of offline reviewing of
patches, which is how I do basically all my patch review.


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

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Roland Scheidegger]

Am 08.05.2013 17:17, schrieb Marek Olšák:
> The SUB opcode is not emitted by GLSL, however this may change in the
> future. I don't think using specialized opcodes instead of the
> modifiers will make anyone's life easier (the modifiers must be
> implemented anyway).
> 
> If you really want people to follow the TGSI documentation, there
> should be a utility function which validates TGSI and st/mesa should
> reject shaders which are invalid. Right now, GLSL-to-TGSI generates
> UCMP with the first operand negated.
This looks like a simple bug (negating integers isn't going to change
the outcome of the logic test the input is used for...). I don't know
what the glsl translation is trying ot do there, seems like it wants to
set ~0 or 0 but the UCMP looks not only very bogus but completely
unnecessary too (the preceding USNE will already set ~0 or 0 and if it
wants the opposite it should use USEQ instead). There's some other
somewhat bogus code with comments saying UCMP should be used instead of
some poor emulation with i2f instructions.
But in any case this is really independent from clarifying what these
opcodes are supposed to do.

Roland



> 
> Marek
> 
> 
> 
> On Wed, May 8, 2013 at 3:51 PM, Roland Scheidegger  wrote:
>> Am 08.05.2013 12:47, schrieb Marek Olšák:
>>> Modifiers are actually very useful with MOV. However I don't think the
>>> modifiers really care what the type is. They just change the sign bit
>>> of float (which is a bitwise operation). Also, UCMP doesn't do
>>> anything with the 2nd and 3rd argument, so their types don't matter.
>> Well, they do matter for the input modifiers.
>> They might just change the most significant bit on your hardware but
>> that's not how they are defined in tgsi.
>> I don't really care that much if the 2nd and 3rd argument to ucmp are
>> ints or floats (it's true for d3d10 movc translation floats are the
>> natural choice but we can easily translate that to several ops instead,
>> e.g. mov's with modifiers followed by ucmp). I do care however that all
>> drivers treat them the same, not like now where softpipe will do two's
>> complement negation on src input modifiers whereas llvmpipe will flip
>> the sign bit.
>>
>>>
>>> I think the ABS and SUB opcodes should be removed in favor of the modifiers.
>> Those are in very widespread use and at least for SUB it definitely
>> avoids additional effort for drivers which can't do input modifiers
>> natively.
>>
>> Roland
>>
>>
>>>
>>> Marek
>>>
>>> On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
>>>  wrote:
 On 08.05.2013 03:48, srol...@vmware.com wrote:
> From: Roland Scheidegger 
>
> UCMP while an integer opcode isn't really consistently implemented as
> having all integer arguments. softpipe will assume all arguments are
> ints, whereas gallivm has the arguments defined as untyped which
> means they'll get treated as floats. This means input modifiers will
> not work the same. Fix this by saying only first arg is an integer,
> which seems more useful than making all arguments integers - this would
> be similar to d3d10 movc opcode.
> ---
>  src/gallium/docs/source/tgsi.rst |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index 3af1fb7..852f8a0 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by 
> PIPE_SHADER_CAP_INTEGERS (all of them?)
>
>  .. opcode:: UCMP - Integer Conditional Move
>
> +.. note::
> +
> +   Only the first source arg is an integer, the 2nd and 3rd ones are
> +   considered floats (for input modifier purposes).
> +

 As long as you patch up all the occurrences of
 tgsi_opcode_infer_src_type and make it take an argument to identify the
 source ...

 I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
 least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated 
 on.
 For the ordinary MOV we have NEG and ABS, and for UCMP the backend
 optimizer can take care of merging modifiers into the instruction
 (nvc0's UCMP (slct u32) doesn't support modifiers)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] R600: Expand MUL for v4i32/v2i32

[Aaron Watry]

Fixes piglit test for OpenCL builtin mul24, and allows mad24 to run.

Signed-off-by: Aaron Watry 
---
 lib/Target/R600/R600ISelLowering.cpp |2 ++
 test/CodeGen/R600/mul.ll |   16 
 2 files changed, 18 insertions(+)
 create mode 100644 test/CodeGen/R600/mul.ll

diff --git a/lib/Target/R600/R600ISelLowering.cpp 
b/lib/Target/R600/R600ISelLowering.cpp
index ac56ed8..b982279 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -43,6 +43,8 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
   setOperationAction(ISD::AND,  MVT::v4i32, Expand);
   setOperationAction(ISD::FP_TO_SINT, MVT::v4i32, Expand);
   setOperationAction(ISD::FP_TO_UINT, MVT::v4i32, Expand);
+  setOperationAction(ISD::MUL,  MVT::v2i32, Expand);
+  setOperationAction(ISD::MUL,  MVT::v4i32, Expand);
   setOperationAction(ISD::OR, MVT::v4i32, Expand);
   setOperationAction(ISD::OR, MVT::v2i32, Expand);
   setOperationAction(ISD::SINT_TO_FP, MVT::v4i32, Expand);
diff --git a/test/CodeGen/R600/mul.ll b/test/CodeGen/R600/mul.ll
new file mode 100644
index 000..7278e90
--- /dev/null
+++ b/test/CodeGen/R600/mul.ll
@@ -0,0 +1,16 @@
+;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
+
+; mul24 and mad24 are affected
+;CHECK: MULLO_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MULLO_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MULLO_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MULLO_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+
+define void @test(<4 x i32> addrspace(1)* %out, <4 x i32> addrspace(1)* %in) {
+  %b_ptr = getelementptr <4 x i32> addrspace(1)* %in, i32 1
+  %a = load <4 x i32> addrspace(1) * %in
+  %b = load <4 x i32> addrspace(1) * %b_ptr
+  %result = mul <4 x i32> %a, %b
+  store <4 x i32> %result, <4 x i32> addrspace(1)* %out
+  ret void
+}
-- 
1.7.10.4

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

[Mesa-dev] [Bug 58718] Crash in src_register() during glClear() call

[bugzilla-daemon]

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

--- Comment #17 from Keith Kriewall  ---
I posted this issue to Microsoft and they have released a hotfix for Visual
Studio 2010 SP1 to correct it:
  http://support.microsoft.com/kb/2836024

-- 
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 2/2] R600: Expand SRA for v4i32/v2i32

[Aaron Watry]

Signed-off-by: Aaron Watry 

v2: Add v4i32 test
---
 lib/Target/R600/R600ISelLowering.cpp |2 ++
 test/CodeGen/R600/sra.ll |   13 +
 2 files changed, 15 insertions(+)
 create mode 100644 test/CodeGen/R600/sra.ll

diff --git a/lib/Target/R600/R600ISelLowering.cpp 
b/lib/Target/R600/R600ISelLowering.cpp
index 6dec4d1..ac56ed8 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -50,6 +50,8 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
   setOperationAction(ISD::SHL, MVT::v2i32, Expand);
   setOperationAction(ISD::SRL, MVT::v4i32, Expand);
   setOperationAction(ISD::SRL, MVT::v2i32, Expand);
+  setOperationAction(ISD::SRA, MVT::v4i32, Expand);
+  setOperationAction(ISD::SRA, MVT::v2i32, Expand);
   setOperationAction(ISD::UINT_TO_FP, MVT::v4i32, Expand);
   setOperationAction(ISD::UDIV, MVT::v4i32, Expand);
   setOperationAction(ISD::UREM, MVT::v4i32, Expand);
diff --git a/test/CodeGen/R600/sra.ll b/test/CodeGen/R600/sra.ll
new file mode 100644
index 000..972542d
--- /dev/null
+++ b/test/CodeGen/R600/sra.ll
@@ -0,0 +1,13 @@
+; RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
+
+; CHECK: @ashr_v4i32
+; CHECK: ASHR * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+; CHECK: ASHR * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+; CHECK: ASHR * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+; CHECK: ASHR * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+
+define void @ashr_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> %a, <4 x i32> 
%b) {
+  %result = ashr <4 x i32> %a, %b
+  store <4 x i32> %result, <4 x i32> addrspace(1)* %out
+  ret void
+}
-- 
1.7.10.4

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

[Mesa-dev] [PATCH 1/2] R600: Expand vselect for v4i32 and v2i32

[Aaron Watry]

Signed-off-by: Aaron Watry 

v2: Add vselect v4i32 test
---
 lib/Target/R600/R600ISelLowering.cpp |3 +++
 test/CodeGen/R600/vselect.ll |   17 +
 2 files changed, 20 insertions(+)
 create mode 100644 test/CodeGen/R600/vselect.ll

diff --git a/lib/Target/R600/R600ISelLowering.cpp 
b/lib/Target/R600/R600ISelLowering.cpp
index c6e2136..6dec4d1 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -78,6 +78,9 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
   setOperationAction(ISD::SELECT, MVT::i32, Custom);
   setOperationAction(ISD::SELECT, MVT::f32, Custom);
 
+  setOperationAction(ISD::VSELECT, MVT::v4i32, Expand);
+  setOperationAction(ISD::VSELECT, MVT::v2i32, Expand);
+
   // Legalize loads and stores to the private address space.
   setOperationAction(ISD::LOAD, MVT::i32, Custom);
   setOperationAction(ISD::LOAD, MVT::v2i32, Custom);
diff --git a/test/CodeGen/R600/vselect.ll b/test/CodeGen/R600/vselect.ll
new file mode 100644
index 000..6e459df
--- /dev/null
+++ b/test/CodeGen/R600/vselect.ll
@@ -0,0 +1,17 @@
+;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
+
+; CHECK: @test_select_v4i32
+; CHECK: CNDE_INT T{{[0-9]+\.[XYZW], PV\.[xyzw], T[0-9]+\.[XYZW], 
T[0-9]+\.[XYZW]}}
+; CHECK: CNDE_INT * T{{[0-9]+\.[XYZW], PV\.[xyzw], T[0-9]+\.[XYZW], 
T[0-9]+\.[XYZW]}}
+; CHECK: CNDE_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
T[0-9]+\.[XYZW]}}
+; CHECK: CNDE_INT * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW], 
T[0-9]+\.[XYZW]}}
+
+define void @test_select_v4i32(<4 x i32> addrspace(1)* %out, <4 x i32> 
addrspace(1)* %in0, <4 x i32> addrspace(1)* %in1) {
+entry:
+  %0 = load <4 x i32> addrspace(1)* %in0
+  %1 = load <4 x i32> addrspace(1)* %in1
+  %cmp = icmp ne <4 x i32> %0, %1
+  %result = select <4 x i1> %cmp, <4 x i32> %0, <4 x i32> %1
+  store <4 x i32> %result, <4 x i32> addrspace(1)* %out
+  ret void
+}
-- 
1.7.10.4

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

[Mesa-dev] R600: Expand vselect and SRA for v2i32 and v4i32 (v2)

[Aaron Watry]

These two patches fix a number of piglit OpenCL test failures on my
HD6850 (Barts).

There are no piglit CL test regressions and the llvm make check runs
without any unexpected failures.

v2: Add tests for v4i32 data type.

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

Re: [Mesa-dev] [PATCH 2/2] gallivm/soa: implement indirect addressing in immediates

[Jose Fonseca]

Series looks good to me.

Jose

- Original Message -
> The support is analogous to the way we handle indirect addressing
> in temporaries, except that we don't have to worry about storing
> (after declarations) and thus we'll able to keep using the old
> code when indirect addressing isn't used. In other words we're
> still using constants directly, unless the instrunction has
> immediate register with indirect addressing.
> 
> Signed-off-by: Zack Rusin 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 ++
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |   78
>  ++-
>  2 files changed, 82 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> index 9d9c742..fd566b1 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> @@ -453,6 +453,12 @@ struct lp_build_tgsi_soa_context
>  */
> LLVMValueRef inputs_array;
>  
> +   /* We allocate/use this array of temps if (1 << TGSI_FILE_IMMEDIATE) is
> +* set in the indirect_files field.
> +*/
> +   LLVMValueRef imms_array;
> +
> +
> struct lp_bld_tgsi_system_values system_values;
>  
> /** bitmask indicating which register files are accessed indirectly */
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 733f0ed..066f64a 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -972,8 +972,58 @@ emit_fetch_immediate(
> unsigned swizzle)
>  {
> struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
> -   LLVMValueRef res = bld->immediates[reg->Register.Index][swizzle];
> -   assert(res);
> +   struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> +   LLVMBuilderRef builder = gallivm->builder;
> +   struct lp_build_context *uint_bld = &bld_base->uint_bld;
> +   struct lp_build_context *float_bld = &bld_base->base;
> +   LLVMValueRef res = NULL;
> +   LLVMValueRef indirect_index = NULL;
> +
> +   if (reg->Register.Indirect) {
> +  indirect_index = get_indirect_index(bld,
> +  reg->Register.File,
> +  reg->Register.Index,
> +  ®->Indirect);
> +   }
> +
> +   if (reg->Register.Indirect) {
> +  LLVMValueRef swizzle_vec =
> + lp_build_const_int_vec(bld->bld_base.base.gallivm,
> +uint_bld->type, swizzle);
> +  LLVMValueRef length_vec =
> + lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
> +bld->bld_base.base.type.length);
> +  LLVMValueRef index_vec;  /* index into the const buffer */
> +  LLVMValueRef imms_array;
> +  LLVMValueRef pixel_offsets;
> +  LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
> +  LLVMTypeRef float4_ptr_type;
> +  int i;
> +
> +  /* build pixel offset vector: {0, 1, 2, 3, ...} */
> +  for (i = 0; i < float_bld->type.length; i++) {
> + offsets[i] = lp_build_const_int32(gallivm, i);
> +  }
> +  pixel_offsets = LLVMConstVector(offsets, float_bld->type.length);
> +
> +  /* index_vec = (indirect_index * 4 + swizzle) * length */
> +  index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
> +  index_vec = lp_build_add(uint_bld, index_vec, swizzle_vec);
> +  index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
> +  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
> +
> +  /* cast imms_array pointer to float* */
> +  float4_ptr_type = LLVMPointerType(
> + LLVMFloatTypeInContext(bld->bld_base.base.gallivm->context), 0);
> +  imms_array = LLVMBuildBitCast(builder, bld->imms_array,
> +float4_ptr_type, "");
> +
> +  /* Gather values from the temporary register array */
> +  res = build_gather(&bld_base->base, imms_array, index_vec);
> +   }
> +   else {
> +  res = bld->immediates[reg->Register.Index][swizzle];
> +   }
>  
> if (stype == TGSI_TYPE_UNSIGNED) {
>res = LLVMConstBitCast(res, bld_base->uint_bld.vec_type);
> @@ -,6 +2272,21 @@ void lp_emit_immediate_soa(
> for( i = size; i < 4; ++i )
>bld->immediates[bld->num_immediates][i] = bld_base->base.undef;
>  
> +   if (bld->indirect_files & (1 << TGSI_FILE_IMMEDIATE)) {
> +  unsigned index = bld->num_immediates;
> +  struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> +  LLVMBuilderRef builder = gallivm->builder;
> +  for (i = 0; i < 4; ++i ) {
> + LLVMValueRef lindex = lp_build_const_int32(
> +bld->bld_base.base.gallivm, index * 4 + i);
> + LLVMValueRef imm_ptr = LLVMBuildGEP(builder,
> + bld->imms_array, &lindex, 1,
> "");
> + L

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_npot on GLES1

[Chad Versace]

On 05/08/2013 10:05 AM, Kenneth Graunke wrote:

On 05/08/2013 09:48 AM, Chad Versace wrote:

Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.

 From the GL_OES_texture_npot spec:
 OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
 written against OpenGL ES 1.1.12 and OpenGL ES 2.0.25.

Signed-off-by: Chad Versace 
---
  src/mesa/main/extensions.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8b67fca..8eb45ff 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -279,7 +279,7 @@ static const struct extension extension_table[] = {
 { "GL_OES_texture_cube_map",o(ARB_texture_cube_map),   
  ES1,   2007 },
 { "GL_OES_texture_env_crossbar",
o(ARB_texture_env_crossbar), ES1,   2005 },
 { "GL_OES_texture_mirrored_repeat", o(dummy_true), 
  ES1,   2005 },
-   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two),   ES2, 2005 },
+   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two), ES1,  ES2, 2005 },
 { "GL_OES_vertex_array_object", o(dummy_true), 
  ES1 | ES2, 2010 },

 /* Vendor extensions */


This even compiles?

With the change to ES1 | ES2, this would be:
Reviewed-by: Kenneth Graunke 


Yes, surprisingly it compiles.

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

Re: [Mesa-dev] [PATCH] intel: Fix render-to-texture in non-FinishRenderTexture cases.

[Kenneth Graunke]

On 05/07/2013 04:46 PM, Ian Romanick wrote:

On 05/07/2013 03:53 PM, Eric Anholt wrote:

With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to

^
image


renderbuffers that are also textures, so the core Mesa
FinishRenderTexture
hook doesn't get called.  That hook also wasn't called in various cases
within the driver where we'd update texture contents using the render
cache (like glCopyTexSubImage) that resulted in
intel_batchbuffer_emit_mi_flush().

To fix it, track a set of rendered-to BOs in our context, which is
cleared at batch wrap or emit_mi_flush time, and do an emit_mi_flush if
one of our textures is in that set.


That sounds like an optimal (if complex) solution for the EGLimage. When
Ken described the bug to me, I was envisioning a simpler fix:  if a
renderbuffer is attached to an EGLimage, use FinishRenderTexture.  Out
of curiosity, do you think that would have also worked?  It seems like
that would be cheaper in the non-EGLimage case, though it doesn't sound
like it matters.


Another problem is that FinishRenderTexture() on most drivers assumes 
that the attachment parameter contains a texture object...which, given 
the name, seems fairly reasonable.  i965 doesn't since it unilaterally 
flushes the texture cache, so it would work out, but we'd have to be 
careful to avoid breaking everyone else.

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

Re: [Mesa-dev] [PATCH] intel: Fix render-to-texture in non-FinishRenderTexture cases.

[Ian Romanick]

On 05/08/2013 09:59 AM, Eric Anholt wrote:

Ian Romanick  writes:


On 05/07/2013 03:53 PM, Eric Anholt wrote:

With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to

 ^
image


renderbuffers that are also textures, so the core Mesa FinishRenderTexture
hook doesn't get called.  That hook also wasn't called in various cases
within the driver where we'd update texture contents using the render
cache (like glCopyTexSubImage) that resulted in
intel_batchbuffer_emit_mi_flush().

To fix it, track a set of rendered-to BOs in our context, which is
cleared at batch wrap or emit_mi_flush time, and do an emit_mi_flush if
one of our textures is in that set.


That sounds like an optimal (if complex) solution for the EGLimage.
When Ken described the bug to me, I was envisioning a simpler fix:  if a
renderbuffer is attached to an EGLimage, use FinishRenderTexture.  Out
of curiosity, do you think that would have also worked?  It seems like
that would be cheaper in the non-EGLimage case, though it doesn't sound
like it matters.


When would you do that?  After every draw call?  There's no signal that
"now's the time it's going to be used as a texture".


Right now FinishRenderTexture is potentially called when the FBO is 
unbound.  I think that should be sufficient.  There are already no 
guarantees (excluding GL_NV_texture_barrier) about synchronization 
during potential feed-back loops, and this shouldn't make that any worse.


I don't see anything in any of the relevant EGL extensions, but issue #2 
in GL_OES_EGL_image suggests that it may be okay.


Anyway... Your patch should be fine.  I was just wondering if you had 
considered other strategies.


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

Re: [Mesa-dev] i965: Haswell has been broken for over 5 days

[Chad Versace]

On 05/08/2013 09:57 AM, Eric Anholt wrote:

Dave Airlie  writes:




Haswell has been broken on master for a surprisingly long time, since
commit
1dfea559c3 (Thu May 2 11:27:37 2013 -0700). Reverting that commit fixed
it
for me.

If it doesn't get properly fixed by the 7th day, I'd like to see the
guilty
patch reverted. A full week is too long for a platform under active
development
to be down.



Well, it was broken for 2 working days before I caught the bug myself
and posted a patch, which got (negative) review feedback at midnight.
QA caught the bug shortly after I posted the patch.  I think you have
unreasonable expectations of turnaround time here for something that
wasn't even bisected and reported.



I admit I may have an unreasonable expectation here sourced in frustration.
The frustration, though, isn't a good excuse to be unreasonable.


Also HSW isn't hw the rest of the world has to worry about, whereas
SNB being broken for 3D at startup on every distro matters more. It
might not matter in your reporting and bonus structure but it sure as
hell matters to users :-)


Which is why I would have refused to revert it anyway.  Released
hardware trumps prerelease hardware.


Strong point. When framed with that statement, my original message looks 
extremely
foolish, doesn't it?

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

Re: [Mesa-dev] [PATCH] i965: verify depth render buffer depth when in fast clear WIP

[Eric Anholt]

Tapani Pälli  writes:

> Patch makes sure in conservative way that the depth_clear_value
> is correct and represents max depth of current depth buffer.
>
> This fixes the case where user has 16bit color buffer but 24bit
> depth buffer and 'fb->_DepthMax' has a wrong value. I'm currently
> investigating how to get _DepthMax corrected on mesa side, but
> meanwhile this patch will enable correct rendering results for
> 16bit benchmarks instead of displaying only white color on the
> screen. This bug does not happen with user created framebuffers,
> only with window system ones.

_DepthMax should actually get fixed, instead.  _DepthMax should have
nothing to do with color bits per pixel.


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

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_npot on GLES1

[Kenneth Graunke]

On 05/08/2013 09:48 AM, Chad Versace wrote:

Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.

 From the GL_OES_texture_npot spec:
 OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
 written against OpenGL ES 1.1.12 and OpenGL ES 2.0.25.

Signed-off-by: Chad Versace 
---
  src/mesa/main/extensions.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8b67fca..8eb45ff 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -279,7 +279,7 @@ static const struct extension extension_table[] = {
 { "GL_OES_texture_cube_map",o(ARB_texture_cube_map),   
  ES1,   2007 },
 { "GL_OES_texture_env_crossbar",
o(ARB_texture_env_crossbar), ES1,   2005 },
 { "GL_OES_texture_mirrored_repeat", o(dummy_true), 
  ES1,   2005 },
-   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two),   ES2, 2005 },
+   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two), ES1,  ES2, 2005 },
 { "GL_OES_vertex_array_object", o(dummy_true), 
  ES1 | ES2, 2010 },

 /* Vendor extensions */


This even compiles?

With the change to ES1 | ES2, this would be:
Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Fix render-to-texture in non-FinishRenderTexture cases.

[Eric Anholt]

Ian Romanick  writes:

> On 05/07/2013 03:53 PM, Eric Anholt wrote:
>> With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
> ^
> image
>
>> renderbuffers that are also textures, so the core Mesa FinishRenderTexture
>> hook doesn't get called.  That hook also wasn't called in various cases
>> within the driver where we'd update texture contents using the render
>> cache (like glCopyTexSubImage) that resulted in
>> intel_batchbuffer_emit_mi_flush().
>>
>> To fix it, track a set of rendered-to BOs in our context, which is
>> cleared at batch wrap or emit_mi_flush time, and do an emit_mi_flush if
>> one of our textures is in that set.
>
> That sounds like an optimal (if complex) solution for the EGLimage. 
> When Ken described the bug to me, I was envisioning a simpler fix:  if a 
> renderbuffer is attached to an EGLimage, use FinishRenderTexture.  Out 
> of curiosity, do you think that would have also worked?  It seems like 
> that would be cheaper in the non-EGLimage case, though it doesn't sound 
> like it matters.

When would you do that?  After every draw call?  There's no signal that
"now's the time it's going to be used as a texture".


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

Re: [Mesa-dev] i965: Haswell has been broken for over 5 days

[Eric Anholt]

Dave Airlie  writes:

>>>
 Haswell has been broken on master for a surprisingly long time, since
 commit
 1dfea559c3 (Thu May 2 11:27:37 2013 -0700). Reverting that commit fixed
 it
 for me.

 If it doesn't get properly fixed by the 7th day, I'd like to see the
 guilty
 patch reverted. A full week is too long for a platform under active
 development
 to be down.
>>>
>>>
>>> Well, it was broken for 2 working days before I caught the bug myself
>>> and posted a patch, which got (negative) review feedback at midnight.
>>> QA caught the bug shortly after I posted the patch.  I think you have
>>> unreasonable expectations of turnaround time here for something that
>>> wasn't even bisected and reported.
>>
>>
>> I admit I may have an unreasonable expectation here sourced in frustration.
>> The frustration, though, isn't a good excuse to be unreasonable.
>
> Also HSW isn't hw the rest of the world has to worry about, whereas
> SNB being broken for 3D at startup on every distro matters more. It
> might not matter in your reporting and bonus structure but it sure as
> hell matters to users :-)

Which is why I would have refused to revert it anyway.  Released
hardware trumps prerelease hardware.


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

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_npot on GLES1

[Ian Romanick]

On 05/08/2013 09:48 AM, Chad Versace wrote:

Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.

 From the GL_OES_texture_npot spec:
 OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
 written against OpenGL ES 1.1.12 and OpenGL ES 2.0.25.

Signed-off-by: Chad Versace 
---
  src/mesa/main/extensions.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8b67fca..8eb45ff 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -279,7 +279,7 @@ static const struct extension extension_table[] = {
 { "GL_OES_texture_cube_map",o(ARB_texture_cube_map),   
  ES1,   2007 },
 { "GL_OES_texture_env_crossbar",
o(ARB_texture_env_crossbar), ES1,   2005 },
 { "GL_OES_texture_mirrored_repeat", o(dummy_true), 
  ES1,   2005 },
-   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two),   ES2, 2005 },
+   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two), ES1,  ES2, 2005 },


I think you want 'ES1 | ES2' instead of 'ES1 , ES2'.


 { "GL_OES_vertex_array_object", o(dummy_true), 
  ES1 | ES2, 2010 },

 /* Vendor extensions */



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

[Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_npot on GLES1

[Chad Versace]

Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.

>From the GL_OES_texture_npot spec:
OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
written against OpenGL ES 1.1.12 and OpenGL ES 2.0.25.

Signed-off-by: Chad Versace 
---
 src/mesa/main/extensions.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8b67fca..8eb45ff 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -279,7 +279,7 @@ static const struct extension extension_table[] = {
{ "GL_OES_texture_cube_map",o(ARB_texture_cube_map),
 ES1,   2007 },
{ "GL_OES_texture_env_crossbar",
o(ARB_texture_env_crossbar), ES1,   2005 },
{ "GL_OES_texture_mirrored_repeat", o(dummy_true),  
 ES1,   2005 },
-   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two),   ES2, 2005 },
+   { "GL_OES_texture_npot",
o(ARB_texture_non_power_of_two), ES1,  ES2, 2005 },
{ "GL_OES_vertex_array_object", o(dummy_true),  
 ES1 | ES2, 2010 },
 
/* Vendor extensions */
-- 
1.8.1.4

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

[Mesa-dev] [PATCH] R600/SI: Add lit test coverage for the remaining patterns added recently

[Michel Dänzer]

From: Michel Dänzer 

Signed-off-by: Michel Dänzer 
---
 test/CodeGen/R600/llvm.AMDGPU.imax.ll  | 21 +
 test/CodeGen/R600/llvm.AMDGPU.imin.ll  | 21 +
 test/CodeGen/R600/llvm.AMDGPU.trunc.ll | 22 +++---
 test/CodeGen/R600/llvm.AMDGPU.umax.ll  | 21 +
 test/CodeGen/R600/llvm.AMDGPU.umin.ll  | 21 +
 test/CodeGen/R600/uitofp.ll| 16 
 6 files changed, 111 insertions(+), 11 deletions(-)
 create mode 100644 test/CodeGen/R600/llvm.AMDGPU.imax.ll
 create mode 100644 test/CodeGen/R600/llvm.AMDGPU.imin.ll
 create mode 100644 test/CodeGen/R600/llvm.AMDGPU.umax.ll
 create mode 100644 test/CodeGen/R600/llvm.AMDGPU.umin.ll
 create mode 100644 test/CodeGen/R600/uitofp.ll

diff --git a/test/CodeGen/R600/llvm.AMDGPU.imax.ll 
b/test/CodeGen/R600/llvm.AMDGPU.imax.ll
new file mode 100644
index 000..3e854c8
--- /dev/null
+++ b/test/CodeGen/R600/llvm.AMDGPU.imax.ll
@@ -0,0 +1,21 @@
+;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck %s
+
+;CHECK: V_MAX_I32_e32
+
+define void @main(i32 %p0, i32 %p1) #0 {
+main_body:
+  %0 = call i32 @llvm.AMDGPU.imax(i32 %p0, i32 %p1)
+  %1 = bitcast i32 %0 to float
+  call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 0, float %1, 
float %1, float %1, float %1)
+  ret void
+}
+
+; Function Attrs: readnone
+declare i32 @llvm.AMDGPU.imax(i32, i32) #1
+
+declare void @llvm.SI.export(i32, i32, i32, i32, i32, float, float, float, 
float)
+
+attributes #0 = { "ShaderType"="0" }
+attributes #1 = { readnone }
+
+!0 = metadata !{metadata !"const", null, i32 1}
diff --git a/test/CodeGen/R600/llvm.AMDGPU.imin.ll 
b/test/CodeGen/R600/llvm.AMDGPU.imin.ll
new file mode 100644
index 000..e227bf8
--- /dev/null
+++ b/test/CodeGen/R600/llvm.AMDGPU.imin.ll
@@ -0,0 +1,21 @@
+;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck %s
+
+;CHECK: V_MIN_I32_e32
+
+define void @main(i32 %p0, i32 %p1) #0 {
+main_body:
+  %0 = call i32 @llvm.AMDGPU.imin(i32 %p0, i32 %p1)
+  %1 = bitcast i32 %0 to float
+  call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 0, float %1, 
float %1, float %1, float %1)
+  ret void
+}
+
+; Function Attrs: readnone
+declare i32 @llvm.AMDGPU.imin(i32, i32) #1
+
+declare void @llvm.SI.export(i32, i32, i32, i32, i32, float, float, float, 
float)
+
+attributes #0 = { "ShaderType"="0" }
+attributes #1 = { readnone }
+
+!0 = metadata !{metadata !"const", null, i32 1}
diff --git a/test/CodeGen/R600/llvm.AMDGPU.trunc.ll 
b/test/CodeGen/R600/llvm.AMDGPU.trunc.ll
index ff22a69..cdc03f8 100644
--- a/test/CodeGen/R600/llvm.AMDGPU.trunc.ll
+++ b/test/CodeGen/R600/llvm.AMDGPU.trunc.ll
@@ -1,16 +1,16 @@
-;RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck %s
+; RUN: llc < %s -march=r600 -mcpu=redwood | FileCheck 
--check-prefix=R600-CHECK %s
+; RUN: llc < %s -march=r600 -mcpu=verde | FileCheck --check-prefix=SI-CHECK %s
 
-;CHECK: TRUNC * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+; R600-CHECK: @amdgpu_trunc
+; R600-CHECK: TRUNC * T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+; SI-CHECK: @amdgpu_trunc
+; SI-CHECK: V_TRUNC_F32
 
-define void @test() {
-   %r0 = call float @llvm.R600.load.input(i32 0)
-   %r1 = call float @llvm.AMDGPU.trunc( float %r0)
-   call void @llvm.AMDGPU.store.output(float %r1, i32 0)
-   ret void
+define void @amdgpu_trunc(float addrspace(1)* %out, float %x) {
+entry:
+  %0 = call float @llvm.AMDGPU.trunc(float %x)
+  store float %0, float addrspace(1)* %out
+  ret void
 }
 
-declare float @llvm.R600.load.input(i32) readnone
-
-declare void @llvm.AMDGPU.store.output(float, i32)
-
 declare float @llvm.AMDGPU.trunc(float ) readnone
diff --git a/test/CodeGen/R600/llvm.AMDGPU.umax.ll 
b/test/CodeGen/R600/llvm.AMDGPU.umax.ll
new file mode 100644
index 000..7699c04
--- /dev/null
+++ b/test/CodeGen/R600/llvm.AMDGPU.umax.ll
@@ -0,0 +1,21 @@
+;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck %s
+
+;CHECK: V_MAX_U32_e32
+
+define void @main(i32 %p0, i32 %p1) #0 {
+main_body:
+  %0 = call i32 @llvm.AMDGPU.umax(i32 %p0, i32 %p1)
+  %1 = bitcast i32 %0 to float
+  call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 0, float %1, 
float %1, float %1, float %1)
+  ret void
+}
+
+; Function Attrs: readnone
+declare i32 @llvm.AMDGPU.umax(i32, i32) #1
+
+declare void @llvm.SI.export(i32, i32, i32, i32, i32, float, float, float, 
float)
+
+attributes #0 = { "ShaderType"="0" }
+attributes #1 = { readnone }
+
+!0 = metadata !{metadata !"const", null, i32 1}
diff --git a/test/CodeGen/R600/llvm.AMDGPU.umin.ll 
b/test/CodeGen/R600/llvm.AMDGPU.umin.ll
new file mode 100644
index 000..a911ad9
--- /dev/null
+++ b/test/CodeGen/R600/llvm.AMDGPU.umin.ll
@@ -0,0 +1,21 @@
+;RUN: llc < %s -march=r600 -mcpu=verde | FileCheck %s
+
+;CHECK: V_MIN_U32_e32
+
+define void @main(i32 %p0, i32 %p1) #0 {
+main_body:
+  %0 = call i32 @llvm.AMDGPU.umin(i32 %p0, i32 %p1)
+  %1 = bitcast i32 %0 to float
+  call void @llvm.SI.export(i32 15, i32 1, i32 1, i32 0, i32 0, float %1, 
float %1, fl

Re: [Mesa-dev] [PATCH] st/mesa: generate GL_OUT_OF_MEMORY if we can't create the index buffer

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, May 8, 2013 at 6:20 PM, Brian Paul  wrote:
> Before, if we failed to allocate the index buffer we'd silently
> return from st_draw_vbo() without drawing anything.  We should
> raise GL_OUT_OF_MEMORY to give some indication that something went
> wrong.
> ---
>  src/mesa/state_tracker/st_draw.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw.c 
> b/src/mesa/state_tracker/st_draw.c
> index 437d554..a0cf2ca 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -230,7 +230,7 @@ st_draw_vbo(struct gl_context *ctx,
> nr_prims);
>
>if (!setup_index_buffer(st, ib, &ibuffer)) {
> - /* out of memory */
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, 
> "glBegin/DrawElements/DrawArray");
>   return;
>}
>
> --
> 1.7.3.4
>
> ___
> 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] st/mesa: generate GL_OUT_OF_MEMORY if we can't create the index buffer

[Brian Paul]

Before, if we failed to allocate the index buffer we'd silently
return from st_draw_vbo() without drawing anything.  We should
raise GL_OUT_OF_MEMORY to give some indication that something went
wrong.
---
 src/mesa/state_tracker/st_draw.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 437d554..a0cf2ca 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -230,7 +230,7 @@ st_draw_vbo(struct gl_context *ctx,
nr_prims);
 
   if (!setup_index_buffer(st, ib, &ibuffer)) {
- /* out of memory */
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glBegin/DrawElements/DrawArray");
  return;
   }
 
-- 
1.7.3.4

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

[Mesa-dev] TGSI conventions (Was: gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition)

[Jose Fonseca]

I don't really care much about modifiers vs no-modifiers, or ABS/SUB opcodes vs 
no opcodes.  It is merely a convention, and as long as we consistently follow 
it we're good IMO.

I am, however, worried about this growing trend of long threads about TGSI with 
little more than nitpicking.  I think that this indecision and back'n'forth is 
an evil in itself, more than making any decision could be: all sides have to 
spend substantial time putting their argument forth, at the end of the day some 
decision will have to be made, compromises unavoidable, and by then somebody is 
bound to be unhappy and frustrated (more unhappy and frustrated the bigger the 
investment in the discussion).

This is not a critique aimed to anybody in particular, but to us all as a 
community.  And I think that the fact that we are all smart and passionate 
about this stuff actually goes against us.

So I think we should have some stronger rules of thumb of where we want TGSI to 
go, so that we can all make progress without less overhead from everybody.

I also believe that there is benefit in gallium mimicking more closely the 
standards out there, instead of trying to find our own solution for every 
little gallium design decision.  Khronos has not specified an GLSL bytecode 
till date, and in my knowledge ARB/NV_fragment_programs is too old to be a good 
model.  So for tokenized shader, D3D10/11 bytecode is the best model we have 
out there.  Furthermore, Gallium drew a lot of inspiration from D3D10 API, so 
it is only natural we do the same for tokenized shaders.

Therefore, I think we should just aim to have TGSI match D3D10/11 tokenized 
shaders more closely, at very least on matters of mere convention, so that we 
can all go spend more time on more interesting problems.

Jose


- Original Message -
> Am 08.05.2013 12:47, schrieb Marek Olšák:
> > Modifiers are actually very useful with MOV. However I don't think the
> > modifiers really care what the type is. They just change the sign bit
> > of float (which is a bitwise operation). Also, UCMP doesn't do
> > anything with the 2nd and 3rd argument, so their types don't matter.
> Well, they do matter for the input modifiers.
> They might just change the most significant bit on your hardware but
> that's not how they are defined in tgsi.
> I don't really care that much if the 2nd and 3rd argument to ucmp are
> ints or floats (it's true for d3d10 movc translation floats are the
> natural choice but we can easily translate that to several ops instead,
> e.g. mov's with modifiers followed by ucmp). I do care however that all
> drivers treat them the same, not like now where softpipe will do two's
> complement negation on src input modifiers whereas llvmpipe will flip
> the sign bit.
> 
> > 
> > I think the ABS and SUB opcodes should be removed in favor of the
> > modifiers.
> Those are in very widespread use and at least for SUB it definitely
> avoids additional effort for drivers which can't do input modifiers
> natively.
> 
> Roland
> 
> 
> > 
> > Marek
> > 
> > On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
> >  wrote:
> >> On 08.05.2013 03:48, srol...@vmware.com wrote:
> >>> From: Roland Scheidegger 
> >>>
> >>> UCMP while an integer opcode isn't really consistently implemented as
> >>> having all integer arguments. softpipe will assume all arguments are
> >>> ints, whereas gallivm has the arguments defined as untyped which
> >>> means they'll get treated as floats. This means input modifiers will
> >>> not work the same. Fix this by saying only first arg is an integer,
> >>> which seems more useful than making all arguments integers - this would
> >>> be similar to d3d10 movc opcode.
> >>> ---
> >>>  src/gallium/docs/source/tgsi.rst |5 +
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/src/gallium/docs/source/tgsi.rst
> >>> b/src/gallium/docs/source/tgsi.rst
> >>> index 3af1fb7..852f8a0 100644
> >>> --- a/src/gallium/docs/source/tgsi.rst
> >>> +++ b/src/gallium/docs/source/tgsi.rst
> >>> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by
> >>> PIPE_SHADER_CAP_INTEGERS (all of them?)
> >>>
> >>>  .. opcode:: UCMP - Integer Conditional Move
> >>>
> >>> +.. note::
> >>> +
> >>> +   Only the first source arg is an integer, the 2nd and 3rd ones are
> >>> +   considered floats (for input modifier purposes).
> >>> +
> >>
> >> As long as you patch up all the occurrences of
> >> tgsi_opcode_infer_src_type and make it take an argument to identify the
> >> source ...
> >>
> >> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
> >> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated
> >> on.
> >> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
> >> optimizer can take care of merging modifiers into the instruction
> >> (nvc0's UCMP (slct u32) doesn't support modifiers)
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Jose Fonseca]

- Original Message -
> The SUB opcode is not emitted by GLSL, however this may change in the
> future. I don't think using specialized opcodes instead of the
> modifiers will make anyone's life easier (the modifiers must be
> implemented anyway).
> 
> If you really want people to follow the TGSI documentation, there
> should be a utility function which validates TGSI and st/mesa should
> reject shaders which are invalid. Right now, GLSL-to-TGSI generates
> UCMP with the first operand negated.

I don't see why TGSI documentation is diminished without such tests.

I actually think such validation tests have limited use: it only tests the 
syntax of shaders -- not how drivers implement them --; and we actually need 
input that exercises those error conditions in runtime. Furthermore, it's more 
stuff to maintain -- just take a look at how graw/galhadad quickly rots.

No, I strongly believe that good gallium documentation is a much better legacy 
than more gallium specific tests.  For the rest we have piglit.

Jose

> 
> Marek
> 
> 
> 
> On Wed, May 8, 2013 at 3:51 PM, Roland Scheidegger 
> wrote:
> > Am 08.05.2013 12:47, schrieb Marek Olšák:
> >> Modifiers are actually very useful with MOV. However I don't think the
> >> modifiers really care what the type is. They just change the sign bit
> >> of float (which is a bitwise operation). Also, UCMP doesn't do
> >> anything with the 2nd and 3rd argument, so their types don't matter.
> > Well, they do matter for the input modifiers.
> > They might just change the most significant bit on your hardware but
> > that's not how they are defined in tgsi.
> > I don't really care that much if the 2nd and 3rd argument to ucmp are
> > ints or floats (it's true for d3d10 movc translation floats are the
> > natural choice but we can easily translate that to several ops instead,
> > e.g. mov's with modifiers followed by ucmp). I do care however that all
> > drivers treat them the same, not like now where softpipe will do two's
> > complement negation on src input modifiers whereas llvmpipe will flip
> > the sign bit.
> >
> >>
> >> I think the ABS and SUB opcodes should be removed in favor of the
> >> modifiers.
> > Those are in very widespread use and at least for SUB it definitely
> > avoids additional effort for drivers which can't do input modifiers
> > natively.
> >
> > Roland
> >
> >
> >>
> >> Marek
> >>
> >> On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
> >>  wrote:
> >>> On 08.05.2013 03:48, srol...@vmware.com wrote:
>  From: Roland Scheidegger 
> 
>  UCMP while an integer opcode isn't really consistently implemented as
>  having all integer arguments. softpipe will assume all arguments are
>  ints, whereas gallivm has the arguments defined as untyped which
>  means they'll get treated as floats. This means input modifiers will
>  not work the same. Fix this by saying only first arg is an integer,
>  which seems more useful than making all arguments integers - this would
>  be similar to d3d10 movc opcode.
>  ---
>   src/gallium/docs/source/tgsi.rst |5 +
>   1 file changed, 5 insertions(+)
> 
>  diff --git a/src/gallium/docs/source/tgsi.rst
>  b/src/gallium/docs/source/tgsi.rst
>  index 3af1fb7..852f8a0 100644
>  --- a/src/gallium/docs/source/tgsi.rst
>  +++ b/src/gallium/docs/source/tgsi.rst
>  @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by
>  PIPE_SHADER_CAP_INTEGERS (all of them?)
> 
>   .. opcode:: UCMP - Integer Conditional Move
> 
>  +.. note::
>  +
>  +   Only the first source arg is an integer, the 2nd and 3rd ones are
>  +   considered floats (for input modifier purposes).
>  +
> >>>
> >>> As long as you patch up all the occurrences of
> >>> tgsi_opcode_infer_src_type and make it take an argument to identify the
> >>> source ...
> >>>
> >>> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
> >>> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated
> >>> on.
> >>> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
> >>> optimizer can take care of merging modifiers into the instruction
> >>> (nvc0's UCMP (slct u32) doesn't support modifiers)
> ___
> 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 2/2] gallivm/soa: implement indirect addressing in immediates

[Roland Scheidegger]

Am 08.05.2013 05:16, schrieb Zack Rusin:
> The support is analogous to the way we handle indirect addressing
> in temporaries, except that we don't have to worry about storing
> (after declarations) and thus we'll able to keep using the old
> code when indirect addressing isn't used. In other words we're
> still using constants directly, unless the instrunction has
"instrunction"

> immediate register with indirect addressing.
> 
> Signed-off-by: Zack Rusin 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 ++
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |   78 
> ++-
>  2 files changed, 82 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h 
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> index 9d9c742..fd566b1 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> @@ -453,6 +453,12 @@ struct lp_build_tgsi_soa_context
>  */
> LLVMValueRef inputs_array;
>  
> +   /* We allocate/use this array of temps if (1 << TGSI_FILE_IMMEDIATE) is
> +* set in the indirect_files field.
> +*/
> +   LLVMValueRef imms_array;
> +
> +
> struct lp_bld_tgsi_system_values system_values;
>  
> /** bitmask indicating which register files are accessed indirectly */
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 733f0ed..066f64a 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -972,8 +972,58 @@ emit_fetch_immediate(
> unsigned swizzle)
>  {
> struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
> -   LLVMValueRef res = bld->immediates[reg->Register.Index][swizzle];
> -   assert(res);
> +   struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> +   LLVMBuilderRef builder = gallivm->builder;
> +   struct lp_build_context *uint_bld = &bld_base->uint_bld;
> +   struct lp_build_context *float_bld = &bld_base->base;
> +   LLVMValueRef res = NULL;
> +   LLVMValueRef indirect_index = NULL;
> +
> +   if (reg->Register.Indirect) {
> +  indirect_index = get_indirect_index(bld,
> +  reg->Register.File,
> +  reg->Register.Index,
> +  ®->Indirect);
> +   }
> +
> +   if (reg->Register.Indirect) {
> +  LLVMValueRef swizzle_vec =
> + lp_build_const_int_vec(bld->bld_base.base.gallivm,
> +uint_bld->type, swizzle);
> +  LLVMValueRef length_vec =
> + lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
> +bld->bld_base.base.type.length);
> +  LLVMValueRef index_vec;  /* index into the const buffer */
> +  LLVMValueRef imms_array;
> +  LLVMValueRef pixel_offsets;
> +  LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
> +  LLVMTypeRef float4_ptr_type;
> +  int i;
> +
> +  /* build pixel offset vector: {0, 1, 2, 3, ...} */
> +  for (i = 0; i < float_bld->type.length; i++) {
> + offsets[i] = lp_build_const_int32(gallivm, i);
> +  }
> +  pixel_offsets = LLVMConstVector(offsets, float_bld->type.length);
> +
> +  /* index_vec = (indirect_index * 4 + swizzle) * length */
> +  index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
> +  index_vec = lp_build_add(uint_bld, index_vec, swizzle_vec);
> +  index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
> +  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
> +
> +  /* cast imms_array pointer to float* */
> +  float4_ptr_type = LLVMPointerType(
> + LLVMFloatTypeInContext(bld->bld_base.base.gallivm->context), 0);
> +  imms_array = LLVMBuildBitCast(builder, bld->imms_array,
> +float4_ptr_type, "");
> +
> +  /* Gather values from the temporary register array */
> +  res = build_gather(&bld_base->base, imms_array, index_vec);
> +   }
> +   else {
> +  res = bld->immediates[reg->Register.Index][swizzle];
> +   }
>  
> if (stype == TGSI_TYPE_UNSIGNED) {
>res = LLVMConstBitCast(res, bld_base->uint_bld.vec_type);
> @@ -,6 +2272,21 @@ void lp_emit_immediate_soa(
> for( i = size; i < 4; ++i )
>bld->immediates[bld->num_immediates][i] = bld_base->base.undef;
>  
> +   if (bld->indirect_files & (1 << TGSI_FILE_IMMEDIATE)) {
> +  unsigned index = bld->num_immediates;
> +  struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> +  LLVMBuilderRef builder = gallivm->builder;
> +  for (i = 0; i < 4; ++i ) {
> + LLVMValueRef lindex = lp_build_const_int32(
> +bld->bld_base.base.gallivm, index * 4 + i);
> + LLVMValueRef imm_ptr = LLVMBuildGEP(builder,
> + bld->imms_array, &lindex, 1, 
> "");
> + LL

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Marek Olšák]

The SUB opcode is not emitted by GLSL, however this may change in the
future. I don't think using specialized opcodes instead of the
modifiers will make anyone's life easier (the modifiers must be
implemented anyway).

If you really want people to follow the TGSI documentation, there
should be a utility function which validates TGSI and st/mesa should
reject shaders which are invalid. Right now, GLSL-to-TGSI generates
UCMP with the first operand negated.

Marek



On Wed, May 8, 2013 at 3:51 PM, Roland Scheidegger  wrote:
> Am 08.05.2013 12:47, schrieb Marek Olšák:
>> Modifiers are actually very useful with MOV. However I don't think the
>> modifiers really care what the type is. They just change the sign bit
>> of float (which is a bitwise operation). Also, UCMP doesn't do
>> anything with the 2nd and 3rd argument, so their types don't matter.
> Well, they do matter for the input modifiers.
> They might just change the most significant bit on your hardware but
> that's not how they are defined in tgsi.
> I don't really care that much if the 2nd and 3rd argument to ucmp are
> ints or floats (it's true for d3d10 movc translation floats are the
> natural choice but we can easily translate that to several ops instead,
> e.g. mov's with modifiers followed by ucmp). I do care however that all
> drivers treat them the same, not like now where softpipe will do two's
> complement negation on src input modifiers whereas llvmpipe will flip
> the sign bit.
>
>>
>> I think the ABS and SUB opcodes should be removed in favor of the modifiers.
> Those are in very widespread use and at least for SUB it definitely
> avoids additional effort for drivers which can't do input modifiers
> natively.
>
> Roland
>
>
>>
>> Marek
>>
>> On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
>>  wrote:
>>> On 08.05.2013 03:48, srol...@vmware.com wrote:
 From: Roland Scheidegger 

 UCMP while an integer opcode isn't really consistently implemented as
 having all integer arguments. softpipe will assume all arguments are
 ints, whereas gallivm has the arguments defined as untyped which
 means they'll get treated as floats. This means input modifiers will
 not work the same. Fix this by saying only first arg is an integer,
 which seems more useful than making all arguments integers - this would
 be similar to d3d10 movc opcode.
 ---
  src/gallium/docs/source/tgsi.rst |5 +
  1 file changed, 5 insertions(+)

 diff --git a/src/gallium/docs/source/tgsi.rst 
 b/src/gallium/docs/source/tgsi.rst
 index 3af1fb7..852f8a0 100644
 --- a/src/gallium/docs/source/tgsi.rst
 +++ b/src/gallium/docs/source/tgsi.rst
 @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by 
 PIPE_SHADER_CAP_INTEGERS (all of them?)

  .. opcode:: UCMP - Integer Conditional Move

 +.. note::
 +
 +   Only the first source arg is an integer, the 2nd and 3rd ones are
 +   considered floats (for input modifier purposes).
 +
>>>
>>> As long as you patch up all the occurrences of
>>> tgsi_opcode_infer_src_type and make it take an argument to identify the
>>> source ...
>>>
>>> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
>>> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated on.
>>> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
>>> optimizer can take care of merging modifiers into the instruction
>>> (nvc0's UCMP (slct u32) doesn't support modifiers)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vl/vdpau: fix PresentationQueueQuerySurfaceStatus

[Christian König]

From: Christian König 

The last queued surface always keeps displaying.

Fixing a problem with XBMC.

Signed-off-by: Christian König 
---
 src/gallium/state_trackers/vdpau/presentation.c  |8 ---
 src/gallium/state_trackers/vdpau/vdpau_private.h |   28 +++---
 2 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index a5466cd..c9f8ea7 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -238,8 +238,6 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
surf_templ.format = tex->format;
surf_draw = pipe->create_surface(pipe, tex, &surf_templ);
 
-   surf->timestamp = (vlVdpTime)earliest_presentation_time;
-
dst_clip.x0 = 0;
dst_clip.y0 = 0;
dst_clip.x1 = clip_width ? clip_width : surf_draw->width;
@@ -276,6 +274,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
 
pipe->screen->fence_reference(pipe->screen, &surf->fence, NULL);
pipe->flush(pipe, &surf->fence, 0);
+   pq->last_surf = surf;
 
if (dump_window == -1) {
   dump_window = debug_get_num_option("VDPAU_DUMP", 0);
@@ -360,7 +359,10 @@ 
vlVdpPresentationQueueQuerySurfaceStatus(VdpPresentationQueue presentation_queue
*first_presentation_time = 0;
 
if (!surf->fence) {
-  *status = VDP_PRESENTATION_QUEUE_STATUS_IDLE;
+  if (pq->last_surf == surf)
+ *status = VDP_PRESENTATION_QUEUE_STATUS_VISIBLE;
+  else
+ *status = VDP_PRESENTATION_QUEUE_STATUS_IDLE;
} else {
   pipe_mutex_lock(pq->device->mutex);
   screen = pq->device->vscreen->pscreen;
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h 
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 918a6c2..716d218 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -323,19 +323,6 @@ typedef struct
 typedef struct
 {
vlVdpDevice *device;
-   Drawable drawable;
-} vlVdpPresentationQueueTarget;
-
-typedef struct
-{
-   vlVdpDevice *device;
-   Drawable drawable;
-   struct vl_compositor_state cstate;
-} vlVdpPresentationQueue;
-
-typedef struct
-{
-   vlVdpDevice *device;
struct vl_compositor_state cstate;
 
struct {
@@ -375,7 +362,6 @@ typedef uint64_t vlVdpTime;
 
 typedef struct
 {
-   vlVdpTime timestamp;
vlVdpDevice *device;
struct pipe_surface *surface;
struct pipe_sampler_view *sampler_view;
@@ -387,6 +373,20 @@ typedef struct
 typedef struct
 {
vlVdpDevice *device;
+   Drawable drawable;
+} vlVdpPresentationQueueTarget;
+
+typedef struct
+{
+   vlVdpDevice *device;
+   Drawable drawable;
+   struct vl_compositor_state cstate;
+   vlVdpOutputSurface *last_surf;
+} vlVdpPresentationQueue;
+
+typedef struct
+{
+   vlVdpDevice *device;
struct pipe_video_decoder *decoder;
 } vlVdpDecoder;
 
-- 
1.7.9.5

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

[Mesa-dev] [PATCH 2/2] gallivm/soa: implement indirect addressing in immediates

[Zack Rusin]

The support is analogous to the way we handle indirect addressing
in temporaries, except that we don't have to worry about storing
(after declarations) and thus we'll able to keep using the old
code when indirect addressing isn't used. In other words we're
still using constants directly, unless the instrunction has
immediate register with indirect addressing.

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 ++
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |   78 ++-
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index 9d9c742..fd566b1 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -453,6 +453,12 @@ struct lp_build_tgsi_soa_context
 */
LLVMValueRef inputs_array;
 
+   /* We allocate/use this array of temps if (1 << TGSI_FILE_IMMEDIATE) is
+* set in the indirect_files field.
+*/
+   LLVMValueRef imms_array;
+
+
struct lp_bld_tgsi_system_values system_values;
 
/** bitmask indicating which register files are accessed indirectly */
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 733f0ed..066f64a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -972,8 +972,58 @@ emit_fetch_immediate(
unsigned swizzle)
 {
struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
-   LLVMValueRef res = bld->immediates[reg->Register.Index][swizzle];
-   assert(res);
+   struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
+   LLVMBuilderRef builder = gallivm->builder;
+   struct lp_build_context *uint_bld = &bld_base->uint_bld;
+   struct lp_build_context *float_bld = &bld_base->base;
+   LLVMValueRef res = NULL;
+   LLVMValueRef indirect_index = NULL;
+
+   if (reg->Register.Indirect) {
+  indirect_index = get_indirect_index(bld,
+  reg->Register.File,
+  reg->Register.Index,
+  ®->Indirect);
+   }
+
+   if (reg->Register.Indirect) {
+  LLVMValueRef swizzle_vec =
+ lp_build_const_int_vec(bld->bld_base.base.gallivm,
+uint_bld->type, swizzle);
+  LLVMValueRef length_vec =
+ lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
+bld->bld_base.base.type.length);
+  LLVMValueRef index_vec;  /* index into the const buffer */
+  LLVMValueRef imms_array;
+  LLVMValueRef pixel_offsets;
+  LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
+  LLVMTypeRef float4_ptr_type;
+  int i;
+
+  /* build pixel offset vector: {0, 1, 2, 3, ...} */
+  for (i = 0; i < float_bld->type.length; i++) {
+ offsets[i] = lp_build_const_int32(gallivm, i);
+  }
+  pixel_offsets = LLVMConstVector(offsets, float_bld->type.length);
+
+  /* index_vec = (indirect_index * 4 + swizzle) * length */
+  index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
+  index_vec = lp_build_add(uint_bld, index_vec, swizzle_vec);
+  index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
+  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
+
+  /* cast imms_array pointer to float* */
+  float4_ptr_type = LLVMPointerType(
+ LLVMFloatTypeInContext(bld->bld_base.base.gallivm->context), 0);
+  imms_array = LLVMBuildBitCast(builder, bld->imms_array,
+float4_ptr_type, "");
+
+  /* Gather values from the temporary register array */
+  res = build_gather(&bld_base->base, imms_array, index_vec);
+   }
+   else {
+  res = bld->immediates[reg->Register.Index][swizzle];
+   }
 
if (stype == TGSI_TYPE_UNSIGNED) {
   res = LLVMConstBitCast(res, bld_base->uint_bld.vec_type);
@@ -,6 +2272,21 @@ void lp_emit_immediate_soa(
for( i = size; i < 4; ++i )
   bld->immediates[bld->num_immediates][i] = bld_base->base.undef;
 
+   if (bld->indirect_files & (1 << TGSI_FILE_IMMEDIATE)) {
+  unsigned index = bld->num_immediates;
+  struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
+  LLVMBuilderRef builder = gallivm->builder;
+  for (i = 0; i < 4; ++i ) {
+ LLVMValueRef lindex = lp_build_const_int32(
+bld->bld_base.base.gallivm, index * 4 + i);
+ LLVMValueRef imm_ptr = LLVMBuildGEP(builder,
+ bld->imms_array, &lindex, 1, "");
+ LLVMBuildStore(builder, 
+bld->immediates[index][i],
+imm_ptr);
+  }
+   }
+
bld->num_immediates++;
 }
 
@@ -2934,6 +2999,15 @@ static void emit_prologue(struct lp_build_tgsi_context * 
bld_base)
   

[Mesa-dev] [PATCH 1/2] draw/gs: don't bind the tgsi state if we're using llvm paths

[Zack Rusin]

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_gs.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
b/src/gallium/auxiliary/draw/draw_gs.c
index fcd6e2d..fa0981e 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -661,7 +661,12 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
 void draw_geometry_shader_prepare(struct draw_geometry_shader *shader,
   struct draw_context *draw)
 {
-   if (shader && shader->machine->Tokens != shader->state.tokens) {
+#ifdef HAVE_LLVM
+   boolean use_llvm = draw_get_option_use_llvm();
+#else
+   boolean use_llvm = FALSE;
+#endif
+   if (!use_llvm && shader && shader->machine->Tokens != shader->state.tokens) 
{
   tgsi_exec_machine_bind_shader(shader->machine,
 shader->state.tokens,
 draw->gs.tgsi.sampler);
-- 
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/12] glsl: Death to array dereferences of vectors!

[Kenneth Graunke]

On 05/03/2013 04:07 PM, Ian Romanick wrote:

From: Ian Romanick 

Now that all the places that used to generate array derefeneces of
vectors have been changed to generate either ir_binop_vector_extract or
ir_triop_vector_insert (or both), remove all support for dealing with
this deprecated construct.

As an added safeguard, modify ir_validate to reject ir_dereference_array
of a vector.

v2: Convert tabs to spaces.  Suggested by Eric.

Signed-off-by: Ian Romanick 
Reviewed-by: Eric Anholt 


Cool, I'm done reviewing.  Patches 10-12 and anything I didn't 
explicitly have comments on are:

Reviewed-by: Kenneth Graunke 

This looks nicer.  Thanks for doing it, Ian!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] draw/llvm: Add additional llvm optimization passes

[Brian Paul]

On 05/08/2013 03:14 AM, Stéphane Marchesin wrote:

It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).

I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop optimizations could
still be useful in the future.
---
  src/gallium/auxiliary/gallivm/lp_bld_init.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 673c16e..4a428ee 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -147,7 +147,10 @@ create_pass_manager(struct gallivm_state *gallivm)
 * but there are more on SVN.
 * TODO: Add more passes.
 */
+  LLVMAddScalarReplAggregatesPass(gallivm->passmgr);
+  LLVMAddLICMPass(gallivm->passmgr);
LLVMAddCFGSimplificationPass(gallivm->passmgr);
+  LLVMAddReassociatePass(gallivm->passmgr);

if (HAVE_LLVM>= 0x207&&  sizeof(void*) == 4) {
   /* For LLVM>= 2.7 and 32-bit build, use this order of passes to


Reviewed-by: Brian Paul 

We should probably give these a try with llvmpipe too...

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

Re: [Mesa-dev] [PATCH] R600: Remove AMDILPeeopholeOptimizer and replace optimizations with tablegen patterns

[Tom Stellard]

On Tue, May 07, 2013 at 10:48:53AM +0200, Christian König wrote:
> Am 06.05.2013 18:48, schrieb Tom Stellard:
> >From: Tom Stellard 
> >
> >The BFE optimization was the only one we were actually using, and it was
> >emitting an intrinsic that we don't support.
> >
> >https://bugs.freedesktop.org/show_bug.cgi?id=64201
> 
> The patch has my rb.
> 
> I'm wondering if we shouldn't get ride of all those AMDIL* files,
> cause we obviously don't use that namespace anymore and at least I
> sometimes wonder why we still have AMDILISelLowering.cpp and
> AMDGPUISelLowering.cpp.
>

I would like to drop the AMDIL* files.  Most of them are still used
in one way or another, so maybe all we can do now is rename them.

I left AMDILISelLowering.cpp in because I was worried removing it would
break things, but maybe it's safe to remove it now that the backend is
more mature.

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

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Roland Scheidegger]

Am 08.05.2013 12:47, schrieb Marek Olšák:
> Modifiers are actually very useful with MOV. However I don't think the
> modifiers really care what the type is. They just change the sign bit
> of float (which is a bitwise operation). Also, UCMP doesn't do
> anything with the 2nd and 3rd argument, so their types don't matter.
Well, they do matter for the input modifiers.
They might just change the most significant bit on your hardware but
that's not how they are defined in tgsi.
I don't really care that much if the 2nd and 3rd argument to ucmp are
ints or floats (it's true for d3d10 movc translation floats are the
natural choice but we can easily translate that to several ops instead,
e.g. mov's with modifiers followed by ucmp). I do care however that all
drivers treat them the same, not like now where softpipe will do two's
complement negation on src input modifiers whereas llvmpipe will flip
the sign bit.

> 
> I think the ABS and SUB opcodes should be removed in favor of the modifiers.
Those are in very widespread use and at least for SUB it definitely
avoids additional effort for drivers which can't do input modifiers
natively.

Roland


> 
> Marek
> 
> On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
>  wrote:
>> On 08.05.2013 03:48, srol...@vmware.com wrote:
>>> From: Roland Scheidegger 
>>>
>>> UCMP while an integer opcode isn't really consistently implemented as
>>> having all integer arguments. softpipe will assume all arguments are
>>> ints, whereas gallivm has the arguments defined as untyped which
>>> means they'll get treated as floats. This means input modifiers will
>>> not work the same. Fix this by saying only first arg is an integer,
>>> which seems more useful than making all arguments integers - this would
>>> be similar to d3d10 movc opcode.
>>> ---
>>>  src/gallium/docs/source/tgsi.rst |5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/src/gallium/docs/source/tgsi.rst 
>>> b/src/gallium/docs/source/tgsi.rst
>>> index 3af1fb7..852f8a0 100644
>>> --- a/src/gallium/docs/source/tgsi.rst
>>> +++ b/src/gallium/docs/source/tgsi.rst
>>> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by 
>>> PIPE_SHADER_CAP_INTEGERS (all of them?)
>>>
>>>  .. opcode:: UCMP - Integer Conditional Move
>>>
>>> +.. note::
>>> +
>>> +   Only the first source arg is an integer, the 2nd and 3rd ones are
>>> +   considered floats (for input modifier purposes).
>>> +
>>
>> As long as you patch up all the occurrences of
>> tgsi_opcode_infer_src_type and make it take an argument to identify the
>> source ...
>>
>> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
>> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated on.
>> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
>> optimizer can take care of merging modifiers into the instruction
>> (nvc0's UCMP (slct u32) doesn't support modifiers)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] fix deadlock with libX11

[Christian König]

From: Christian König 

libX11 acquires the display lock before calling "xcb_take_socket" and inside
the "return_socket" callback, this can lead to a classic deadlock situation
with the XCB iolock. Releasing the lock while calling "return_socket" only
partially helps because we still try to avoid calling return_socket from
multiple threads by using an extra condition.

This patch removes the unnecessary extra signaling and just documents that
"return_socket" might be called by multiple threads at the same time (which
works fine with how libX11 is using the interface).

Signed-off-by: Christian König 
---
 src/xcb_out.c |   36 +++-
 src/xcbext.h  |6 --
 src/xcbint.h  |7 ---
 3 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/src/xcb_out.c b/src/xcb_out.c
index 405f963..5eddab8 100644
--- a/src/xcb_out.c
+++ b/src/xcb_out.c
@@ -86,20 +86,23 @@ static void send_sync(xcb_connection_t *c)
 
 static void get_socket_back(xcb_connection_t *c)
 {
-while(c->out.return_socket && c->out.socket_moving)
-pthread_cond_wait(&c->out.socket_cond, &c->iolock);
-if(!c->out.return_socket)
-return;
-
-c->out.socket_moving = 1;
-pthread_mutex_unlock(&c->iolock);
-c->out.return_socket(c->out.socket_closure);
-pthread_mutex_lock(&c->iolock);
-c->out.socket_moving = 0;
-
-pthread_cond_broadcast(&c->out.socket_cond);
-c->out.return_socket = 0;
-c->out.socket_closure = 0;
+while (c->out.return_socket) {
+/* we are about to release the lock,
+   so make a copy of the current status */
+xcb_return_socket_func_t return_socket = c->out.return_socket;
+void *socket_closure = c->out.socket_closure;
+int socket_seq = c->out.socket_seq;
+
+pthread_mutex_unlock(&c->iolock);
+return_socket(socket_closure);
+pthread_mutex_lock(&c->iolock);
+
+/* make sure nobody else has acquired the socket */
+if (socket_seq == c->out.socket_seq) {
+c->out.return_socket = 0;
+c->out.socket_closure = 0;
+}
+}
 _xcb_in_replies_done(c);
 }
 
@@ -278,6 +281,7 @@ int xcb_take_socket(xcb_connection_t *c, void 
(*return_socket)(void *closure), v
 {
 c->out.return_socket = return_socket;
 c->out.socket_closure = closure;
+++c->out.socket_seq;
 if(flags)
 _xcb_in_expect_reply(c, c->out.request, 
WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
 assert(c->out.request == c->out.request_written);
@@ -314,11 +318,9 @@ int xcb_flush(xcb_connection_t *c)
 
 int _xcb_out_init(_xcb_out *out)
 {
-if(pthread_cond_init(&out->socket_cond, 0))
-return 0;
 out->return_socket = 0;
 out->socket_closure = 0;
-out->socket_moving = 0;
+out->socket_seq = 0;
 
 if(pthread_cond_init(&out->cond, 0))
 return 0;
diff --git a/src/xcbext.h b/src/xcbext.h
index 98b3c93..f8520a0 100644
--- a/src/xcbext.h
+++ b/src/xcbext.h
@@ -66,8 +66,10 @@ unsigned int xcb_send_request(xcb_connection_t *c, int 
flags, struct iovec *vect
  * callback which XCB can call when it wants the write side of the
  * socket back to make a request. This callback synchronizes with the
  * external socket owner and flushes any output queues if appropriate.
- * If you are sending requests which won't cause a reply, please note the
- * comment for xcb_writev which explains some sequence number wrap issues.
+ * It is called without any locks held and so might be called from different
+ * threads at the same time. If you are sending requests which won't
+ * cause a reply, please note the comment for xcb_writev which explains
+ * some sequence number wrap issues.
  * */
 int xcb_take_socket(xcb_connection_t *c, void (*return_socket)(void *closure), 
void *closure, int flags, uint64_t *sent);
 
diff --git a/src/xcbint.h b/src/xcbint.h
index f9e5a52..c68b2fa 100644
--- a/src/xcbint.h
+++ b/src/xcbint.h
@@ -79,14 +79,15 @@ void *_xcb_map_remove(_xcb_map *q, unsigned int key);
 
 /* xcb_out.c */
 
+typedef void (*xcb_return_socket_func_t)(void *closure);
+
 typedef struct _xcb_out {
 pthread_cond_t cond;
 int writing;
 
-pthread_cond_t socket_cond;
-void (*return_socket)(void *closure);
+xcb_return_socket_func_t return_socket;
 void *socket_closure;
-int socket_moving;
+int socket_seq;
 
 char queue[XCB_QUEUE_BUFFER_SIZE];
 int queue_len;
-- 
1.7.9.5

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

[Mesa-dev] Improved Patch review using Gerrit

[Christoph Brill]

Hi list,

I'm trying to follow the patches and patchsets sent to mesa-dev and
really like the process of how they get reviewed. It's a good way of
catching bugs before they get committed. But currently this approach
has a downside (at least for me): It's easy to miss a patch and
happens from time to time to others as well (see
http://lists.freedesktop.org/archives/mesa-dev/2013-May/039178.html )

Has anyone thought about using Gerrit for code reviews (like done for
Libreoffice at https://gerrit.libreoffice.org/ )? I like the way it
integrates with git and might be a good idea to use for mesa-dev (and
maybe even dri-devel) as well.

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

Re: [Mesa-dev] : Who to contact if I want to do this Automatic testing in the To-Do List

[Christian König]

Hi Peter,

Am 08.05.2013 11:48, schrieb test automation:

Hi Everyone,

Could you please tell me about whom to contact if I want to do this
Automatic testing in the To-Do List ?

Help Wanted / To-Do List

*Automatic testing. * It would be great if someone would set up an
automated system for grabbing the latest Mesa code and run tests (such as
piglit) then report issues to the mailing list.


well asking on this list is a pretty good start.

The answer to this question somewhat depends on what kind of hardware do 
you want to test? AMD/NVidia/Intel or even CPU only based rendering?


Cheers,
Christian.


Thanks,
PeterT



___
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] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Marek Olšák]

Modifiers are actually very useful with MOV. However I don't think the
modifiers really care what the type is. They just change the sign bit
of float (which is a bitwise operation). Also, UCMP doesn't do
anything with the 2nd and 3rd argument, so their types don't matter.

I think the ABS and SUB opcodes should be removed in favor of the modifiers.

Marek

On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
 wrote:
> On 08.05.2013 03:48, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> UCMP while an integer opcode isn't really consistently implemented as
>> having all integer arguments. softpipe will assume all arguments are
>> ints, whereas gallivm has the arguments defined as untyped which
>> means they'll get treated as floats. This means input modifiers will
>> not work the same. Fix this by saying only first arg is an integer,
>> which seems more useful than making all arguments integers - this would
>> be similar to d3d10 movc opcode.
>> ---
>>  src/gallium/docs/source/tgsi.rst |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/src/gallium/docs/source/tgsi.rst 
>> b/src/gallium/docs/source/tgsi.rst
>> index 3af1fb7..852f8a0 100644
>> --- a/src/gallium/docs/source/tgsi.rst
>> +++ b/src/gallium/docs/source/tgsi.rst
>> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by 
>> PIPE_SHADER_CAP_INTEGERS (all of them?)
>>
>>  .. opcode:: UCMP - Integer Conditional Move
>>
>> +.. note::
>> +
>> +   Only the first source arg is an integer, the 2nd and 3rd ones are
>> +   considered floats (for input modifier purposes).
>> +
>
> As long as you patch up all the occurrences of
> tgsi_opcode_infer_src_type and make it take an argument to identify the
> source ...
>
> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated on.
> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
> optimizer can take care of merging modifiers into the instruction
> (nvc0's UCMP (slct u32) doesn't support modifiers).
>
>>  .. math::
>>
>>dst.x = src0.x ? src1.x : src2.x
>>
>
> ___
> 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 01/17] mesa: consolidate definitions of max texture image units

[Marek Olšák]

On Thu, May 2, 2013 at 7:12 PM, Eric Anholt  wrote:
> Marek Olšák  writes:
>
>> Shaders are unified on most hardware (= same limits in all stages).
>> No idea what the assertion was good for.
>> ---
>>  src/mesa/main/config.h |6 ++
>>  src/mesa/main/context.c|6 ++
>>  src/mesa/state_tracker/st_extensions.c |2 +-
>>  3 files changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>> index 33b5ab0..76863bf 100644
>> --- a/src/mesa/main/config.h
>> +++ b/src/mesa/main/config.h
>
>> -   assert(MAX_COMBINED_TEXTURE_IMAGE_UNITS <= 8 * sizeof(GLbitfield));
>> -
>
> I think this assert is asserting that _EnabledUnits of gl_texture_attrib
> can fit the size of the Unit[] array, which seems important.

With Gallium drivers, _EnabledUnits is only used for the
fixed-function vertex program, where the number of texture coord units
is limited to 8. The fixed-function vertex program doesn't even use
the bits of _EnabledUnits, it only checks if the variable is non-zero,
so it could just be a boolean.

However, swrast uses _EnabledUnits, though the variable seems to be
used for fixed-function only.

Is this explanation satisfactory that _EnabledUnits doesn't need to
have more than 32 bits or am I missing something else?

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

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

[Christoph Bumiller]

On 08.05.2013 03:48, srol...@vmware.com wrote:
> From: Roland Scheidegger 
> 
> UCMP while an integer opcode isn't really consistently implemented as
> having all integer arguments. softpipe will assume all arguments are
> ints, whereas gallivm has the arguments defined as untyped which
> means they'll get treated as floats. This means input modifiers will
> not work the same. Fix this by saying only first arg is an integer,
> which seems more useful than making all arguments integers - this would
> be similar to d3d10 movc opcode.
> ---
>  src/gallium/docs/source/tgsi.rst |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index 3af1fb7..852f8a0 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by 
> PIPE_SHADER_CAP_INTEGERS (all of them?)
>  
>  .. opcode:: UCMP - Integer Conditional Move
>  
> +.. note::
> +
> +   Only the first source arg is an integer, the 2nd and 3rd ones are
> +   considered floats (for input modifier purposes).
> +

As long as you patch up all the occurrences of
tgsi_opcode_infer_src_type and make it take an argument to identify the
source ...

I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated on.
For the ordinary MOV we have NEG and ABS, and for UCMP the backend
optimizer can take care of merging modifiers into the instruction
(nvc0's UCMP (slct u32) doesn't support modifiers).

>  .. math::
>  
>dst.x = src0.x ? src1.x : src2.x
> 

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

[Mesa-dev] [PATCH] i965: verify depth render buffer depth when in fast clear WIP

[Tapani Pälli]

Patch makes sure in conservative way that the depth_clear_value
is correct and represents max depth of current depth buffer.

This fixes the case where user has 16bit color buffer but 24bit
depth buffer and 'fb->_DepthMax' has a wrong value. I'm currently
investigating how to get _DepthMax corrected on mesa side, but
meanwhile this patch will enable correct rendering results for
16bit benchmarks instead of displaying only white color on the
screen. This bug does not happen with user created framebuffers,
only with window system ones.

Signed-off-by: Tapani Pälli 
---
 src/mesa/drivers/dri/i965/brw_clear.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 2b999bf..28dd872 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -129,6 +129,9 @@ brw_fast_clear_depth(struct gl_context *ctx)
}
 
uint32_t depth_clear_value;
+   struct gl_renderbuffer *depth_rb =
+  ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
+   uint32_t depth_bits = _mesa_get_format_bits(depth_rb->Format, 
GL_DEPTH_BITS);
switch (mt->format) {
case MESA_FORMAT_Z32_FLOAT_X24S8:
case MESA_FORMAT_S8_Z24:
@@ -161,7 +164,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
   /* FALLTHROUGH */
 
default:
-  depth_clear_value = fb->_DepthMax * ctx->Depth.Clear;
+  depth_clear_value = ((1 << depth_bits) - 1) * ctx->Depth.Clear;
   break;
}
 
-- 
1.8.1.4

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

[Mesa-dev] : Who to contact if I want to do this Automatic testing in the To-Do List

[test automation]

Hi Everyone,

Could you please tell me about whom to contact if I want to do this
Automatic testing in the To-Do List ?

Help Wanted / To-Do List

*Automatic testing. * It would be great if someone would set up an
automated system for grabbing the latest Mesa code and run tests (such as
piglit) then report issues to the mailing list.

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

Re: [Mesa-dev] [PATCH] egl/android: Fix error condition for EGL_ANDROID_image_native_buffer

[Tapani Pälli]

On 05/07/2013 12:23 AM, Chad Versace wrote:

Emit EGL_BAD_CONTEXT if the user passes a context to
eglCreateImageKHR(type=EGL_ANDROID_image_native_buffer).

 From the EGL_ANDROID_image_native_buffer spec:
   * If  is EGL_NATIVE_BUFFER_ANDROID and  is not
 EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.

Note: This is a candidate for the stable branches.
CC: Tapani Pälli 
Signed-off-by: Chad Versace 
---
  src/egl/drivers/dri2/platform_android.c | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)


Yep, this makes the implementation complete as in spec.

Reviewed-by: Tapani Pälli 


diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index cee4035..ed50907 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -337,7 +337,7 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
  }
  
  static _EGLImage *

-dri2_create_image_android_native_buffer(_EGLDisplay *disp,
+dri2_create_image_android_native_buffer(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf)
  {
 struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
@@ -346,6 +346,18 @@ dri2_create_image_android_native_buffer(_EGLDisplay *disp,
 uint32_t offsets[3], strides[3], handles[3], tmp;
 EGLint format;
  
+   if (ctx != NULL) {

+  /* From the EGL_ANDROID_image_native_buffer spec:
+   *
+   * * If  is EGL_NATIVE_BUFFER_ANDROID and  is not
+   *   EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
+   */
+  _eglError(EGL_BAD_CONTEXT, "eglCreateEGLImageKHR: for "
+"EGL_NATIVE_BUFFER_ANDROID, the context must be "
+"EGL_NO_CONTEXT");
+  return NULL;
+   }
+
 if (!buf || buf->common.magic != ANDROID_NATIVE_BUFFER_MAGIC ||
 buf->common.version != sizeof(*buf)) {
_eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
@@ -479,7 +491,7 @@ droid_create_image_khr(_EGLDriver *drv, _EGLDisplay *disp,
  {
 switch (target) {
 case EGL_NATIVE_BUFFER_ANDROID:
-  return dri2_create_image_android_native_buffer(disp,
+  return dri2_create_image_android_native_buffer(disp, ctx,
  (struct ANativeWindowBuffer *) buffer);
 default:
return dri2_create_image_khr(drv, disp, ctx, target, buffer, attr_list);


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

[Mesa-dev] [PATCH] draw/llvm: Add additional llvm optimization passes

[Stéphane Marchesin]

It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).

I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop optimizations could
still be useful in the future.
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 673c16e..4a428ee 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -147,7 +147,10 @@ create_pass_manager(struct gallivm_state *gallivm)
* but there are more on SVN.
* TODO: Add more passes.
*/
+  LLVMAddScalarReplAggregatesPass(gallivm->passmgr);
+  LLVMAddLICMPass(gallivm->passmgr);
   LLVMAddCFGSimplificationPass(gallivm->passmgr);
+  LLVMAddReassociatePass(gallivm->passmgr);
 
   if (HAVE_LLVM >= 0x207 && sizeof(void*) == 4) {
  /* For LLVM >= 2.7 and 32-bit build, use this order of passes to
-- 
1.7.6.5

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