Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM

[Boris BREZILLON]

Hello Giovanni,

On Thu, 3 Jul 2014 11:14:48 +0200
Giovanni Campagna  wrote:

> 2014-07-03 10:48 GMT+02:00 Boris BREZILLON 
> :
> > Hello Giovanni,
> >
> > I have recently been working on a DRM/KMS driver which does not support
> > OpenGL rendering (it only provides plane composition functionalities):
> > [1].
> >
> > If I understand correctly you patch series might solve some of the
> > issues I am facing.
> 
> It might get your working EGL, but it's not a complete solution,
> because buffer management is limited to linear CPU-addressable "dumb"
> buffers, which is probably not the most efficient choice (altough how
> much slower it gets depends on the driver and on the HWl).
> 
> > I'm trying to get wayland working with HW cursor and several planes,
> > the problem is that it depends on GBM to provides drm plane and drm
> > cursor support.
> >
> > I tried to get EGL working with my DRM device and it always ask for an
> > atmel-hlcdc_dri.so module (I have applied this patch [2] to get to this
> > point).
> >
> > First of all, am I mistaken in thinking this series could solve my
> > issue ?
> 
> Indeed, using my patch stack (patches 2 and 3) you will have a working
> GBM device that will allocate GPU memory using the "dumb" interface.
> If your driver is then able to upload this buffers to the plane HW (or
> directly capable of allocating in GPU memory), that may be good enough
> for you.
> OTOH, this will not provide the wayland clients with the ability to
> render directly to the plane buffers, because the "dumb" interface
> does not provide global names that can be shared between processes,
> therefore clients will have to render into a shared memory location,
> that then the wayland compositor (weston, I assume) will have to
> memcpy into a GBM allocated buffer.
> If you want to avoid that, you will need to design an ioctl interface
> for your driver to allocate buffers, then write a "winsys" for the
> userspace side that uses those ioctls (directly or through libdrm) -
> first it allocates the buffer with your driver specific ioctl and then
> calls GEM_FLINK to get the global name, which can be passed to weston
> and in there to gbm_bo_import().
> If your HW is uncapable of GL rendering (and thus you want to use SW
> rendering always) is quite likely that your driver will not be that
> different from
> dri_kms_swrast, except that will be able to share buffers (patch 3)
> using GEM names.

I'm just curious: what are you using this dri_kms_swrast implementation
for ?

Okay, my real question here is: Is there other people trying to do what
I'm doing or do you need it for another use case :-) ?

Best Regards,

Boris



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 81162] New: Multicore Rendering issue on Intel Ironlake Mobile chipsets

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 81162
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Multicore Rendering issue on Intel Ironlake Mobile
chipsets
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: bubakpat...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Other
   Product: Mesa

All the details are explained here:
https://github.com/ValveSoftware/Source-1-Games/issues/1739 and here:
https://github.com/ValveSoftware/Source-1-Games/issues/457

My specs:

System:Host: innerdistance-Satellite-L650 Kernel: 3.13.0-30-generic x86_64
(64 bit) 
   Desktop: Gnome Distro: Ubuntu 14.04 trusty
Machine:   System: TOSHIBA product: Satellite L650 version: PSK1EE-00Y007SK
   Mobo: TOSHIBA model: Portable PC Bios: INSYDE version: 2.40 date:
11/09/2011
CPU:   Dual core Intel Core i3 CPU M 330 (-HT-MCP-) cache: 3072 KB flags:
(lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) 
   Clock Speeds: 1: 933.00 MHz 2: 933.00 MHz 3: 933.00 MHz 4: 933.00
MHz
Graphics:  Card: Intel Core Processor Integrated Graphics Controller 
   X.Org: 1.15.1 drivers: intel (unloaded: fbdev,vesa) Resolution:
1366x768@60.0hz 
   GLX Renderer: Mesa DRI Intel Ironlake Mobile GLX Version: 2.1 Mesa
10.3.0-devel (git-50bbe49 trusty-oibaf-ppa)
Audio: Card: Intel 5 Series/3400 Series High Definition Audio driver:
snd_hda_intel Sound: ALSA ver: k3.13.0-30-generic
Network:   Card-1: Realtek RTL8191SEvB Wireless LAN Controller driver:
rtl8192se 
   IF: wlan0 state: up mac: b4:82:fe:bd:63:26
   Card-2: Qualcomm Atheros AR8152 v1.1 Fast Ethernet driver: atl1c 
   IF: eth0 state: down mac: 00:26:6c:6e:2e:52
Drives:HDD Total Size: 500.1GB (20.6% used) 1: id: /dev/sda model:
Hitachi_HTS54505 size: 500.1GB 
Partition: ID: / size: 46G used: 7.7G (18%) fs: ext4 ID: /home size: 241G used:
89G (39%) fs: ext4 
   ID: swap-1 size: 4.09GB used: 0.03GB (1%) fs: swap 
RAID:  No RAID devices detected - /proc/mdstat and md_mod kernel raid
module present
Sensors:   System Temperatures: cpu: 53.0C mobo: N/A 
   Fan Speeds (in rpm): cpu: N/A 
Info:  Processes: 252 Uptime: 3:34 Memory: 2451.7/3753.0MB Client: Shell
(bash) inxi: 1.9.17

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

[Mesa-dev] [Bug 81174] New: Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 81174
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Gallium: GL_LINE_LOOP broken with more than 512 points
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: florianl...@gmail.com
  Hardware: Other
Status: NEW
   Version: 10.2
 Component: Mesa core
   Product: Mesa

Created attachment 102536
  --> https://bugs.freedesktop.org/attachment.cgi?id=102536&action=edit
This should be a circle...

The error ocurrs on Windows 7 and on Linux with Mesa softpipe and llvm.

There seem to be random lines between non-adjacent points in the line loop.
When switching to GL_LINE_STRIP, the error disappears.

Attached you find a screenshot and a Qt example program (see glwidget.cpp for
the minimal GL_LINE_LOOP code).

The bug only happens when there are more than about 512 lines and there are
more errors the more lines are in the loop (as seen in the screenshot).

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

[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #102536|text/plain  |image/png
  mime type||

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

[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

--- Comment #1 from Florian Link  ---
Created attachment 102537
  --> https://bugs.freedesktop.org/attachment.cgi?id=102537&action=edit
A Qt example that demonstrates the problem

-- 
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

Re: [Mesa-dev] [PATCH 1/2] meta: Add a state flag for the GL_DITHER

[Pohjolainen, Topi]

On Mon, Jul 07, 2014 at 12:27:29PM +0100, Neil Roberts wrote:
> "Pohjolainen, Topi"  writes:
> 
> > All the other state flags considered in _mesa_meta_begin() are
> > explicitly set as disabled. And having noticed that you
> > unconditionally disable dithering also in cleartexsubimage_using_fbo()
> > I'm wondering if I'm missing something.
> 
> My understanding is that _mesa_meta_begin is supposed to reset the state
> to the GL defaults and dithering is enabled by default in GL.
> 
> If I were to set it to disabled then it would also affect things like
> _mesa_meta_GenerateMipmap which uses MESA_META_ALL. Presumably that
> function will currently either use dithering or not depending on whether
> the user has toggled the state. I think it makes sense for that function
> to always use dithering so this patch arguably fixes a bug with that
> function (and others).

Thanks for the explanation, that makes perfect sense to me at least.

> 
> Thanks for the review.
> 
> Regards,
> - Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 80183] [llvmpipe] triangles with vertices that map to raster positions > viewport width/height are not displayed

[bugzilla-daemon]

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

--- Comment #2 from Florian Link  ---
I found out that the problem is the line:

gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;

in the fragment shader. If I remove that line, it works as expected.

Since the rendering is ok on ATI/NVidia and on softpipe, I suspect that
gl_ClipVertex support is broken in LLVM pipe.

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

[Mesa-dev] [Bug 80183] [llvmpipe] triangles with vertices that map to raster positions > viewport width/height are not displayed

[bugzilla-daemon]

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

--- Comment #3 from Brian Paul  ---
(In reply to comment #2)
> I found out that the problem is the line:
> 
> gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
> 
> in the fragment shader. If I remove that line, it works as expected.
> 
> Since the rendering is ok on ATI/NVidia and on softpipe, I suspect that
> gl_ClipVertex support is broken in LLVM pipe.

Are you sure you're seeing that in the fragment shader?  Vertex-related code
like that would normally be seen in the vertex shader.

-- 
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

Re: [Mesa-dev] [PATCH v2] glsl: Fix aggregates with dynamic initializers.

[Cody Northrop]

No, that's the same experiment I would have run.  I was hoping the original
authors could chime in, but it sounds like you have more insight via AoA
work.

I'll resubmit with your change, thanks!

-C



On Wed, Jul 9, 2014 at 5:36 PM, Timothy Arceri 
wrote:

> On Wed, 2014-07-02 at 22:16 +1000, Timothy Arceri wrote:
> > On Tue, 2014-07-01 at 14:45 -0700, Kenneth Graunke wrote:
> > > From: Cody Northrop 
> > >
> > > Vectors are falling in to the ir_dereference_array() path.
> > >
> > > Without this change, the following glsl aborts the debug driver,
> > > or gets the wrong answer in release:
> > >
> > > mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
> > >
> > > Also submitting piglit tests, will reference in bug.
> > >
> > > v2: Rebase on Mesa master.
> > >
> > > Signed-off-by: Cody Northrop 
> > > Reviewed-by: Courtney Goeltzenleuchter 
> > > Reviewed-by: Kenneth Graunke 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79373
> > > ---
> > >  src/glsl/ast_function.cpp | 16 +---
> > >  1 file changed, 13 insertions(+), 3 deletions(-)
> > >
> > > Hi Cody,
> > >
> > > Your patch didn't apply to master due to Matt's foreach_list changes;
> > > I did the obvious rebase.  Otherwise, it looks great.  Thanks for
> fixing
> > > this and improving our tests!
> > >
> > > I'll plan to commit this tomorrow unless anyone else has objections.
> > >
> > >  --Ken
> > >
> > > diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> > > index cdb34cc..98288d2 100644
> > > --- a/src/glsl/ast_function.cpp
> > > +++ b/src/glsl/ast_function.cpp
> > > @@ -743,10 +743,20 @@ process_vec_mat_constructor(exec_list
> *instructions,
> > >
> > > int i = 0;
> > > foreach_in_list(ir_rvalue, rhs, &actual_parameters) {
> > > -  ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
> > > - new(ctx)
> ir_constant(i));
> > > +  ir_instruction *assignment = NULL;
> > > +
> > > +  if (var->type->is_array() || var->type->is_matrix()) {
> >
> > Is this ever actually an array???
>
> I didn't mean for my question to hold this up for so long. But I cant
> see where this would ever be an array, if my understanding is correct
> process_array_constructor() should process any arrays. When removing
> var->type->is_array() all arb_shading_language_420pack piglit tests
> (including the new ones) continue to pass. So I don't think the
> is_array() condition is needed.
>
> If I'm wrong could you please give an example of when this would be an
> array as it might affect my arrays of arrays work.
>
>
> >
> > > + ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
> > > + new(ctx) ir_constant(i));
> > > + assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
> > > +  } else {
> > > + /* use writemask rather than index for vector */
> > > + assert(var->type->is_vector());
> > > + assert(i < 4);
> > > + ir_dereference *lhs = new(ctx) ir_dereference_variable(var);
> > > + assignment = new(ctx) ir_assignment(lhs, rhs, NULL,
> (unsigned)(1 << i));
> > > +  }
> > >
> > > -  ir_instruction *assignment = new(ctx) ir_assignment(lhs, rhs,
> NULL);
> > >instructions->push_tail(assignment);
> > >
> > >i++;
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>


-- 
 Cody Northrop
 Graphics Software Engineer
 LunarG, Inc.- 3D Driver Innovations
 Email: c...@lunarg.com
 Website: http://www.lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] configure.ac: require LLVM 3.4.2 for radeon

[Tom Stellard]

On Tue, Jul 08, 2014 at 03:37:02AM +0200, Marek Olšák wrote:
> From: Marek Olšák 
> 
> Needed by ARB_draw_indirect.

I think we should come up with a rule for how long we should support
older versions of LLVM.  Do you have any thoughts about this?  I was
thinking we could have each Mesa release support current stable LLVM
and also the development version from SVN.

-Tom

> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4646212..9d5cd89 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1888,8 +1888,9 @@ radeon_llvm_check() {
>  AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
>  fi
>  LLVM_REQUIRED_VERSION_MAJOR="3"
> -LLVM_REQUIRED_VERSION_MINOR="3"
> -if test "$LLVM_VERSION_INT" -lt 
> "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}"; then
> +LLVM_REQUIRED_VERSION_MINOR="4"
> +LLVM_REQUIRED_VERSION_PATCH="2"
> +if test "${LLVM_VERSION_INT}${LLVM_VERSION_PATCH}" -lt 
> "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}${LLVM_REQUIRED_VERSION_PATCH}";
>  then
>  AC_MSG_ERROR([LLVM 
> $LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is 
> required for $1])
>  fi
>  if test true && $LLVM_CONFIG --targets-built | grep -qvw 'R600' ; then
> -- 
> 1.9.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radeonsi: switch descriptors to i32 vectors

[Tom Stellard]

On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
> From: Marek Olšák 
> 
> This is a follow-up to the commit which adds texture fetches with offsets.

Will this still work with LLVM 3.4.2 ?

-Tom

> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 29 -
>  1 file changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 3dd6ad1..a28d682 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1574,7 +1574,7 @@ static void tex_fetch_args(
>   LLVMTypeRef i8 = LLVMInt8TypeInContext(gallivm->context);
>   LLVMTypeRef v16i8 = LLVMVectorType(i8, 16);
>  
> - /* Truncate v32i8 to v16i8. */
> + /* Bitcast and truncate v8i32 to v16i8. */
>   LLVMValueRef res = si_shader_ctx->resources[sampler_index];
>   res = LLVMBuildBitCast(gallivm->builder, res, v2i128, "");
>   res = LLVMBuildExtractElement(gallivm->builder, res, 
> bld_base->uint_bld.zero, "");
> @@ -2305,12 +2305,18 @@ static void create_meta_data(struct si_shader_context 
> *si_shader_ctx)
>   si_shader_ctx->const_md = LLVMMDNodeInContext(gallivm->context, args, 
> 3);
>  }
>  
> +static LLVMTypeRef const_array(LLVMTypeRef elem_type, int num_elements)
> +{
> + return LLVMPointerType(LLVMArrayType(elem_type, num_elements),
> +CONST_ADDR_SPACE);
> +}
> +
>  static void create_function(struct si_shader_context *si_shader_ctx)
>  {
>   struct lp_build_tgsi_context *bld_base = 
> &si_shader_ctx->radeon_bld.soa.bld_base;
>   struct gallivm_state *gallivm = bld_base->base.gallivm;
>   struct si_pipe_shader *shader = si_shader_ctx->shader;
> - LLVMTypeRef params[SI_NUM_PARAMS], f32, i8, i32, v2i32, v3i32;
> + LLVMTypeRef params[SI_NUM_PARAMS], f32, i8, i32, v2i32, v3i32, v16i8, 
> v4i32, v8i32;
>   unsigned i, last_sgpr, num_params;
>  
>   i8 = LLVMInt8TypeInContext(gallivm->context);
> @@ -2318,21 +2324,18 @@ static void create_function(struct si_shader_context 
> *si_shader_ctx)
>   f32 = LLVMFloatTypeInContext(gallivm->context);
>   v2i32 = LLVMVectorType(i32, 2);
>   v3i32 = LLVMVectorType(i32, 3);
> + v4i32 = LLVMVectorType(i32, 4);
> + v8i32 = LLVMVectorType(i32, 8);
> + v16i8 = LLVMVectorType(i8, 16);
>  
> - params[SI_PARAM_CONST] = LLVMPointerType(
> - LLVMArrayType(LLVMVectorType(i8, 16), NUM_CONST_BUFFERS), 
> CONST_ADDR_SPACE);
> - params[SI_PARAM_RW_BUFFERS] = params[SI_PARAM_CONST];
> -
> - /* We assume at most 16 textures per program at the moment.
> -  * This need probably need to be changed to support bindless textures */
> - params[SI_PARAM_SAMPLER] = LLVMPointerType(
> - LLVMArrayType(LLVMVectorType(i8, 16), NUM_SAMPLER_STATES), 
> CONST_ADDR_SPACE);
> - params[SI_PARAM_RESOURCE] = LLVMPointerType(
> - LLVMArrayType(LLVMVectorType(i8, 32), NUM_SAMPLER_VIEWS), 
> CONST_ADDR_SPACE);
> + params[SI_PARAM_CONST] = const_array(v16i8, NUM_CONST_BUFFERS);
> + params[SI_PARAM_RW_BUFFERS] = const_array(v16i8, 6); /* XXX hardcoded */
> + params[SI_PARAM_SAMPLER] = const_array(v4i32, NUM_SAMPLER_STATES);
> + params[SI_PARAM_RESOURCE] = const_array(v8i32, NUM_SAMPLER_VIEWS);
>  
>   switch (si_shader_ctx->type) {
>   case TGSI_PROCESSOR_VERTEX:
> - params[SI_PARAM_VERTEX_BUFFER] = params[SI_PARAM_CONST];
> + params[SI_PARAM_VERTEX_BUFFER] = const_array(v16i8, 16); /* XXX 
> hardcoded */
>   params[SI_PARAM_START_INSTANCE] = i32;
>   num_params = SI_PARAM_START_INSTANCE+1;
>   if (shader->key.vs.as_es) {
> -- 
> 1.9.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeonsi: rename definitions of shader limits

[Tom Stellard]

On Tue, Jul 08, 2014 at 01:37:03AM +0200, Marek Olšák wrote:
> From: Marek Olšák 

Reviewed-by: Tom Stellard 

> 
> ---
>  src/gallium/drivers/radeonsi/si_blit.c|  2 +-
>  src/gallium/drivers/radeonsi/si_descriptors.c | 12 +-
>  src/gallium/drivers/radeonsi/si_pipe.c|  6 ++---
>  src/gallium/drivers/radeonsi/si_pipe.h|  4 +---
>  src/gallium/drivers/radeonsi/si_shader.c  | 34 
> +--
>  src/gallium/drivers/radeonsi/si_state.c   | 12 +-
>  src/gallium/drivers/radeonsi/si_state.h   | 31 +---
>  7 files changed, 57 insertions(+), 44 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
> b/src/gallium/drivers/radeonsi/si_blit.c
> index 8c3e136..072024a 100644
> --- a/src/gallium/drivers/radeonsi/si_blit.c
> +++ b/src/gallium/drivers/radeonsi/si_blit.c
> @@ -76,7 +76,7 @@ static void si_blitter_begin(struct pipe_context *ctx, enum 
> si_blitter_op op)
>  
>   util_blitter_save_fragment_sampler_views(sctx->blitter,
>   
> util_last_bit(sctx->samplers[PIPE_SHADER_FRAGMENT].views.desc.enabled_mask &
> -   ((1 << NUM_TEX_UNITS) - 1)),
> +   ((1 << SI_NUM_USER_SAMPLERS) - 1)),
>   sctx->samplers[PIPE_SHADER_FRAGMENT].views.views);
>   }
>  
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 38ad077..6ae9b82 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -289,7 +289,7 @@ static void si_init_sampler_views(struct si_context *sctx,
>   si_init_descriptors(sctx, &views->desc,
>   si_get_shader_user_data_base(shader) +
>   SI_SGPR_RESOURCE * 4,
> - 8, NUM_SAMPLER_VIEWS, si_emit_sampler_views);
> + 8, SI_NUM_SAMPLER_VIEWS, si_emit_sampler_views);
>  }
>  
>  static void si_release_sampler_views(struct si_sampler_views *views)
> @@ -643,7 +643,7 @@ static void si_set_streamout_targets(struct pipe_context 
> *ctx,
>  
>   /* Set the shader resources.*/
>   for (i = 0; i < num_targets; i++) {
> - bufidx = SI_RW_SO + i;
> + bufidx = SI_SO_BUF_OFFSET + i;
>  
>   if (targets[i]) {
>   struct pipe_resource *buffer = targets[i]->buffer;
> @@ -677,7 +677,7 @@ static void si_set_streamout_targets(struct pipe_context 
> *ctx,
>   buffers->desc.dirty_mask |= 1 << bufidx;
>   }
>   for (; i < old_num_targets; i++) {
> - bufidx = SI_RW_SO + i;
> + bufidx = SI_SO_BUF_OFFSET + i;
>   /* Clear the descriptor and unset the resource. */
>   memset(buffers->desc_data[bufidx], 0, sizeof(uint32_t) * 4);
>   pipe_resource_reference(&buffers->buffers[bufidx], NULL);
> @@ -755,7 +755,7 @@ static void si_invalidate_buffer(struct pipe_context 
> *ctx, struct pipe_resource
>   buffers->desc.dirty_mask |= 1 << i;
>   found = true;
>  
> - if (i >= SI_RW_SO && shader == 
> PIPE_SHADER_VERTEX) {
> + if (i >= SI_SO_BUF_OFFSET && shader == 
> PIPE_SHADER_VERTEX) {
>   /* Update the streamout state. */
>   if (sctx->b.streamout.begin_emitted) {
>   
> r600_emit_streamout_end(&sctx->b);
> @@ -977,11 +977,11 @@ void si_init_all_descriptors(struct si_context *sctx)
>  
>   for (i = 0; i < SI_NUM_SHADERS; i++) {
>   si_init_buffer_resources(sctx, &sctx->const_buffers[i],
> -  NUM_CONST_BUFFERS, i, SI_SGPR_CONST,
> +  SI_NUM_CONST_BUFFERS, i, SI_SGPR_CONST,
>RADEON_USAGE_READ, 
> RADEON_PRIO_SHADER_BUFFER_RO);
>   si_init_buffer_resources(sctx, &sctx->rw_buffers[i],
>i == PIPE_SHADER_VERTEX ?
> -  SI_RW_SO + 4 : SI_RW_SO,
> +  SI_NUM_RW_BUFFERS : 
> SI_NUM_RING_BUFFERS,
>i, SI_SGPR_RW_BUFFERS,
>RADEON_USAGE_READWRITE, 
> RADEON_PRIO_SHADER_RESOURCE_RW);
>  
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 184235d..0f99e44 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -146,7 +146,7 @@ static struct pipe_context *si_create_context(struct 
> pipe_screen *screen, void *
>   sctx->null_const_buf.buffer_size = 
> sctx->null_const_buf.buffer->width0;
>  
>   for (shader = 

[Mesa-dev] [Bug 80183] [llvmpipe] triangles with vertices that map to raster positions > viewport width/height are not displayed

[bugzilla-daemon]

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

--- Comment #4 from Florian Link  ---
Sorry, that was a typo, of course it is in the vertex shader.

-- 
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

Re: [Mesa-dev] [PATCH] r600g/compute: Try to use a temporary resource when growing the pool

[Tom Stellard]

On Mon, Jul 07, 2014 at 05:50:05PM +0200, Bruno Jiménez wrote:
> Now, before moving everything to host memory, we try to create a
> new resource to use as a pool. I we succeed we just use this resource
> and delete the previous one. If we fail we fallback to using the
> shadow.
> 
> This should make growing the pool faster, and we can also save
> 64KB of memory that were allocated for the 'shadow', even if they
> weren't used.

Reviewed-by: Tom Stellard 

> ---
>  src/gallium/drivers/r600/compute_memory_pool.c | 61 
> ++
>  1 file changed, 43 insertions(+), 18 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
> b/src/gallium/drivers/r600/compute_memory_pool.c
> index fe19d9e..db6d937 100644
> --- a/src/gallium/drivers/r600/compute_memory_pool.c
> +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> @@ -73,10 +73,6 @@ static void compute_memory_pool_init(struct 
> compute_memory_pool * pool,
>   COMPUTE_DBG(pool->screen, "* compute_memory_pool_init() 
> initial_size_in_dw = %ld\n",
>   initial_size_in_dw);
>  
> - pool->shadow = (uint32_t*)CALLOC(initial_size_in_dw, 4);
> - if (pool->shadow == NULL)
> - return;
> -
>   pool->size_in_dw = initial_size_in_dw;
>   pool->bo = (struct 
> r600_resource*)r600_compute_buffer_alloc_vram(pool->screen,
>   pool->size_in_dw * 4);
> @@ -184,27 +180,56 @@ int compute_memory_grow_pool(struct 
> compute_memory_pool* pool,
>  
>   if (!pool->bo) {
>   compute_memory_pool_init(pool, MAX2(new_size_in_dw, 1024 * 16));
> - if (pool->shadow == NULL)
> - return -1;
>   } else {
> + struct r600_resource *temp = NULL;
> +
>   new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
>  
>   COMPUTE_DBG(pool->screen, "  Aligned size = %d (%d bytes)\n",
>   new_size_in_dw, new_size_in_dw * 4);
>  
> - compute_memory_shadow(pool, pipe, 1);
> - pool->shadow = realloc(pool->shadow, new_size_in_dw*4);
> - if (pool->shadow == NULL)
> - return -1;
> + temp = (struct r600_resource *)r600_compute_buffer_alloc_vram(
> + pool->screen, 
> new_size_in_dw * 4);
>  
> - pool->size_in_dw = new_size_in_dw;
> - pool->screen->b.b.resource_destroy(
> - (struct pipe_screen *)pool->screen,
> - (struct pipe_resource *)pool->bo);
> - pool->bo = (struct 
> r600_resource*)r600_compute_buffer_alloc_vram(
> - pool->screen,
> - pool->size_in_dw * 4);
> - compute_memory_shadow(pool, pipe, 0);
> + if (temp != NULL) {
> + struct r600_context *rctx = (struct r600_context *)pipe;
> + struct pipe_resource *src = (struct pipe_resource 
> *)pool->bo;
> + struct pipe_resource *dst = (struct pipe_resource 
> *)temp;
> + struct pipe_box box;
> +
> + COMPUTE_DBG(pool->screen, "  Growing the pool using a 
> temporary resource\n");
> +
> + u_box_1d(0, pool->size_in_dw * 4, &box);
> +
> + rctx->b.b.resource_copy_region(pipe,
> + dst, 0, 0, 0 ,0,
> + src, 0, &box);
> +
> + pool->screen->b.b.resource_destroy(
> + (struct pipe_screen *)pool->screen,
> + src);
> +
> + pool->bo = temp;
> + pool->size_in_dw = new_size_in_dw;
> + }
> + else {
> + COMPUTE_DBG(pool->screen, "  The creation of the 
> temporary resource failed\n"
> + "  Falling back to using 'shadow'\n");
> +
> + compute_memory_shadow(pool, pipe, 1);
> + pool->shadow = realloc(pool->shadow, new_size_in_dw * 
> 4);
> + if (pool->shadow == NULL)
> + return -1;
> +
> + pool->size_in_dw = new_size_in_dw;
> + pool->screen->b.b.resource_destroy(
> + (struct pipe_screen *)pool->screen,
> + (struct pipe_resource *)pool->bo);
> + pool->bo = (struct 
> r600_resource*)r600_compute_buffer_alloc_vram(
> + pool->screen,
> + pool->size_in_dw * 4);
> + compute_memory_shadow(pool, pipe, 0);
> + }
>   }
>  
>   return 0;
> -- 
> 2.0.1
> 
> _

[Mesa-dev] [PATCH 1/2] softpipe: fix sp_get_dims() for PIPE_BUFFER

[Brian Paul]

Before, we were checking the level against view->u.tex.last_level but
level is not valid for buffers.  Plus, the aliasing of the view->u.tex
view->u.buf members (a union) caused the level checking arithmetic to
be totally wrong.  The net effect is we always returned early for
PIPE_BUFFER size queries.

This fixes the piglit "textureSize 140 fs samplerBuffer" test.
---
 src/gallium/drivers/softpipe/sp_tex_sample.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c 
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 8565a01..2d59766 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2907,14 +2907,21 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int level,
const struct pipe_sampler_view *view = &sp_sview->base;
const struct pipe_resource *texture = view->texture;
 
+   if (texture->target == PIPE_BUFFER) {
+  dims[0] = (view->u.buf.last_element - view->u.buf.first_element) + 1;
+  /* the other values are undefined, but let's avoid potential valgrind
+   * warnings.
+   */
+  dims[1] = dims[2] = dims[3] = 0;
+  return;
+   }
+
/* undefined according to EXT_gpu_program */
level += view->u.tex.first_level;
if (level > view->u.tex.last_level)
   return;
 
-   if (texture->target != PIPE_BUFFER)
-  dims[3] = view->u.tex.last_level - view->u.tex.first_level + 1;
-
+   dims[3] = view->u.tex.last_level - view->u.tex.first_level + 1;
dims[0] = u_minify(texture->width0, level);
 
switch(texture->target) {
@@ -2939,9 +2946,6 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int level,
   dims[1] = u_minify(texture->height0, level);
   dims[2] = (view->u.tex.last_layer - view->u.tex.first_layer + 1) / 6;
   break;
-   case PIPE_BUFFER:
-  dims[0] /= util_format_get_blocksize(view->format);
-  return;
default:
   assert(!"unexpected texture target in sp_get_dims()");
   return;
-- 
1.7.10.4

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

[Mesa-dev] [PATCH 2/2] gallium/docs: minor clarification for TXQ instruction

[Brian Paul]

---
 src/gallium/docs/source/tgsi.rst |2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 8cbb3d8..c267b2c 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -968,6 +968,8 @@ XXX doesn't look like most of the opcodes really belong 
here.
   Also return the number of accessible levels (last_level - first_level + 1)
   in W.
 
+  For components that aren't used, the returned values are undefined.
+
 .. math::
 
   lod = src0.x
-- 
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 2/2] gallium/docs: minor clarification for TXQ instruction

[Ilia Mirkin]

On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul  wrote:
> ---
>  src/gallium/docs/source/tgsi.rst |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index 8cbb3d8..c267b2c 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -968,6 +968,8 @@ XXX doesn't look like most of the opcodes really belong 
> here.
>Also return the number of accessible levels (last_level - first_level + 1)
>in W.
>
> +  For components that aren't used, the returned values are undefined.
> +

Perhaps I'm just not seeing something obvious... but what does this
mean? I'm reading this as "If you don't look at a component of the
return value, then unbeknownst to you, since you're not looking at it,
the value is undefined."

>  .. math::
>
>lod = src0.x
> --
> 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 2/2] gallium/docs: minor clarification for TXQ instruction

[Ilia Mirkin]

On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin  wrote:
> On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul  wrote:
>> ---
>>  src/gallium/docs/source/tgsi.rst |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/gallium/docs/source/tgsi.rst 
>> b/src/gallium/docs/source/tgsi.rst
>> index 8cbb3d8..c267b2c 100644
>> --- a/src/gallium/docs/source/tgsi.rst
>> +++ b/src/gallium/docs/source/tgsi.rst
>> @@ -968,6 +968,8 @@ XXX doesn't look like most of the opcodes really belong 
>> here.
>>Also return the number of accessible levels (last_level - first_level + 1)
>>in W.
>>
>> +  For components that aren't used, the returned values are undefined.
>> +
>
> Perhaps I'm just not seeing something obvious... but what does this
> mean? I'm reading this as "If you don't look at a component of the
> return value, then unbeknownst to you, since you're not looking at it,
> the value is undefined."

Oh. I just got what you were saying. Perhaps phrase this as

"For non-existent dimensions, the returned values are undefined"?

>
>>  .. math::
>>
>>lod = src0.x
>> --
>> 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

[Mesa-dev] [PATCH] glsl: Fix aggregates with dynamic initializers.

[Cody Northrop]

Vectors are falling in to the ir_dereference_array() path.

Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:

mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );

Also submitting piglit tests, will reference in bug.

v2: Rebase on Mesa master.

v3: Remove unneeded check for arrays, which are covered by
process_array_constructor(), recommended by Timothy Arceri.

Signed-off-by: Cody Northrop 
Reviewed-by: Courtney Goeltzenleuchter 
Reviewed-by: Kenneth Graunke 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79373
---
 src/glsl/ast_function.cpp | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index cdb34cc..c019b83 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -742,11 +742,22 @@ process_vec_mat_constructor(exec_list *instructions,
instructions->push_tail(var);
 
int i = 0;
+
foreach_in_list(ir_rvalue, rhs, &actual_parameters) {
-  ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
- new(ctx) ir_constant(i));
+  ir_instruction *assignment = NULL;
+
+  if (var->type->is_matrix()) {
+ ir_rvalue *lhs = new(ctx) ir_dereference_array(var,
+ new(ctx) ir_constant(i));
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
+  } else {
+ /* use writemask rather than index for vector */
+ assert(var->type->is_vector());
+ assert(i < 4);
+ ir_dereference *lhs = new(ctx) ir_dereference_variable(var);
+ assignment = new(ctx) ir_assignment(lhs, rhs, NULL, (unsigned)(1 << 
i));
+  }
 
-  ir_instruction *assignment = new(ctx) ir_assignment(lhs, rhs, NULL);
   instructions->push_tail(assignment);
 
   i++;
-- 
1.9.1

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

[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

Benjamin Bellec  changed:

   What|Removed |Added

 CC||b.bel...@gmail.com

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

Re: [Mesa-dev] [PATCH 1/2] softpipe: fix sp_get_dims() for PIPE_BUFFER

[Roland Scheidegger]

Am 10.07.2014 17:43, schrieb Brian Paul:
> Before, we were checking the level against view->u.tex.last_level but
> level is not valid for buffers.  Plus, the aliasing of the view->u.tex
> view->u.buf members (a union) caused the level checking arithmetic to
> be totally wrong.  The net effect is we always returned early for
> PIPE_BUFFER size queries.
> 
> This fixes the piglit "textureSize 140 fs samplerBuffer" test.
> ---
>  src/gallium/drivers/softpipe/sp_tex_sample.c |   16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c 
> b/src/gallium/drivers/softpipe/sp_tex_sample.c
> index 8565a01..2d59766 100644
> --- a/src/gallium/drivers/softpipe/sp_tex_sample.c
> +++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
> @@ -2907,14 +2907,21 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int 
> level,
> const struct pipe_sampler_view *view = &sp_sview->base;
> const struct pipe_resource *texture = view->texture;
>  
> +   if (texture->target == PIPE_BUFFER) {
> +  dims[0] = (view->u.buf.last_element - view->u.buf.first_element) + 1;
> +  /* the other values are undefined, but let's avoid potential valgrind
> +   * warnings.
> +   */
> +  dims[1] = dims[2] = dims[3] = 0;
> +  return;
> +   }
> +
> /* undefined according to EXT_gpu_program */
> level += view->u.tex.first_level;
> if (level > view->u.tex.last_level)
>return;
>  
> -   if (texture->target != PIPE_BUFFER)
> -  dims[3] = view->u.tex.last_level - view->u.tex.first_level + 1;
> -
> +   dims[3] = view->u.tex.last_level - view->u.tex.first_level + 1;
> dims[0] = u_minify(texture->width0, level);
>  
> switch(texture->target) {
> @@ -2939,9 +2946,6 @@ sp_get_dims(struct sp_sampler_view *sp_sview, int level,
>dims[1] = u_minify(texture->height0, level);
>dims[2] = (view->u.tex.last_layer - view->u.tex.first_layer + 1) / 6;
>break;
> -   case PIPE_BUFFER:
> -  dims[0] /= util_format_get_blocksize(view->format);
> -  return;
> default:
>assert(!"unexpected texture target in sp_get_dims()");
>return;
> 

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

Re: [Mesa-dev] [PATCH 2/2] gallium/docs: minor clarification for TXQ instruction

[Brian Paul]

On 07/10/2014 09:50 AM, Ilia Mirkin wrote:

On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin  wrote:

On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul  wrote:

---
  src/gallium/docs/source/tgsi.rst |2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 8cbb3d8..c267b2c 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -968,6 +968,8 @@ XXX doesn't look like most of the opcodes really belong 
here.
Also return the number of accessible levels (last_level - first_level + 1)
in W.

+  For components that aren't used, the returned values are undefined.
+


Perhaps I'm just not seeing something obvious... but what does this
mean? I'm reading this as "If you don't look at a component of the
return value, then unbeknownst to you, since you're not looking at it,
the value is undefined."


Oh. I just got what you were saying. Perhaps phrase this as

"For non-existent dimensions, the returned values are undefined"?


How about, "For components which don't return a resource dimension, 
their value is undefined." ?


-Brian

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

Re: [Mesa-dev] [PATCH 2/2] gallium/docs: minor clarification for TXQ instruction

[Ilia Mirkin]

On Thu, Jul 10, 2014 at 1:13 PM, Brian Paul  wrote:
> On 07/10/2014 09:50 AM, Ilia Mirkin wrote:
>>
>> On Thu, Jul 10, 2014 at 11:46 AM, Ilia Mirkin 
>> wrote:
>>>
>>> On Thu, Jul 10, 2014 at 11:43 AM, Brian Paul  wrote:

 ---
   src/gallium/docs/source/tgsi.rst |2 ++
   1 file changed, 2 insertions(+)

 diff --git a/src/gallium/docs/source/tgsi.rst
 b/src/gallium/docs/source/tgsi.rst
 index 8cbb3d8..c267b2c 100644
 --- a/src/gallium/docs/source/tgsi.rst
 +++ b/src/gallium/docs/source/tgsi.rst
 @@ -968,6 +968,8 @@ XXX doesn't look like most of the opcodes really
 belong here.
 Also return the number of accessible levels (last_level -
 first_level + 1)
 in W.

 +  For components that aren't used, the returned values are undefined.
 +
>>>
>>>
>>> Perhaps I'm just not seeing something obvious... but what does this
>>> mean? I'm reading this as "If you don't look at a component of the
>>> return value, then unbeknownst to you, since you're not looking at it,
>>> the value is undefined."
>>
>>
>> Oh. I just got what you were saying. Perhaps phrase this as
>>
>> "For non-existent dimensions, the returned values are undefined"?
>
>
> How about, "For components which don't return a resource dimension, their
> value is undefined." ?

Makes sense to me.

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

Re: [Mesa-dev] [PATCH 1/5] configure.ac: require LLVM 3.4.2 for radeon

[Marek Olšák]

Yes, that sounds good. We should always support the latest stable
version of LLVM, but I don't think it's worth supporting anything
older than that.

It's also important to have the latest LLVM because it's sometimes the
only way to get the new features which are mentioned in the release
notes of Mesa. Older LLVM usually causes the driver not to advertise
all features despite what the release notes say.

Marek

On Thu, Jul 10, 2014 at 5:10 PM, Tom Stellard  wrote:
> On Tue, Jul 08, 2014 at 03:37:02AM +0200, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> Needed by ARB_draw_indirect.
>
> I think we should come up with a rule for how long we should support
> older versions of LLVM.  Do you have any thoughts about this?  I was
> thinking we could have each Mesa release support current stable LLVM
> and also the development version from SVN.
>
> -Tom
>
>> ---
>>  configure.ac | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 4646212..9d5cd89 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1888,8 +1888,9 @@ radeon_llvm_check() {
>>  AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
>>  fi
>>  LLVM_REQUIRED_VERSION_MAJOR="3"
>> -LLVM_REQUIRED_VERSION_MINOR="3"
>> -if test "$LLVM_VERSION_INT" -lt 
>> "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}"; then
>> +LLVM_REQUIRED_VERSION_MINOR="4"
>> +LLVM_REQUIRED_VERSION_PATCH="2"
>> +if test "${LLVM_VERSION_INT}${LLVM_VERSION_PATCH}" -lt 
>> "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}${LLVM_REQUIRED_VERSION_PATCH}";
>>  then
>>  AC_MSG_ERROR([LLVM 
>> $LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is 
>> required for $1])
>>  fi
>>  if test true && $LLVM_CONFIG --targets-built | grep -qvw 'R600' ; then
>> --
>> 1.9.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] glsl: Add callback_leave to ir_hierarchical_visitor.

[Matt Turner]

---
 src/glsl/ir_hierarchical_visitor.cpp | 158 +--
 src/glsl/ir_hierarchical_visitor.h   |  29 +--
 src/glsl/ir_validate.cpp |  12 +--
 3 files changed, 126 insertions(+), 73 deletions(-)

diff --git a/src/glsl/ir_hierarchical_visitor.cpp 
b/src/glsl/ir_hierarchical_visitor.cpp
index d3c00ec..adb6294 100644
--- a/src/glsl/ir_hierarchical_visitor.cpp
+++ b/src/glsl/ir_hierarchical_visitor.cpp
@@ -27,16 +27,18 @@
 ir_hierarchical_visitor::ir_hierarchical_visitor()
 {
this->base_ir = NULL;
-   this->callback = NULL;
-   this->data = NULL;
+   this->callback_enter = NULL;
+   this->callback_leave = NULL;
+   this->data_enter = NULL;
+   this->data_leave = NULL;
this->in_assignee = false;
 }
 
 ir_visitor_status
 ir_hierarchical_visitor::visit(ir_rvalue *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -44,8 +46,8 @@ ir_hierarchical_visitor::visit(ir_rvalue *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit(ir_variable *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -53,8 +55,8 @@ ir_hierarchical_visitor::visit(ir_variable *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit(ir_constant *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -62,8 +64,8 @@ ir_hierarchical_visitor::visit(ir_constant *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit(ir_loop_jump *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -71,8 +73,8 @@ ir_hierarchical_visitor::visit(ir_loop_jump *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit(ir_dereference_variable *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -80,8 +82,8 @@ ir_hierarchical_visitor::visit(ir_dereference_variable *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit_enter(ir_loop *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -89,15 +91,17 @@ ir_hierarchical_visitor::visit_enter(ir_loop *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit_leave(ir_loop *ir)
 {
-   (void) ir;
+   if (this->callback_leave != NULL)
+  this->callback_leave(ir, this->data_leave);
+
return visit_continue;
 }
 
 ir_visitor_status
 ir_hierarchical_visitor::visit_enter(ir_function_signature *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -105,15 +109,17 @@ 
ir_hierarchical_visitor::visit_enter(ir_function_signature *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit_leave(ir_function_signature *ir)
 {
-   (void) ir;
+   if (this->callback_leave != NULL)
+  this->callback_leave(ir, this->data_leave);
+
return visit_continue;
 }
 
 ir_visitor_status
 ir_hierarchical_visitor::visit_enter(ir_function *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -121,15 +127,17 @@ ir_hierarchical_visitor::visit_enter(ir_function *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit_leave(ir_function *ir)
 {
-   (void) ir;
+   if (this->callback_leave != NULL)
+  this->callback_leave(ir, this->data_leave);
+
return visit_continue;
 }
 
 ir_visitor_status
 ir_hierarchical_visitor::visit_enter(ir_expression *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -137,15 +145,17 @@ ir_hierarchical_visitor::visit_enter(ir_expression *ir)
 ir_visitor_status
 ir_hierarchical_visitor::visit_leave(ir_expression *ir)
 {
-   (void) ir;
+   if (this->callback_leave != NULL)
+  this->callback_leave(ir, this->data_leave);
+
return visit_continue;
 }
 
 ir_visitor_status
 ir_hierarchical_visitor::visit_enter(ir_texture *ir)
 {
-   if (this->callback != NULL)
-  this->callback(ir, this->data);
+   if (this->callback_enter != NULL)
+  this->callback_enter(ir, this->data_enter);
 
return visit_continue;
 }
@@ -153,15 +163,17 @@ ir_hierarchical_visitor:

[Mesa-dev] [PATCH 2/2] glsl: Update expression types after rebalancing the tree.

[Matt Turner]

If we saw a tree that looked like

vec3
   /   \
 vec3 float
/   \
  vec3 float
 /   \
   vec3 float

We would see that all of the expression types were vec3, and then
rebalance to

   vec3
/\
  vec3   vec3 <-- should be float
 /   \  /\
   vec3 float float float

This patch adds code to visit the rebalanced tree and update the
expression types from the bottom up.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80880
---
 src/glsl/opt_rebalance_tree.cpp | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/glsl/opt_rebalance_tree.cpp b/src/glsl/opt_rebalance_tree.cpp
index 773aab3..daabdc9 100644
--- a/src/glsl/opt_rebalance_tree.cpp
+++ b/src/glsl/opt_rebalance_tree.cpp
@@ -60,6 +60,7 @@
 #include "ir_visitor.h"
 #include "ir_rvalue_visitor.h"
 #include "ir_optimization.h"
+#include "main/macros.h" /* for MAX2 */
 
 /* The DSW algorithm generates a degenerate tree (really, a linked list) in
  * tree_to_vine(). We'd rather not leave a binary expression with only one
@@ -261,6 +262,20 @@ handle_expression(ir_expression *expr)
return expr;
 }
 
+static void
+update_types(ir_instruction *ir, void *)
+{
+   ir_expression *expr = ir->as_expression();
+   if (!expr)
+  return;
+
+   expr->type =
+  glsl_type::get_instance(expr->type->base_type,
+  MAX2(expr->operands[0]->type->components(),
+   expr->operands[1]->type->components()),
+  1);
+}
+
 void
 ir_rebalance_visitor::handle_rvalue(ir_rvalue **rvalue)
 {
@@ -285,6 +300,8 @@ ir_rebalance_visitor::handle_rvalue(ir_rvalue **rvalue)
if (new_rvalue == *rvalue)
   return;
 
+   visit_tree(new_rvalue, NULL, NULL, update_types);
+
*rvalue = new_rvalue;
this->progress = true;
 }
-- 
1.8.5.5

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

[Mesa-dev] [PATCH] i965/fs: Perform CSE on sends-from-GRF rather than textures.

[Matt Turner]

Should potentially allow a few more cases, while avoiding doing CSE on
texture operations on Gen <= 6 with the MRF.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80211
---
 src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index 5727801..7226aff 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -103,7 +103,7 @@ is_expression(const fs_inst *const inst)
case SHADER_OPCODE_LOAD_PAYLOAD:
   return !is_copy_payload(inst);
default:
-  return inst->is_tex();
+  return inst->is_send_from_grf();
}
 }
 
-- 
1.8.5.5

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

[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

--- Comment #2 from Benjamin Bellec  ---
Is that a regression ?

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

[Mesa-dev] [Bug 78716] Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux

[bugzilla-daemon]

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

--- Comment #9 from oscar garcia  ---
Hi, seems now on unreal wiki there is a page with most content
demos compiled using some form of 4.3 preview so should have bugs fixed
querying tess info etc.. So now you can try to fix it, right?

El miércoles, 28 de mayo de 2014, 
escribió:

>  darkbasic  changed
> bug 78716 
>  What Removed Added  CC   darkba...@linuxsystems.it
> 
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
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] r600g/compute: Add debug information to promote and demote functions

[Bruno Jiménez]

---
 src/gallium/drivers/r600/compute_memory_pool.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1d0ec85..6d47b1a 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -339,6 +339,8 @@ int compute_memory_promote_item(struct compute_memory_pool 
*pool,
int64_t start_in_dw;
int err = 0;
 
+   COMPUTE_DBG(pool->screen, "* compute_memory_promote_item()\n"
+   "  + Promoting Item: %i\n", item->id);
 
/* Search for free space in the pool for this item. */
while ((start_in_dw=compute_memory_prealloc_chunk(pool,
@@ -409,6 +411,9 @@ void compute_memory_demote_item(struct compute_memory_pool 
*pool,
struct pipe_resource *dst;
struct pipe_box box;
 
+   COMPUTE_DBG(pool->screen, "* compute_memory_demote_item()\n"
+   "  + Demoting Item: %i\n", item->id);
+
/* First, we remove the item from the item_list */
list_del(&item->link);
 
-- 
2.0.1

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

[Mesa-dev] [PATCH 1/2] r600g/compute: Add documentation to compute_memory_pool

[Bruno Jiménez]

---
 src/gallium/drivers/r600/compute_memory_pool.c | 54 
 src/gallium/drivers/r600/compute_memory_pool.h | 58 --
 2 files changed, 83 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/r600/compute_memory_pool.c 
b/src/gallium/drivers/r600/compute_memory_pool.c
index fe19d9e..1d0ec85 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -44,7 +44,7 @@
 
 #define ITEM_ALIGNMENT 1024
 /**
- * Creates a new pool
+ * Creates a new pool.
  */
 struct compute_memory_pool* compute_memory_pool_new(
struct r600_screen * rscreen)
@@ -66,6 +66,12 @@ struct compute_memory_pool* compute_memory_pool_new(
return pool;
 }
 
+/**
+ * Initializes the pool with a size of \a initial_size_in_dw.
+ * \param pool The pool to be initialized.
+ * \param initial_size_in_dw   The initial size.
+ * \see compute_memory_grow_pool
+ */
 static void compute_memory_pool_init(struct compute_memory_pool * pool,
unsigned initial_size_in_dw)
 {
@@ -83,7 +89,7 @@ static void compute_memory_pool_init(struct 
compute_memory_pool * pool,
 }
 
 /**
- * Frees all stuff in the pool and the pool struct itself too
+ * Frees all stuff in the pool and the pool struct itself too.
  */
 void compute_memory_pool_delete(struct compute_memory_pool* pool)
 {
@@ -98,7 +104,10 @@ void compute_memory_pool_delete(struct compute_memory_pool* 
pool)
 
 /**
  * Searches for an empty space in the pool, return with the pointer to the
- * allocatable space in the pool, returns -1 on failure.
+ * allocatable space in the pool.
+ * \param size_in_dw   The size of the space we are looking for.
+ * \return -1 on failure
+ * \see compute_memory_promote_item
  */
 int64_t compute_memory_prealloc_chunk(
struct compute_memory_pool* pool,
@@ -130,6 +139,9 @@ int64_t compute_memory_prealloc_chunk(
 
 /**
  *  Search for the chunk where we can link our new chunk after it.
+ *  \param start_in_dw The position of the item we want to add to the pool.
+ *  \return The item that is just before the passed position
+ *  \see compute_memory_promote_item
  */
 struct list_head *compute_memory_postalloc_chunk(
struct compute_memory_pool* pool,
@@ -171,7 +183,8 @@ struct list_head *compute_memory_postalloc_chunk(
 
 /**
  * Reallocates pool, conserves data.
- * @returns -1 if it fails, 0 otherwise
+ * \returns -1 if it fails, 0 otherwise
+ * \see compute_memory_finalize_pending and compute_memory_promote_item
  */
 int compute_memory_grow_pool(struct compute_memory_pool* pool,
struct pipe_context * pipe, int new_size_in_dw)
@@ -212,6 +225,8 @@ int compute_memory_grow_pool(struct compute_memory_pool* 
pool,
 
 /**
  * Copy pool from device to host, or host to device.
+ * \param device_to_host 1 for device->host, 0 for host->device
+ * \see compute_memory_grow_pool
  */
 void compute_memory_shadow(struct compute_memory_pool* pool,
struct pipe_context * pipe, int device_to_host)
@@ -229,8 +244,10 @@ void compute_memory_shadow(struct compute_memory_pool* 
pool,
 }
 
 /**
- * Allocates pending allocations in the pool
- * @returns -1 if it fails, 0 otherwise
+ * Moves all the items marked for promotion from the \a unallocated_list
+ * to the \a item_list.
+ * \return -1 if it fails, 0 otherwise
+ * \see evergreen_set_global_binding
  */
 int compute_memory_finalize_pending(struct compute_memory_pool* pool,
struct pipe_context * pipe)
@@ -302,6 +319,12 @@ int compute_memory_finalize_pending(struct 
compute_memory_pool* pool,
return 0;
 }
 
+/**
+ * Moves an item from the \a unallocated_list to the \a item_list.
+ * \param item The item that will be promoted.
+ * \return -1 if it fails, 0 otherwise
+ * \see compute_memory_finalize_pending
+ */
 int compute_memory_promote_item(struct compute_memory_pool *pool,
struct compute_memory_item *item, struct pipe_context *pipe,
int64_t allocated)
@@ -373,6 +396,11 @@ int compute_memory_promote_item(struct compute_memory_pool 
*pool,
return 0;
 }
 
+/**
+ * Moves an item from the \a item_list to the \a unallocated_list.
+ * \param item The item that will be demoted
+ * \see r600_compute_global_transfer_map
+ */
 void compute_memory_demote_item(struct compute_memory_pool *pool,
struct compute_memory_item *item, struct pipe_context *pipe)
 {
@@ -408,6 +436,10 @@ void compute_memory_demote_item(struct compute_memory_pool 
*pool,
item->start_in_dw = -1;
 }
 
+/**
+ * Frees the memory asociated to the item with id \a id from the pool.
+ * \param id   The id of the item to be freed.
+ */
 void compute_memory_free(struct compute_memory_pool* pool, int64_t id)
 {
struct compute_memory_item *item, *next;
@@ -457,7 +489,11 @@ void compute_memory_free(struct compute_memory_pool* pool, 
int64_t id)
 }
 
 /**
- * Creates pending allocations
+ * Creates pending allocations for new items, these items 

[Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[thomashelland90]

From: Thomas Helland 

Let's cut the needless A && B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.

helped: shaders/tf2/2042.shader_test fs16:23 -> 21
(-8.70%)
helped: shaders/tf2/2042.shader_test fs8: 23 -> 21
(-8.70%)
helped: shaders/tf2/4624.shader_test fs16:21 -> 19
(-9.52%)
helped: shaders/tf2/4624.shader_test fs8: 21 -> 19
(-9.52%)
helped: shaders/tf2/763.shader_test fs16: 23 -> 21
(-8.70%)
helped: shaders/tf2/763.shader_test fs8:  23 -> 21
(-8.70%)

HURT:   shaders/orbital_explorer.shader_test vs:  1049 -> 1052
(0.29%)

total instructions in shared programs: 758979 -> 758970 (-0.00%)
instructions in affected programs: 1183 -> 1174 (-0.76%)
GAINED:0
LOST:  0

Signed-off-by: Thomas Helland 
---
 src/glsl/opt_algebraic.cpp | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index ac7514a..8f3a505 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -588,6 +588,16 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   } else if (ir->operands[0]->equals(ir->operands[1])) {
  /* (a || a) == a */
  return ir->operands[0];
+  } else if (op_expr[0] && op_expr[0]->operation == ir_binop_logic_and &&
+(op_expr[0]->operands[0]->equals(op_expr[1]) || 
+ op_expr[0]->operands[1]->equals(op_expr[1]))) {
+ /* A || (A && B)  or A || (B && A) */
+ return ir->operands[0];
+  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_and &&
+(op_expr[1]->operands[0]->equals(op_expr[0]) || 
+ op_expr[1]->operands[1]->equals(op_expr[0]))) {
+ /* (A && B) || A  or (B && A) || A */
+ return ir->operands[1];
   }
   break;
 
-- 
2.0.0

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

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Matt Turner]

On Thu, Jul 10, 2014 at 2:24 PM,   wrote:
> From: Thomas Helland 
>
> Let's cut the needless A && B here.
> Gives some effect on a clean shader-db with
> some extra shaders from TF2 and portal.

Nice. Thanks DX translators. :(

I'll run this on our collection of shaders too. I'll reply with some stats.

> helped: shaders/tf2/2042.shader_test fs16:23 -> 21
> (-8.70%)
> helped: shaders/tf2/2042.shader_test fs8: 23 -> 21
> (-8.70%)
> helped: shaders/tf2/4624.shader_test fs16:21 -> 19
> (-9.52%)
> helped: shaders/tf2/4624.shader_test fs8: 21 -> 19
> (-9.52%)
> helped: shaders/tf2/763.shader_test fs16: 23 -> 21
> (-8.70%)
> helped: shaders/tf2/763.shader_test fs8:  23 -> 21
> (-8.70%)
>
> HURT:   shaders/orbital_explorer.shader_test vs:  1049 -> 1052
> (0.29%)

There's something wrong with this shader. It seems to fluctuate
between 1048 and 1052 instructions for me, even without any changes.

>
> total instructions in shared programs: 758979 -> 758970 (-0.00%)
> instructions in affected programs: 1183 -> 1174 (-0.76%)
> GAINED:0
> LOST:  0
>
> Signed-off-by: Thomas Helland 
> ---
>  src/glsl/opt_algebraic.cpp | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index ac7514a..8f3a505 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -588,6 +588,16 @@ ir_algebraic_visitor::handle_expression(ir_expression 
> *ir)
>} else if (ir->operands[0]->equals(ir->operands[1])) {
>   /* (a || a) == a */
>   return ir->operands[0];
> +  } else if (op_expr[0] && op_expr[0]->operation == ir_binop_logic_and &&
> +(op_expr[0]->operands[0]->equals(op_expr[1]) ||
> + op_expr[0]->operands[1]->equals(op_expr[1]))) {
> + /* A || (A && B)  or A || (B && A) */
> + return ir->operands[0];
> +  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_and &&
> +(op_expr[1]->operands[0]->equals(op_expr[0]) ||
> + op_expr[1]->operands[1]->equals(op_expr[0]))) {
> + /* (A && B) || A  or (B && A) || A */
> + return ir->operands[1];

Looks good to me.

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: switch descriptors to i32 vectors

[Marek Olšák]

I have just tested it and it works with LLVM 3.4.2.

Marek

On Thu, Jul 10, 2014 at 5:11 PM, Tom Stellard  wrote:
> On Tue, Jul 08, 2014 at 01:37:02AM +0200, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> This is a follow-up to the commit which adds texture fetches with offsets.
>
> Will this still work with LLVM 3.4.2 ?
>
> -Tom
>
>> ---
>>  src/gallium/drivers/radeonsi/si_shader.c | 29 -
>>  1 file changed, 16 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
>> b/src/gallium/drivers/radeonsi/si_shader.c
>> index 3dd6ad1..a28d682 100644
>> --- a/src/gallium/drivers/radeonsi/si_shader.c
>> +++ b/src/gallium/drivers/radeonsi/si_shader.c
>> @@ -1574,7 +1574,7 @@ static void tex_fetch_args(
>>   LLVMTypeRef i8 = LLVMInt8TypeInContext(gallivm->context);
>>   LLVMTypeRef v16i8 = LLVMVectorType(i8, 16);
>>
>> - /* Truncate v32i8 to v16i8. */
>> + /* Bitcast and truncate v8i32 to v16i8. */
>>   LLVMValueRef res = si_shader_ctx->resources[sampler_index];
>>   res = LLVMBuildBitCast(gallivm->builder, res, v2i128, "");
>>   res = LLVMBuildExtractElement(gallivm->builder, res, 
>> bld_base->uint_bld.zero, "");
>> @@ -2305,12 +2305,18 @@ static void create_meta_data(struct 
>> si_shader_context *si_shader_ctx)
>>   si_shader_ctx->const_md = LLVMMDNodeInContext(gallivm->context, args, 
>> 3);
>>  }
>>
>> +static LLVMTypeRef const_array(LLVMTypeRef elem_type, int num_elements)
>> +{
>> + return LLVMPointerType(LLVMArrayType(elem_type, num_elements),
>> +CONST_ADDR_SPACE);
>> +}
>> +
>>  static void create_function(struct si_shader_context *si_shader_ctx)
>>  {
>>   struct lp_build_tgsi_context *bld_base = 
>> &si_shader_ctx->radeon_bld.soa.bld_base;
>>   struct gallivm_state *gallivm = bld_base->base.gallivm;
>>   struct si_pipe_shader *shader = si_shader_ctx->shader;
>> - LLVMTypeRef params[SI_NUM_PARAMS], f32, i8, i32, v2i32, v3i32;
>> + LLVMTypeRef params[SI_NUM_PARAMS], f32, i8, i32, v2i32, v3i32, v16i8, 
>> v4i32, v8i32;
>>   unsigned i, last_sgpr, num_params;
>>
>>   i8 = LLVMInt8TypeInContext(gallivm->context);
>> @@ -2318,21 +2324,18 @@ static void create_function(struct si_shader_context 
>> *si_shader_ctx)
>>   f32 = LLVMFloatTypeInContext(gallivm->context);
>>   v2i32 = LLVMVectorType(i32, 2);
>>   v3i32 = LLVMVectorType(i32, 3);
>> + v4i32 = LLVMVectorType(i32, 4);
>> + v8i32 = LLVMVectorType(i32, 8);
>> + v16i8 = LLVMVectorType(i8, 16);
>>
>> - params[SI_PARAM_CONST] = LLVMPointerType(
>> - LLVMArrayType(LLVMVectorType(i8, 16), NUM_CONST_BUFFERS), 
>> CONST_ADDR_SPACE);
>> - params[SI_PARAM_RW_BUFFERS] = params[SI_PARAM_CONST];
>> -
>> - /* We assume at most 16 textures per program at the moment.
>> -  * This need probably need to be changed to support bindless textures 
>> */
>> - params[SI_PARAM_SAMPLER] = LLVMPointerType(
>> - LLVMArrayType(LLVMVectorType(i8, 16), NUM_SAMPLER_STATES), 
>> CONST_ADDR_SPACE);
>> - params[SI_PARAM_RESOURCE] = LLVMPointerType(
>> - LLVMArrayType(LLVMVectorType(i8, 32), NUM_SAMPLER_VIEWS), 
>> CONST_ADDR_SPACE);
>> + params[SI_PARAM_CONST] = const_array(v16i8, NUM_CONST_BUFFERS);
>> + params[SI_PARAM_RW_BUFFERS] = const_array(v16i8, 6); /* XXX hardcoded 
>> */
>> + params[SI_PARAM_SAMPLER] = const_array(v4i32, NUM_SAMPLER_STATES);
>> + params[SI_PARAM_RESOURCE] = const_array(v8i32, NUM_SAMPLER_VIEWS);
>>
>>   switch (si_shader_ctx->type) {
>>   case TGSI_PROCESSOR_VERTEX:
>> - params[SI_PARAM_VERTEX_BUFFER] = params[SI_PARAM_CONST];
>> + params[SI_PARAM_VERTEX_BUFFER] = const_array(v16i8, 16); /* 
>> XXX hardcoded */
>>   params[SI_PARAM_START_INSTANCE] = i32;
>>   num_params = SI_PARAM_START_INSTANCE+1;
>>   if (shader->key.vs.as_es) {
>> --
>> 1.9.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Jordan Justen]

On Thu, Jul 10, 2014 at 2:24 PM,   wrote:
> From: Thomas Helland 
>
> Let's cut the needless A && B here.
> Gives some effect on a clean shader-db with
> some extra shaders from TF2 and portal.
>
> helped: shaders/tf2/2042.shader_test fs16:23 -> 21
> (-8.70%)
> helped: shaders/tf2/2042.shader_test fs8: 23 -> 21
> (-8.70%)
> helped: shaders/tf2/4624.shader_test fs16:21 -> 19
> (-9.52%)
> helped: shaders/tf2/4624.shader_test fs8: 21 -> 19
> (-9.52%)
> helped: shaders/tf2/763.shader_test fs16: 23 -> 21
> (-8.70%)
> helped: shaders/tf2/763.shader_test fs8:  23 -> 21
> (-8.70%)
>
> HURT:   shaders/orbital_explorer.shader_test vs:  1049 -> 1052
> (0.29%)
>
> total instructions in shared programs: 758979 -> 758970 (-0.00%)
> instructions in affected programs: 1183 -> 1174 (-0.76%)
> GAINED:0
> LOST:  0
>
> Signed-off-by: Thomas Helland 
> ---
>  src/glsl/opt_algebraic.cpp | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index ac7514a..8f3a505 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -588,6 +588,16 @@ ir_algebraic_visitor::handle_expression(ir_expression 
> *ir)
>} else if (ir->operands[0]->equals(ir->operands[1])) {
>   /* (a || a) == a */
>   return ir->operands[0];
> +  } else if (op_expr[0] && op_expr[0]->operation == ir_binop_logic_and &&
> +(op_expr[0]->operands[0]->equals(op_expr[1]) ||
> + op_expr[0]->operands[1]->equals(op_expr[1]))) {
> + /* A || (A && B)  or A || (B && A) */
> + return ir->operands[0];

Isn't this returning the 'and expr' rather than 'A'?

Are the comments swapped too?

-Jordan

> +  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_and &&
> +(op_expr[1]->operands[0]->equals(op_expr[0]) ||
> + op_expr[1]->operands[1]->equals(op_expr[0]))) {
> + /* (A && B) || A  or (B && A) || A */
>
> + return ir->operands[1];
>}
>break;
>
> --
> 2.0.0
>
> ___
> 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] mesa: fix crash in st/mesa after deleting a VAO

[Marek Olšák]

From: Marek Olšák 

This happens when glGetMultisamplefv (or any other non-draw function) is
called, which doesn't invoke the VBO module to update _DrawArrays and
the pointer is invalid at that point.

However st/mesa still dereferences it to setup vertex buffers ==> crash.
---
 src/mesa/main/arrayobj.c   | 15 +++
 src/mesa/main/mtypes.h | 14 ++
 src/mesa/vbo/vbo_context.h | 22 --
 src/mesa/vbo/vbo_exec.c| 15 ---
 4 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index efb9930..0f8f827 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -427,6 +427,21 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, 
GLboolean genRequired)
   }
}
 
+   if (ctx->Array.DrawMethod == DRAW_ARRAYS) {
+  /* The _DrawArrays pointer is pointing at the VAO being unbound and
+   * that VAO may be in the process if being deleted. If it's not going
+   * to be deleted, this will have no effect, because the pointer needs
+   * to be updated by the VBO module anyway.
+   *
+   * Before the VBO module can update the pointer, we have to set it
+   * to NULL for drivers not to set up arrays which are not bound,
+   * or to prevent a crash if the VAO being unbound is going to be
+   * deleted.
+   */
+  ctx->Array._DrawArrays = NULL;
+  ctx->Array.DrawMethod = DRAW_NONE;
+   }
+
ctx->NewState |= _NEW_ARRAY;
_mesa_reference_vao(ctx, &ctx->Array.VAO, newObj);
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a7126fd..b699021 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1640,6 +1640,17 @@ struct gl_vertex_array_object
 };
 
 
+/** Used to signal when transitioning from one kind of drawing method
+ * to another.
+ */
+typedef enum {
+   DRAW_NONE,  /**< Initial value only */
+   DRAW_BEGIN_END,
+   DRAW_DISPLAY_LIST,
+   DRAW_ARRAYS
+} gl_draw_method;
+
+
 /**
  * Vertex array state
  */
@@ -1679,6 +1690,9 @@ struct gl_array_attrib
 * The array pointer is set up only by the VBO module.
 */
const struct gl_client_array **_DrawArrays; /**< 0..VERT_ATTRIB_MAX-1 */
+
+   /** One of the DRAW_xxx flags, not consumed by drivers */
+   gl_draw_method DrawMethod;
 };
 
 
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index 1680e23..e224513 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -57,18 +57,6 @@
 #include "vbo_save.h"
 
 
-/** Used to signal when transitioning from one kind of drawing method
- * to another.
- */
-enum draw_method
-{
-   DRAW_NONE,  /**< Initial value only */
-   DRAW_BEGIN_END,
-   DRAW_DISPLAY_LIST,
-   DRAW_ARRAYS
-};
-
-
 struct vbo_context {
struct gl_client_array currval[VBO_ATTRIB_MAX];

@@ -83,8 +71,6 @@ struct vbo_context {
 * is responsible for initiating any fallback actions required:
 */
vbo_draw_func draw_prims;
-
-   enum draw_method last_draw_method;
 };
 
 
@@ -122,11 +108,11 @@ get_program_mode( struct gl_context *ctx )
  * that arrays may be changing.
  */
 static inline void
-vbo_draw_method(struct vbo_context *vbo, enum draw_method method)
+vbo_draw_method(struct vbo_context *vbo, gl_draw_method method)
 {
-   if (vbo->last_draw_method != method) {
-  struct gl_context *ctx = vbo->exec.ctx;
+   struct gl_context *ctx = vbo->exec.ctx;
 
+   if (ctx->Array.DrawMethod != method) {
   switch (method) {
   case DRAW_ARRAYS:
  ctx->Array._DrawArrays = vbo->exec.array.inputs;
@@ -142,7 +128,7 @@ vbo_draw_method(struct vbo_context *vbo, enum draw_method 
method)
   }
 
   ctx->NewDriverState |= ctx->DriverFlags.NewArray;
-  vbo->last_draw_method = method;
+  ctx->Array.DrawMethod = method;
}
 }
 
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index bd2b1b1..eb90350 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -82,21 +82,6 @@ void vbo_exec_invalidate_state( struct gl_context *ctx, 
GLuint new_state )
 
if (!exec->validating && new_state & (_NEW_PROGRAM|_NEW_ARRAY)) {
   exec->array.recalculate_inputs = GL_TRUE;
-
-  /* If we ended up here because a VAO was deleted, the _DrawArrays
-   * pointer which pointed to the VAO might be invalid now, so set it
-   * to NULL.  This prevents crashes in driver functions like Clear
-   * where driver state validation might occur, but the vbo module is
-   * still in an invalid state.
-   *
-   * Drivers should skip vertex array state validation if _DrawArrays
-   * is NULL.  It also has no effect on performance, because attrib
-   * bindings will be recalculated anyway.
-   */
-  if (vbo->last_draw_method == DRAW_ARRAYS) {
- ctx->Array._DrawArrays = NULL;
- vbo->last_draw_method = DRAW_NONE;
-  }
}
 
if (new_state & _NEW_EVAL)
-- 
1.9.1

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Brian Paul]

On 07/10/2014 03:24 PM, thomashellan...@gmail.com wrote:

From: Thomas Helland 

Let's cut the needless A && B here.
Gives some effect on a clean shader-db with
some extra shaders from TF2 and portal.

helped: shaders/tf2/2042.shader_test fs16:23 -> 21
(-8.70%)
helped: shaders/tf2/2042.shader_test fs8: 23 -> 21
(-8.70%)
helped: shaders/tf2/4624.shader_test fs16:21 -> 19
(-9.52%)
helped: shaders/tf2/4624.shader_test fs8: 21 -> 19
(-9.52%)
helped: shaders/tf2/763.shader_test fs16: 23 -> 21
(-8.70%)
helped: shaders/tf2/763.shader_test fs8:  23 -> 21
(-8.70%)

HURT:   shaders/orbital_explorer.shader_test vs:  1049 -> 1052
(0.29%)

total instructions in shared programs: 758979 -> 758970 (-0.00%)
instructions in affected programs: 1183 -> 1174 (-0.76%)
GAINED:0
LOST:  0

Signed-off-by: Thomas Helland 
---
  src/glsl/opt_algebraic.cpp | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index ac7514a..8f3a505 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -588,6 +588,16 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
} else if (ir->operands[0]->equals(ir->operands[1])) {
   /* (a || a) == a */
   return ir->operands[0];
+  } else if (op_expr[0] && op_expr[0]->operation == ir_binop_logic_and &&
+(op_expr[0]->operands[0]->equals(op_expr[1]) ||
+ op_expr[0]->operands[1]->equals(op_expr[1]))) {
+ /* A || (A && B)  or A || (B && A) */
+ return ir->operands[0];
+  } else if (op_expr[1] && op_expr[1]->operation == ir_binop_logic_and &&
+(op_expr[1]->operands[0]->equals(op_expr[0]) ||
+ op_expr[1]->operands[1]->equals(op_expr[0]))) {
+ /* (A && B) || A  or (B && A) || A */
+ return ir->operands[1];
}
break;




It would be helpful if the comments indicated what the expression is 
simplified to.  Ex:


/* A || (A && B) == A, or A || (B && A) == A */

But something else looks fishy here.  The comments don't seem to agree 
with the code, if I'm reading things right.


BTW, looking at these algebraic simplifications in general, where do we 
check for operands with side-effects?  For example, in the "1^x == 1" 
optimization, suppose x is a function call which modifies a global. 
Removing x would be invalid, right?


-Brian

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

Re: [Mesa-dev] [PATCH] mesa: fix crash in st/mesa after deleting a VAO

[Brian Paul]

On 07/10/2014 05:11 PM, Marek Olšák wrote:

From: Marek Olšák 

This happens when glGetMultisamplefv (or any other non-draw function) is
called, which doesn't invoke the VBO module to update _DrawArrays and
the pointer is invalid at that point.

However st/mesa still dereferences it to setup vertex buffers ==> crash.
---
  src/mesa/main/arrayobj.c   | 15 +++
  src/mesa/main/mtypes.h | 14 ++
  src/mesa/vbo/vbo_context.h | 22 --
  src/mesa/vbo/vbo_exec.c| 15 ---
  4 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index efb9930..0f8f827 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -427,6 +427,21 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, 
GLboolean genRequired)
}
 }

+   if (ctx->Array.DrawMethod == DRAW_ARRAYS) {
+  /* The _DrawArrays pointer is pointing at the VAO being unbound and
+   * that VAO may be in the process if being deleted. If it's not going


s/if/of/



+   * to be deleted, this will have no effect, because the pointer needs
+   * to be updated by the VBO module anyway.
+   *
+   * Before the VBO module can update the pointer, we have to set it
+   * to NULL for drivers not to set up arrays which are not bound,
+   * or to prevent a crash if the VAO being unbound is going to be
+   * deleted.
+   */
+  ctx->Array._DrawArrays = NULL;
+  ctx->Array.DrawMethod = DRAW_NONE;
+   }
+
 ctx->NewState |= _NEW_ARRAY;
 _mesa_reference_vao(ctx, &ctx->Array.VAO, newObj);

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a7126fd..b699021 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1640,6 +1640,17 @@ struct gl_vertex_array_object
  };


+/** Used to signal when transitioning from one kind of drawing method
+ * to another.
+ */
+typedef enum {
+   DRAW_NONE,  /**< Initial value only */
+   DRAW_BEGIN_END,
+   DRAW_DISPLAY_LIST,
+   DRAW_ARRAYS
+} gl_draw_method;
+
+
  /**
   * Vertex array state
   */
@@ -1679,6 +1690,9 @@ struct gl_array_attrib
  * The array pointer is set up only by the VBO module.
  */
 const struct gl_client_array **_DrawArrays; /**< 0..VERT_ATTRIB_MAX-1 */
+
+   /** One of the DRAW_xxx flags, not consumed by drivers */
+   gl_draw_method DrawMethod;
  };


diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index 1680e23..e224513 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -57,18 +57,6 @@
  #include "vbo_save.h"


-/** Used to signal when transitioning from one kind of drawing method
- * to another.
- */
-enum draw_method
-{
-   DRAW_NONE,  /**< Initial value only */
-   DRAW_BEGIN_END,
-   DRAW_DISPLAY_LIST,
-   DRAW_ARRAYS
-};
-
-
  struct vbo_context {
 struct gl_client_array currval[VBO_ATTRIB_MAX];

@@ -83,8 +71,6 @@ struct vbo_context {
  * is responsible for initiating any fallback actions required:
  */
 vbo_draw_func draw_prims;
-
-   enum draw_method last_draw_method;
  };


@@ -122,11 +108,11 @@ get_program_mode( struct gl_context *ctx )
   * that arrays may be changing.
   */
  static inline void
-vbo_draw_method(struct vbo_context *vbo, enum draw_method method)
+vbo_draw_method(struct vbo_context *vbo, gl_draw_method method)
  {
-   if (vbo->last_draw_method != method) {
-  struct gl_context *ctx = vbo->exec.ctx;
+   struct gl_context *ctx = vbo->exec.ctx;

+   if (ctx->Array.DrawMethod != method) {
switch (method) {
case DRAW_ARRAYS:
   ctx->Array._DrawArrays = vbo->exec.array.inputs;
@@ -142,7 +128,7 @@ vbo_draw_method(struct vbo_context *vbo, enum draw_method 
method)
}

ctx->NewDriverState |= ctx->DriverFlags.NewArray;
-  vbo->last_draw_method = method;
+  ctx->Array.DrawMethod = method;
 }
  }

diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index bd2b1b1..eb90350 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -82,21 +82,6 @@ void vbo_exec_invalidate_state( struct gl_context *ctx, 
GLuint new_state )

 if (!exec->validating && new_state & (_NEW_PROGRAM|_NEW_ARRAY)) {
exec->array.recalculate_inputs = GL_TRUE;
-
-  /* If we ended up here because a VAO was deleted, the _DrawArrays
-   * pointer which pointed to the VAO might be invalid now, so set it
-   * to NULL.  This prevents crashes in driver functions like Clear
-   * where driver state validation might occur, but the vbo module is
-   * still in an invalid state.
-   *
-   * Drivers should skip vertex array state validation if _DrawArrays
-   * is NULL.  It also has no effect on performance, because attrib
-   * bindings will be recalculated anyway.
-   */
-  if (vbo->last_draw_method == DRAW_ARRAYS) {
- ctx->Array._DrawArrays = NULL;
- vbo->last_draw_method = DRAW_NONE;
-  }

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Jordan Justen]

On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul  wrote:
> BTW, looking at these algebraic simplifications in general, where do we
> check for operands with side-effects?  For example, in the "1^x == 1"
> optimization, suppose x is a function call which modifies a global. Removing
> x would be invalid, right?

ir_call doesn't implement equals, so it should always return 'not
equals' via ir_instruction::equals. (ir_equals.cpp)

This should prevent optimizations involving calls, right?

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

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Matt Turner]

On Thu, Jul 10, 2014 at 4:12 PM, Brian Paul  wrote:
> BTW, looking at these algebraic simplifications in general, where do we
> check for operands with side-effects?  For example, in the "1^x == 1"
> optimization, suppose x is a function call which modifies a global. Removing
> x would be invalid, right?

Function calls (ir_call) are not R-values (ir_rvalues), so they can
never appear in an expression tree. They can only appear as top-level
ir_instructions, so return_something() in 1^return_something() would
appear as an ir_call in the instruction list, and then its result (an
ir_variable) could be used in an expression tree.

GLSL IR's expression trees are pure, i.e., they have no side effects.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 81174] Gallium: GL_LINE_LOOP broken with more than 512 points

[bugzilla-daemon]

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

--- Comment #3 from Marek Olšák  ---
No. If you use the immediate-mode style rendering (glBegin/End), the vertices
are written into a buffer. When the buffer is full, all vertices are drawn and
a new buffer is allocated for the following vertex data. Guess what, you'll end
up with a lot of line loops instead of just one.

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #4 from Boyan Ding  ---
(In reply to comment #1)
> My guess it that it is a libxcb bug.
> Debian packages have the fix (which is
> http://cgit.freedesktop.org/xcb/libxcb/commit/
> ?id=3b72a2c9d1d656c74c691a45689e1d637f669e3a)

I tried git version of libxcb and xcb-proto today and the problem still
remains.

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #5 from Boyan Ding  ---
I think it's not about xcb bug.
I turned on DebugPresent output and that's what I get when running glxgears:
q 1 0x2bf5a30   351258: 0046 -> 0042 (crtc (nil))
e 1 ust 5854416007 msc 351258
c 0x2bf5a30   351258: 0046 -> 0042
i 0046
d 1 0x2bf5a30   351258: 0046 -> 0042
q 2 0x35e42a0 111514530873345: 0046 -> 0042 (crtc (nil))
e 2 ust 5854416646 msc 351258
c 0x35e42a0   351258: 0046 -> 0042
i 0046
d 2 0x35e42a0 111514530873345: 0046 -> 0042
q 3 0x35e42a0 111514530873346: 0046 -> 0042 (crtc (nil))
e 3 ust 5854417065 msc 351258
c 0x35e42a0   351258: 0046 -> 0042
i 0046
d 3 0x35e42a0 111514530873346: 0046 -> 0042
q 4 0x35e42a0 463856467970: 0046 -> 0042 (crtc (nil))
(both the output and the animation stop here)

That means the event waited for is even not sent.

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #6 from Axel Davy  ---
I tested the program and confirmed I have the same problem with mesa git.

However on this branch https://github.com/axeldavy/mesa/tree/submit4,
I don't get the bug. This is quite strange.

Could test it and say if you have the bug with it too ?

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #7 from Axel Davy  ---
Hum... strangely after testing again, it doesn't work too now with this branch.

Perhaps the bug is from Xserver side.

-- 
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] i965/fs: Set force_uncompressed and force_sechalf on samplepos setup.

[Kenneth Graunke]

gen8_fs_generator uses these to decide whether to set the execution size
to 8 or 16, so we incorrectly made both of these MOVs the full width in
SIMD16 shaders.  (It happened to work out on Gen4-7.)

Setting them should also help inform optimization passes what's really
going on, which could help avoid bugs.

Signed-off-by: Kenneth Graunke 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index a3ad375..ceea32a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1248,19 +1248,21 @@ fs_visitor::emit_samplepos_setup(ir_variable *ir)
   stride(retype(brw_vec1_grf(payload.sample_pos_reg, 0),
 BRW_REGISTER_TYPE_B), 16, 8, 2);
 
-   emit(MOV(int_sample_x, fs_reg(sample_pos_reg)));
+   fs_inst *inst = emit(MOV(int_sample_x, fs_reg(sample_pos_reg)));
if (dispatch_width == 16) {
-  fs_inst *inst = emit(MOV(half(int_sample_x, 1),
-   fs_reg(suboffset(sample_pos_reg, 16;
+  inst->force_uncompressed = true;
+  inst = emit(MOV(half(int_sample_x, 1),
+  fs_reg(suboffset(sample_pos_reg, 16;
   inst->force_sechalf = true;
}
/* Compute gl_SamplePosition.x */
compute_sample_position(pos, int_sample_x);
pos.reg_offset++;
-   emit(MOV(int_sample_y, fs_reg(suboffset(sample_pos_reg, 1;
+   inst = emit(MOV(int_sample_y, fs_reg(suboffset(sample_pos_reg, 1;
if (dispatch_width == 16) {
-  fs_inst *inst = emit(MOV(half(int_sample_y, 1),
-   fs_reg(suboffset(sample_pos_reg, 17;
+  inst->force_uncompressed = true;
+  inst = emit(MOV(half(int_sample_y, 1),
+  fs_reg(suboffset(sample_pos_reg, 17;
   inst->force_sechalf = true;
}
/* Compute gl_SamplePosition.y */
-- 
2.0.0

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

[Mesa-dev] [PATCH 1/2] i965: Set execution size to 8 for instructions with force_sechalf set.

[Kenneth Graunke]

Both inst->force_uncompressed and inst->force_sechalf mean that the
generated instruction should be uncompressed and have an execution size
of 8.  We don't require the visitor to set both flags - setting
inst->force_sechalf by itself is supposed to be enough.

On Gen4-7, guess_execution_size() demoted instructions to 8-wide based
on the default compression state.  On Gen8+, we instead set a default
execution size, which worked great...except that we forgot to check
inst->force_sechalf when deciding whether to use 8 or 16.

Signed-off-by: Kenneth Graunke 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 02e28cf..2924820 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -921,7 +921,7 @@ gen8_fs_generator::generate_code(exec_list *instructions)
   default_state.mask_control = ir->force_writemask_all;
   default_state.flag_subreg_nr = ir->flag_subreg;
 
-  if (dispatch_width == 16 && !ir->force_uncompressed)
+  if (dispatch_width == 16 && !ir->force_uncompressed && 
!ir->force_sechalf)
  default_state.exec_size = BRW_EXECUTE_16;
   else
  default_state.exec_size = BRW_EXECUTE_8;
-- 
2.0.0

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #8 from Boyan Ding  ---
(In reply to comment #7)
> Perhaps the bug is from Xserver side.

I guess it may be the case. But where is the problem in xserver -- xwayland or
glamor or else? If it is not in xwayland, I guess there is possibly a way to
reproduce that out of it. But I'm not an expert in that.

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

[Mesa-dev] [Bug 81139] Rendering sometimes halts in waiting for back buffers with dri3 & xwayland

[bugzilla-daemon]

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

--- Comment #9 from Axel Davy  ---
For Xwayland, Present uses the Present fallback implementation.

If never present_fake_queue_vblank is called with a msc too low (already
passed), then perhaps it's going to wait forever. My guess is that for an
unknown reason, this function is called with a past msc.

-- 
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

Re: [Mesa-dev] [PATCH] glsl: Optimize logic operation A || (A && B)

[Thomas Helland]

11. juli 2014 01:02 skrev "Jordan Justen"  følgende:
>
> On Thu, Jul 10, 2014 at 2:24 PM,   wrote:
> > From: Thomas Helland 
> >
> > Let's cut the needless A && B here.
> > Gives some effect on a clean shader-db with
> > some extra shaders from TF2 and portal.
> >
> > helped: shaders/tf2/2042.shader_test fs16:23 -> 21
> > (-8.70%)
> > helped: shaders/tf2/2042.shader_test fs8: 23 -> 21
> > (-8.70%)
> > helped: shaders/tf2/4624.shader_test fs16:21 -> 19
> > (-9.52%)
> > helped: shaders/tf2/4624.shader_test fs8: 21 -> 19
> > (-9.52%)
> > helped: shaders/tf2/763.shader_test fs16: 23 -> 21
> > (-8.70%)
> > helped: shaders/tf2/763.shader_test fs8:  23 -> 21
> > (-8.70%)
> >
> > HURT:   shaders/orbital_explorer.shader_test vs:  1049 -> 1052
> > (0.29%)
> >
> > total instructions in shared programs: 758979 -> 758970 (-0.00%)
> > instructions in affected programs: 1183 -> 1174 (-0.76%)
> > GAINED:0
> > LOST:  0
> >
> > Signed-off-by: Thomas Helland 
> > ---
> >  src/glsl/opt_algebraic.cpp | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> > index ac7514a..8f3a505 100644
> > --- a/src/glsl/opt_algebraic.cpp
> > +++ b/src/glsl/opt_algebraic.cpp
> > @@ -588,6 +588,16 @@
ir_algebraic_visitor::handle_expression(ir_expression *ir)
> >} else if (ir->operands[0]->equals(ir->operands[1])) {
> >   /* (a || a) == a */
> >   return ir->operands[0];
> > +  } else if (op_expr[0] && op_expr[0]->operation ==
ir_binop_logic_and &&
> > +(op_expr[0]->operands[0]->equals(op_expr[1]) ||
> > + op_expr[0]->operands[1]->equals(op_expr[1]))) {
> > + /* A || (A && B)  or A || (B && A) */
> > + return ir->operands[0];
>
> Isn't this returning the 'and expr' rather than 'A'?
>
> Are the comments swapped too?
>
> -Jordan
>

Oh, too much coffee I guess.
You are of course doubly correct.
Thanks for spotting that!
I'll put up a new version soon.

-Thomas

> > +  } else if (op_expr[1] && op_expr[1]->operation ==
ir_binop_logic_and &&
> > +(op_expr[1]->operands[0]->equals(op_expr[0]) ||
> > + op_expr[1]->operands[1]->equals(op_expr[0]))) {
> > + /* (A && B) || A  or (B && A) || A */
> >
> > + return ir->operands[1];
> >}
> >break;
> >
> > --
> > 2.0.0
> >
> > ___
> > 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