[Mesa-dev] [PATCH] nv30: fix inconsistent setting of push->user_priv

It's set to &nv30->bufctx everywhere else. Signed-off-by: Ilia Mirkin Cc: "9.2" --- src/gallium/drivers/nv30/nv30_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nv30/nv30_context.c b/src/gallium/drivers/nv30/nv30_context.c index e872c02..acef4

[Mesa-dev] Mesa (git 20130828) fails to build on MIPS

Hello, I encounter an error when I build mesa from git. I am on a MIPS computer with ATI RS780E. Here are the instructions I use for the build: ./autogen.sh \ --prefix=/usr \ --enable-gles2 \ --disable-gallium-egl \ --with-egl-platforms=x11,wayland,drm \ --enable-gbm \ --

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

On Tue, Sep 3, 2013 at 8:20 PM, Stéphane Marchesin wrote: > Hi Zack, > > This change regresses a bunch of point sprite piglit tests on i915g. Should > we revert back to the old behaviour? As far as I can see, it was correct (it > was keeping the attributes in case another stage is using them). > >

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

Hi Zack, This change regresses a bunch of point sprite piglit tests on i915g. Should we revert back to the old behaviour? As far as I can see, it was correct (it was keeping the attributes in case another stage is using them). Stéphane On Thu, Aug 8, 2013 at 12:46 PM, Zack Rusin wrote: > Bef

[Mesa-dev] [PATCH 15/15] i965/gen6+: Support 128 varying components.

GL 3.2 requires us to support 128 varying components for geometry shader outputs and fragment shader inputs, and 64 varying components otherwise. But there's no hardware limitation that restricts us to 64 varying components, and core Mesa doesn't currently allow different stages to have different

[Mesa-dev] [PATCH 14/15] i965/ff_gs: Generate URB writes using a loop.

Previously we only ever did 1 URB write, since the maximum number of varyings we support is small enough to fit in 1 URB write (when using BRW_URB_SWIZZLE_NONE, which is what the pre-Gen7 GS always uses). But we're about to increase the number of varying components we support from 64 to 128. With

[Mesa-dev] [PATCH 13/15] i965/gen6: Fix assertions on VS/GS URB size.

The "{VS,GS} URB Entry Allocation Size" fields of 3DSTATE_URB allow values in the range 0-4, but they are U8-1 fields, so the range of possible allocation sizes is 1-5. We were erroneously prohibiting a size of 5. --- src/mesa/drivers/dri/i965/gen6_urb.c | 4 ++-- 1 file changed, 2 insertions(+),

[Mesa-dev] [PATCH 12/15] i965/vec4: Generate URB writes using a loop.

Previously we only ever did 1 or 2 URB writes, since the maximum number of varyings we support is small enough to fit in 2 URB writes. But GL 3.2 requires the geometry shader to support 128 output varying components, and this could require up to 3 URB writes. --- src/mesa/drivers/dri/i965/brw_vec4

[Mesa-dev] [PATCH 11/15] i965/fs: When >64 input components, order them to match prev pipeline stage.

Since the SF/SBE stage is only capable of performing arbitrary reorderings of 16 varying slots, we can't arrange the fragment shader inputs in an arbitrary order if there are more than 16 input varying slots in use. We need to make sure that slots 16-31 match the corresponding outputs of the previ

[Mesa-dev] [PATCH 10/15] i965/fs: Simplify computation of key.input_slots_valid during precompile.

The for loop was rather silly. In addition to checking brw->gen < 6 on each loop iteration, it took pains to exclude bits from fp->Base.InputsRead that don't correspond to fragment shader inputs. But those bits would never have been set in the first place, since the only bits that are ever set in

[Mesa-dev] [PATCH 09/15] i965/gs: Stop storing an input VUE map in the GS program key.

Now that the vertex shader output VUE map is determined solely by a 64-bit bitfield, we don't have to store it in its entirety in the geometry shader program key; instead, we can just store the bitfield, and let the geometry shader infer the VUE map at compile time. This dramatically reduces the s

[Mesa-dev] [PATCH 08/15] i965/gen6+: Remove VUE map dependency on userclip_active.

Previously, on Gen6+, we laid out the vertex (or geometry) shader VUE map differently depending whether user clipping was active. If it was active, we put the clip distances in slots 2 and 3 (where the clipper expects them); if it was inactive, we assigned them in the order of the gl_varying_slot

[Mesa-dev] [PATCH 07/15] i965/fs: Stop wasting input attribute space on gl_FragCoord and gl_FrontFacing.

Previously, if a fragment shader accessed gl_FragCoord or gl_FrontFacing, we would assign them their own slots in the fragment shader input attribute array, using up space that could be made available to real varyings. This was not strictly necessary (since these values are not true varyings, and

[Mesa-dev] [PATCH 06/15] i965/sf: Consult brw_wm_prog_data when setting up SF/SBE state.

Previously, the SF/SBE setup code delivered varying inputs to the FS in the order in which they appear in the gl_program::InputsRead bitfield, since that's what the FS expects. When we add support for more than 64 varying components, this will no longer always be the case, because the Gen6+ SF/SBE

[Mesa-dev] [PATCH 05/15] i965/sf: Consolidate common code for setting up gen6-7 attribute overrides.

--- src/mesa/drivers/dri/i965/brw_state.h | 9 +- src/mesa/drivers/dri/i965/gen6_sf_state.c | 153 +- src/mesa/drivers/dri/i965/gen7_sf_state.c | 64 + 3 files changed, 97 insertions(+), 129 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_sta

[Mesa-dev] [PATCH 03/15] i965/fs: Consult brw_wm_prog_data::num_varying_inputs when setting up WM state.

Previously, we assumed that the number of varying inputs consumed by the fragment shader was equal to the number of bits set in gl_program::InputsRead. However, we'll soon be making two changes that will cause that not to be true: - We'll stop wasting varying input space for gl_FragCoord and gl

[Mesa-dev] [PATCH 04/15] i965/sf: Use BRW_SF_URB_ENTRY_READ_OFFSET rather than hardcoded values.

We always program the SF unit to start reading the vertex URB entry at offset 1. In upcoming patches, we'll be adding FS code that relies on this. So consistently use the constant BRW_SF_URB_ENTRY_READ_OFFSET rather than hardcoding a 1. --- src/mesa/drivers/dri/i965/brw_context.h | 10

[Mesa-dev] [PATCH 01/15] i965/fs: Expose "urb_setup" as part of brw_wm_prog_data.

At the moment, for Gen6+, the FS assumes that all varying inputs are delivered to it in the order in which they appear in the gl_program::InputsRead bitfield, and the SF/SBE setup code ensures that they are delivered in this order. When we add support for more than 64 varying components, this will

[Mesa-dev] [PATCH 02/15] i965/fs: Change brw_wm_prog_data::urb_read_length to num_varying_inputs.

On gen4-5, the FS stage reads varying inputs from URB entries that were output by the SF thread, where each register stores the interpolation setup for two components of a vec4, therefore the FS urb_read_length is twice the number of FS input varyings. On gen6+, varying inputs are directly deposit

[Mesa-dev] [PATCH 00/15] i965/gen6+: Support 128 varying components.

GL 3.2 requires us to support 128 varying components for geometry shader outputs and fragment shader inputs, and 64 varying components otherwise. But there's no hardware limitation that restricts us to 64 varying components, and core Mesa doesn't currently allow different stages to have different

Re: [Mesa-dev] [PATCH] i965/gs: Don't assign gl_Layer its own slot in the VUE map.

On 09/03/2013 04:11 PM, Paul Berry wrote: --- src/mesa/drivers/dri/i965/brw_vs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c index b81a538..7c7493f 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.c +++ b/src/me

Re: [Mesa-dev] [PATCH] glsl: propagate max_array_access through function calls

Thanks, I looked at piglit tests and they look OK if they are only supposed to test whether the shader compiles and links. It doesn't look like they test the results of rendering which could be more useful? On Tue, Sep 3, 2013 at 3:19 PM, Dominik Behr wrote: > Thanks, > I looked at piglit tests

Re: [Mesa-dev] [PATCH] glsl: propagate max_array_access through function calls

On Wed, Aug 28, 2013 at 1:10 PM, Dominik Behr wrote: > Fixes a bug where if an uniform array is passed to a function the accesses > to the array are not propagated so later all but the first vector of the > uniform array are removed in parcel_out_uniform_storage resulting in > broken shaders and o

[Mesa-dev] [PATCH] i965/gs: Don't assign gl_Layer its own slot in the VUE map.

--- src/mesa/drivers/dri/i965/brw_vs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c index b81a538..7c7493f 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.c +++ b/src/mesa/drivers/dri/i965/brw_vs.c @@ -64,6 +64,11 @

Re: [Mesa-dev] [PATCH] swrast: Fix crash in sPriv->swrast_loader->getImage().

On 09/01/2013 08:19 AM, Johannes Obermayr wrote: From: Egbert Eich When glXBindTexImageEXT is called and SWrast is used there will be a crash when sPriv->swrast_loader->getImage() is called from swrastSetTexBuffer2(). Reason: no memory has been allocated for the destination thus texImage->Data

Re: [Mesa-dev] [PATCH 2/3] i965/gen7: Set MOCS L3 cacheability for IVB/BYT

On Thu, Aug 15, 2013 at 10:39:31PM +0200, Vedran Rodic wrote: > > We do have the set_caching ioctl. It's enough to flip the PTEs to UC and > > let MOCS manage things. I actually did a few experiments on my IVB. I > > made all Mesa's buffers UC via PTEs by patching libdrm to change the > > cache mod

Re: [Mesa-dev] [PATCH] gallivm: support indirect registers on both dimensions

On 09/03/2013 11:50 AM, Zack Rusin wrote: We support indirect addressing only on the vertex index, but some shaders also use indirect addressing on attributes. This patch adds support for indirect addressing on both dimensions inside gs arrays. Signed-off-by: Zack Rusin --- src/gallium/auxili

[Mesa-dev] [PATCH] gallivm: support indirect registers on both dimensions

We support indirect addressing only on the vertex index, but some shaders also use indirect addressing on attributes. This patch adds support for indirect addressing on both dimensions inside gs arrays. Signed-off-by: Zack Rusin --- src/gallium/auxiliary/draw/draw_llvm.c | 23 ++

Re: [Mesa-dev] [PATCH 1/4] glsl: Refactor a bunch of the code out of cross_validate_outputs_to_inputs

On 30 August 2013 16:07, Ian Romanick wrote: > From: Ian Romanick > > The new function, cross_validate_types_and_qualifiers, will have > multiple callers from this file in future commits. > > Signed-off-by: Ian Romanick > --- > src/glsl/link_varyings.cpp | 171 > +--

Re: [Mesa-dev] [PATCH] i965/gen7.5: Fix lower bound on number of VS URB entries.

On 08/31/2013 10:34 PM, Paul Berry wrote: Haswell GT2 and GT3 require the number of vertex shader URB entries to be at least 64, not 32. At the moment, we always meet this requirement automatically, because in the absence of a geometry shader, we assign all available URB space to the vertex shad

Re: [Mesa-dev] [PATCH 4/4] glsl: Remove unused prog parameter from tfeedback_decl::init

On 30 August 2013 16:07, Ian Romanick wrote: > From: Ian Romanick > > It looks like commit 53febac removed the last user of that parameter. > > Signed-off-by: Ian Romanick > Cc: Paul Berry > Patches 2-4 are: Reviewed-by: Paul Berry > --- > src/glsl/link_varyings.cpp | 6 +++--- > src/gls

Re: [Mesa-dev] [PATCH 4/6] i965/fs: Optimize IF/MOV/ELSE/MOV/ENDIF to SEL when possible.

On Tue, Aug 6, 2013 at 3:24 PM, Christoph Bumiller wrote: > On 06.08.2013 19:19, Matt Turner wrote: >> On Tue, Aug 6, 2013 at 4:14 AM, Christoph Bumiller >> wrote: >>> On 06.08.2013 03:28, Kenneth Graunke wrote: Many GLSL shaders contain code of the form: x = condition ? foo : b

Re: [Mesa-dev] [PATCH] i965: Actually check every primitive for cut index support.

On 2 September 2013 16:47, Ian Romanick wrote: > On 09/01/2013 07:05 PM, Kenneth Graunke wrote: > > can_cut_index_handle_prims() was passed an array of _mesa_prim objects > > and a count, and ran a loop for that many iterations. However, it > > treated the array like a pointer, repeatedly checki

[Mesa-dev] [PATCH 10/11] radeonsi: implement streamout shader support

The shader is responsible for writing to streamout buffers using the TBUFFER_STORE_FORMAT_* instructions. The locations of some input SGPRs and VGPRs are assigned dynamically, because the input SGPRs controlling streamout are not declared if they are not needed, decreasing the indices of all follo

[Mesa-dev] [PATCH 11/11] radeonsi: enable streamout AKA transform feedback on SI

CIK is not enabled, because it's very unstable regardless of transform feedback. --- src/gallium/drivers/radeonsi/radeonsi_pipe.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeons

[Mesa-dev] [PATCH 09/11] radeonsi: implement glDrawTransformFeedback functionality

--- src/gallium/drivers/radeonsi/si_state.c | 1 + src/gallium/drivers/radeonsi/si_state_draw.c | 23 +++ src/gallium/drivers/radeonsi/sid.h | 6 ++ 3 files changed, 30 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drive

[Mesa-dev] [PATCH 08/11] radeonsi: fix streamout queries

--- src/gallium/drivers/radeonsi/r600_hw_context.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index c8fa66c..b6e7a0f 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_

[Mesa-dev] [PATCH 07/11] radeonsi: implement streamout flush properly

--- src/gallium/drivers/radeonsi/si_state_draw.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index 3529660..e65b0cf 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c

[Mesa-dev] [PATCH 06/11] radeonsi: bind streamout buffers to VGT and the vertex shader

--- src/gallium/drivers/radeonsi/radeonsi_pipe.h | 2 + src/gallium/drivers/radeonsi/radeonsi_shader.c | 1 + src/gallium/drivers/radeonsi/radeonsi_shader.h | 18 --- src/gallium/drivers/radeonsi/si_descriptors.c | 68 ++ 4 files changed, 81 insertions(+), 8 deleti

[Mesa-dev] [PATCH 05/11] radeonsi: handle rasterizer_discard and set GS_OUT_PRIM_TYPE

--- src/gallium/drivers/radeonsi/si_state.c | 1 + src/gallium/drivers/radeonsi/si_state_draw.c | 28 +++- src/gallium/drivers/radeonsi/sid.h | 3 +++ 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/

[Mesa-dev] [PATCH 04/11] radeonsi: initialize the first CS like any other

So that the "init" state is always emitted first and not later in draw_vbo. This fixes streamout where the "init" state, which disables streamout, was emitted in draw_vbo after streamout was enabled. --- src/gallium/drivers/radeonsi/r600.h| 1 + src/gallium/drivers/radeonsi/r600_hw_c

[Mesa-dev] [PATCH 03/11] radeonsi: integrate shared streamout state

--- src/gallium/drivers/radeonsi/r600_blit.c | 4 ++-- src/gallium/drivers/radeonsi/r600_hw_context.c | 26 +++--- src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 ++ src/gallium/drivers/radeonsi/radeonsi_pipe.h | 9 + src/gallium/drivers/radeonsi/radeonsi

[Mesa-dev] [PATCH 02/11] radeon: don't emit streamout state if there are no streamout buffers

This could happen if set_stream_output_targets is called twice in a row without a draw call in between. --- src/gallium/drivers/radeon/r600_streamout.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/radeon/r600_streamout.c b/src/gallium/drivers/radeon/r600_streamout.c i

[Mesa-dev] [PATCH 01/11] radeon: don't emit VGT_STRMOUT_BUFFER_BASE on SI

The register doesn't exist on SI. --- src/gallium/drivers/radeon/r600_streamout.c | 85 ++--- 1 file changed, 54 insertions(+), 31 deletions(-) diff --git a/src/gallium/drivers/radeon/r600_streamout.c b/src/gallium/drivers/radeon/r600_streamout.c index ab40630..313d737 10

[Mesa-dev] [PATCH 00/11] Transform Feedback for Radeon SI

This series implements transform feedback for Radeon SI, which also enables OpenGL 3.0. It requires the LLVM patch I sent yesterday. Transform feedback is disabled by default on CIK, because my card is very unstable with current kernel DRM. It should work though. Please review. Marek _

Re: [Mesa-dev] [PATCH] glx: Initialize OpenGL version to 1.0

On 03.09.2013 01:54, Ian Romanick wrote: Please send patches only using git-send-email. Send patches as attachments prevents people from being able to provide in-line review comments. Ok, sorry for the trouble. On 09/01/2013 12:30 PM, Rico Schüller wrote: Some driver/card combinations (r20

[Mesa-dev] [Bug 54080] glXQueryDrawable fails with GLXBadDrawable for a Window in direct context

https://bugs.freedesktop.org/show_bug.cgi?id=54080 Alexander Monakov changed: What|Removed |Added CC||a...@nwnk.net --- Comment #2 from Al

Re: [Mesa-dev] [PATCH] glx: Initialize OpenGL version to 1.0

Please send patches only using git-send-email. Send patches as attachments prevents people from being able to provide in-line review comments. On 09/01/2013 12:30 PM, Rico Schüller wrote: > > Some driver/card combinations (r200/RV280, i915/915G) don't support > OpenGL 2.1. These create in some c

Re: [Mesa-dev] [PATCH] i965: Actually check every primitive for cut index support.

On 09/01/2013 07:05 PM, Kenneth Graunke wrote: > can_cut_index_handle_prims() was passed an array of _mesa_prim objects > and a count, and ran a loop for that many iterations. However, it > treated the array like a pointer, repeatedly checking the first element. Blarg. How would an application b