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
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önigdeathsim...@vodafone.de:
Hi Maarten,
first of all: Happy new Year and sorry for the late reply, have been on
vacation for the last week.
On
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
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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.
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
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
From: Ian Romanick ian.d.roman...@intel.com
Track the calculated data in gl_shader_program instead of the
individual assembly shaders.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/link_uniforms.cpp | 15 ++-
src/mesa/main/ff_fragment_shader.cpp
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
All three of these commits could probably be squashed into one.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
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
From: Ian Romanick ian.d.roman...@intel.com
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 ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 60
On 01/06/2012 04:54 PM, Kenneth Graunke wrote:
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
Makefile|2 +-
configs/default |4 +-
docs/relnotes-7.12.html | 83 ---
docs/relnotes-8.0.html | 83
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
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
Series is
Reviewed-by: Eric Anholt e...@anholt.net
pgpjfhSfYYkmc.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, 7 Jan 2012 14:37:34 -0700, Brian Paul bri...@vmware.com wrote:
Since it returns uint values, not int.
Series is:
Reviewed-by: Eric Anholt e...@anholt.net
pgpofeFGAiUZt.pgp
Description: PGP signature
___
mesa-dev mailing list
---
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
+++
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
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
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
---
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
---
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
---
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen6_depthstencil.c
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
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 kenn...@whitecape.org
---
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
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen6_gs_state.c |3 +--
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_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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen7_vs_state.c |3 +--
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
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_sf_state.c |2 ++
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 kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen7_wm_state.c |3 ++-
1 files
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.
https://bugs.freedesktop.org/show_bug.cgi?id=44564
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, Jan 8, 2012 at 5:15 PM, Vincent Lejeune v...@ovi.com 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
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
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
GLSL spec boneheadedly says (a ^^ a) must actually be evaluated.
Signed-off-by: Matt Turner matts...@gmail.com
---
Fortunately, shaders that do this are even more boneheaded.
src/glsl/opt_algebraic.cpp |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
On Sun, Jan 8, 2012 at 10:44 PM, Matt Turner matts...@gmail.com wrote:
GLSL spec boneheadedly says (a ^^ a) must actually be evaluated.
Signed-off-by: Matt Turner matts...@gmail.com
---
On second thought, maybe the better thing to do here is to evaluate $a
twice, which in most cases would be
43 matches
Mail list logo
