On Sun, Jan 8, 2012 at 10:44 PM, Matt Turner wrote:
> GLSL spec boneheadedly says (a ^^ a) must actually be evaluated.
>
> Signed-off-by: Matt Turner
> ---
On second thought, maybe the better thing to do here is to evaluate $a
twice, which in most cases would be dead-code eliminated, and then
si
GLSL spec boneheadedly says (a ^^ a) must actually be evaluated.
Signed-off-by: Matt Turner
---
Fortunately, shaders that do this are even more boneheaded.
src/glsl/opt_algebraic.cpp |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src
This brings the code in sync with gen6_sf_state.c; presumably the
mistake was a botched rebase on initial Ivybridge bring-up patches.
Found by diffing batch buffer dumps and noticing the random values.
Thanks to Eric for catching the obvious mistake.
NOTE: This is a candidate for the 7.11 branch.
I don't have the code handy (and haven't looked at it in a while), but wonder
if finer-grained tracking of dirtiness would help? Or more generally trying to
preserve more computed results across state changes?
Keith
- Original Message -
> Hi,
>
> I did some profiling with perf under n
On Sun, Jan 8, 2012 at 5:15 PM, Vincent Lejeune wrote:
> ---
> src/mesa/state_tracker/st_cb_texture.c | 82
>
> 1 files changed, 62 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.
On Sat, Jan 7, 2012 at 8:08 PM, Marek Olšák wrote:
> On Fri, Jan 6, 2012 at 4:42 PM, wrote:
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>> index ccf9c4f..8ef0c18 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
>>
https://bugs.freedesktop.org/show_bug.cgi?id=44564
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
In f3e9ccb3b, I renamed gen6_upload_wm_constants to
gen6_upload_wm_push_constants, but neglected to update this comment.
I don't think there ever was a gen7_prepare_wm_constants function; it
was probably a search and replace error. Of course, "prepare" functions
died a while back as well.
Signed
CACHE_NEW_SAMPLER doesn't cover max_wm_threads, but it does cover
brw->sampler.count. BRW_NEW_PS_BINDING_TABLE is obvious, but it's
probably worth adding a comment anyway.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_wm_state.c |3 ++-
1 files changed, 2 insertions(+),
>From my reading of main/enable.c:735, it appears that
ctx->VertexProgram.PointSizeEnabled is covered by _NEW_PROGRAM.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_sf_state.c |2 ++
src/mesa/drivers/dri/i965/gen6_sf_state.c
According to a comment in gen6_sf_state.c, calls to get_attr_override
need both _NEW_PROGRAM and _NEW_LIGHT. Since Gen7 reuses the same
function, the same dirty bits should apply.
When I performed the SF/SBE split, I partitioned the bits incorrectly:
3DSTATE_SBE (which contains the attribute setu
The BRW_NEW_CURBE_OFFSETS dirty bit is only flagged by the
brw_curbe_offsets state atom which is only used on Gen4-5.
Since it's never flagged, there's no reason to depend on it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_vs_state.c |3 +--
src/mesa/drivers/dri/i965/g
Without MI_SET_CONTEXT, there's no guarantee that another program hasn't
reprogram the GPU's URB state since our last batch. We need to submit
it every time.
This is especially important now that we actually reprogram the URB
layout on Gen6 based on whether or not we're using transform feedback.
The BRW_NEW_URB_FENCE dirty bit is only flagged by the
brw_recalculate_urb_fence state atom which isn't used on Gen6+.
Since it's never flagged, there's no reason to depend on it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_gs_state.c |3 +--
src/mesa/drivers/dri/i965/
Without MI_SET_CONTEXT, there's no guarantee that another program hasn't
reprogram the GPU's SF state since our last batch. We need to submit
it every time.
Found by inspection.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_sf
Without MI_SET_CONTEXT, there's no guarantee that another program hasn't
reprogram the GPU's GS state since our last batch. We need to submit
it every time.
This is especially important now that we actually use the GS unit:
different Mesa-based programs may program it to different states.
Found
Without MI_SET_CONTEXT, there's no guarantee that another program hasn't
reprogram the GPU's clip state since our last batch. We need to submit
it every time.
Found by inspection.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_
While investigating an etracer issue on Ivybridge, I did a lot of careful
reading of the tracked state atoms' dirty bits. Found a bunch of issues.
Unfortunately, none of these patches fixed the issues I was seeing.
While we're at it: BRW_NEW_CONTEXT seems like the wrong thing in basically
every c
This brings the dirty bits in line with the comments.
This does /not/ need to be cherry-picked to stable branches because the
access requiring _NEW_BUFFERS was added in master as part of HiZ.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_depthstencil.c |2 +-
1 files cha
---
src/mesa/state_tracker/st_cb_texture.c | 82
1 files changed, 62 insertions(+), 20 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 3cd1b2b..eeb6e3a 100644
--- a/src/mesa/state_tracker/st_cb_tex
---
src/mesa/state_tracker/st_cb_texture.c | 67 ---
src/mesa/state_tracker/st_cb_texture.h |5 ++
src/mesa/state_tracker/st_gen_mipmap.c |4 +-
3 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa
Hi,
I did some profiling with perf under nexuiz and found that st_finalize_texture
function was one of the most cycle consumming. (~1,50% whereas darkplaces took
~30%)
I rewrite some part of this function to make it a bit faster ; with these 2
patches,
st_finalize_texture consumption went down
On 01/08/2012 01:25 PM, Tolga Dalman wrote:
On 01/06/12 14:44, Dylan Baker wrote:
if you don't have an /etc/drirc or ~/.drirc then all of the tests will
give a status of 'warn', this addes that warning to the ignored list.
---
tests/all.tests | 1 +
1 files changed, 1 insertions(+), 0 deletions(-
On 01/06/12 14:44, Dylan Baker wrote:
if you don't have an /etc/drirc or ~/.drirc then all of the tests will
give a status of 'warn', this addes that warning to the ignored list.
---
tests/all.tests |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/all.tests b/test
---
src/mesa/drivers/dri/i965/gen7_wm_state.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index a994836..6a45520 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mes
On Sat, 7 Jan 2012 14:37:34 -0700, Brian Paul wrote:
> Since it returns uint values, not int.
Series is:
Reviewed-by: Eric Anholt
pgpofeFGAiUZt.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fre
Series is
Reviewed-by: Eric Anholt
pgpjfhSfYYkmc.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
There are 3 changes:
1) stride is specified for each buffer, not just one, so that drivers don't
have to derive it from the outputs
2) new per-output property dst_offset, which specifies the offset
into the buffer in dwords where the output should be stored,
so that drivers don't have to
On Jan 2, 2012, at 7:03 PM, Ian Romanick wrote:
> On 01/02/2012 06:18 PM, Jeremy Huddleston wrote:
>> xdriinfo is failing to build in tinderbox (through no change of its own).
>> The relevant changes in mesa were bce506f..7705833. My guess is that this
>> was caused by one of:
>>
>> glx: Add
On 01/06/2012 04:54 PM, Kenneth Graunke wrote:
Reviewed-by: Ian Romanick
---
Makefile|2 +-
configs/default |4 +-
docs/relnotes-7.12.html | 83 ---
docs/relnotes-8.0.html | 83 +++
From: Ian Romanick
Once the i965 driver stops calling _mesa_ir_link_shader, this
information is no longer set.
Ideally gen6_upload_vs_push_constants should use the
gl_shader_program, but I don't see a way to propagate the information
there. The other alternative, since this is the only usage, i
From: Ian Romanick
Instead, do the uniform setting and input / output mapping directly in
brw_link_shader. Hurray for not generating Mesa IR!
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 60 +++---
1 files changed, 54 insertions(+), 6 de
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_fs.h |2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs
From: Ian Romanick
This previously enabled some optimizations in the fragment shader
(interpolation, etc.) if some input components were always 0.0 or
1.0. However, this data was generated by analyzing Mesa IR. The
next patch in this series removes generation of Mesa IR for GLSL
paths. When we
From: Ian Romanick
All three of these commits could probably be squashed into one.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mes
From: Ian Romanick
There are several things that could cause the fragment shader
precompile to fail. Looking for calls to 'fail' in brw_fs_visitor.cpp
finds three classes of things:
* Trying to emit instructions that are invalid in 16-wide mode.
* Trying to emit instructions that should ha
From: Ian Romanick
The only error that the vertex shader precompile could generate is
when register allocation fails. Since i965 can spill registers, this
should never happen. It's also not something that can cause a link
error.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_s
From: Ian Romanick
It used to be done in ir_to_mesa, and that was kind of a bad place.
I didn't change st_glsl_to_tgsi because there is some strange stuff
happening in the code that generates glDrawPixels shaders. It looked
like this would break horribly if I touched anything.
Signed-off-by: I
From: Ian Romanick
Track the calculated data in gl_shader_program instead of the
individual assembly shaders.
Signed-off-by: Ian Romanick
---
src/glsl/link_uniforms.cpp | 15 ++-
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/mtypes.h
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/glsl_types.cpp | 29 +
src/glsl/glsl_types.h |6 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 8587da0..d4385a6 100644
From: Ian Romanick
Rather than looking at the settings in individual assembly programs,
look at the settings in the top-level uniform values. The old code
was flawed because examining each shader stage in isolation could
allow inconsitent usage across stages (e.g., bind unit 0 to a
sampler2D in
From: Ian Romanick
Previously the fixed-function fragment shader was tracked as a
gl_program. This means that it shows up in the driver as a Mesa IR
program instead of as a GLSL IR program. If a driver doesn't generate
Mesa IR from the GLSL IR, that program is empty. If the program is
empty th
From: Ian Romanick
Signed-off-by: Ian Romanick
Cc: Eric Anholt
---
src/mesa/main/ff_fragment_shader.cpp |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 49a8af0..165230c 100644
---
From: Ian Romanick
Poking directly at the backing resources works only by luck. Core
Mesa code should only know about the gl_uniform_storage structure.
Soon other code that looks at samplers will use the gl_uniform_storage
structures instead of the data in the gl_program.
Signed-off-by: Ian Rom
Patches 01/14 through 03/14 was previously sent to the list. It
tickled a pre-existing bug (fixed by patch recently posted to the list
by Eric) on some Intel chipsets.
Patches 04/14 through 07/14 make the linker do some sampler tracking
that was previously done by ir_to_mesa. I suspect that the
Hey Christian,
Op 04-01-12 11:42, Christian König schreef:
On 03.01.2012 17:03, Maarten Lankhorst wrote:
Hi Christian,
2012/1/2 Christian König:
Hi Maarten,
first of all: Happy new Year and sorry for the late reply, have been on
vacation for the last week.
On 29.12.2011 16:41, Maarten Lank
if you don't have an /etc/drirc or ~/.drirc then all of the tests will
give a status of 'warn', this addes that warning to the ignored list.
---
tests/all.tests |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/all.tests b/tests/all.tests
index b713de0..f8d942b 100644
47 matches
Mail list logo
