Ian,
I just tried running Cogs (from the Humble Indie Bundle 3) and
discovered a terrible regression: it continually keeps recompiling
fragment shader 19 over and over again.
It looks like it was caused by commit 71990969 ("mesa: Rewrite the way
uniforms are tracked and handled").
Each tim
G45+ determine the data type to return based on the Surface Format, but
the original Gen4 hardware needs a bit more hand-holding.
For convenience, set the return format based on the destination register
type, as we already set that correctly.
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
On 11/08/2011 11:27 AM, Eric Anholt wrote:
> While not required by any particular spec version, mplayer was asking
> for L16 and hoping for actual L16 without checking. The 8 bits
> allocated led to 10-bit planar video data stored in the lower 10 bits
> giving only 2 bits of precision in video. W
On 11/08/2011 08:10 PM, Kenneth Graunke wrote:
> On 11/04/2011 04:41 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Fixes piglit's getfragdatalocation test.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/mesa/main/shader_query.cpp | 56
>>
>> src
On 11/04/2011 04:41 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Fixes piglit's getfragdatalocation test.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/main/shader_query.cpp | 56
>
> src/mesa/main/shaderapi.c | 20 --
> 2 f
On 11/08/2011 02:26 PM, Ian Romanick wrote:
> This is the next step in the uniform-rework saga. Right now the i965
> depends on ir_to_mesa doing some uniform related work for it. One of
> those pieces of work, which is duplicated in st_glsl_to_tgsi, is
> validating some resource usage against imp
On 11/04/2011 03:01 PM, Eric Anholt wrote:
> Here's a patch series to get GL_EXT_texture_integer partially working
> on i965, hidden under the GL 3.0 override. There's a bunch of support
> I think isn't finished yet, mostly because testing is in a bad state.
> A few things I noticed while looking
On 11/04/2011 03:01 PM, Eric Anholt wrote:
> This requires using a new fragment shader to get the integer color
> output, and a new vertex shader because #version has to match between
> the two.
Hm. The extra VS is rather unfortunate (it's exactly the same other
than the #version), but I suppose
On 11/04/2011 03:01 PM, Eric Anholt wrote:
> We're missing support for the software paths still, but basic
> rendering is working.
Yeah, we'll need to finish killing the software paths. Glad to see GPU
rendering working!
Comments below.
> ---
> src/mesa/drivers/dri/intel/intel_span.c |
From: Eric Anholt
Before, I was tracking the ir_variable * found for gl_FragColor or
gl_FragData[]. Instead, when visiting those variables, set up an
array of per-render-target fs_regs to copy the output data from. This
cleans up the color emit path, while making handling of multiple
user-defin
From: Eric Anholt
Before, I was tracking the ir_variable * found for gl_FragColor or
gl_FragData[]. Instead, when visiting those variables, set up an
array of per-render-target fs_regs to copy the output data from. This
cleans up the color emit path, while making handling of multiple
user-defin
From: Eric Anholt
When rendering to integer color buffers, we need to be careful to use
MRFs of the correct type when emitting color writes.
Signed-off-by: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +++
1 files changed, 7 insert
From: Eric Anholt
Previously, brw_type_for_base_type returned UD for array variables,
similar to structures. For structures, each field may have a different
type, so every field access must explicitly override the register's type
with that field's type. We chose to return UD in this case since
On 11/04/2011 03:01 PM, Eric Anholt wrote:
> Before, I was tracking the ir_variable * found for gl_FragColor or
> gl_FragData[]. Instead, when visiting those variables, set up an
> array of per-render-target fs_regs to copy the output data from. This
> cleans up the color emit path, while making
On 11/08/2011 12:30 PM, Jose Fonseca wrote:
[snip]
> Second, it would really help to clearly distinguish headers that are
> meant to be used exclusive by C++ with a different suffix (e.g.,
> .hpp). And leave .h for headers that are meant for joint C/C++
> consuption.
>
> Take e.g., ../glsl/program
- Original Message -
> On 11/08/2011 12:30 PM, Jose Fonseca wrote:
> > At the moment MSVC build's failing with the error
> >
> > mesa.lib(uniform_query.obj) : error LNK2001: unresolved external
> > symbol "int MESA_VERBOSE" (?MESA_VERBOSE@@3HA)
> > build\windows-x86-debug\gallium\targets\li
On 11/04/2011 03:01 PM, Eric Anholt wrote:
Before, I was tracking the ir_variable * found for gl_FragColor or
gl_FragData[]. Instead, when visiting those variables, set up an
array of per-render-target fs_regs to copy the output data from. This
cleans up the color emit path, while making handli
On 11/08/2011 12:30 PM, Jose Fonseca wrote:
At the moment MSVC build's failing with the error
mesa.lib(uniform_query.obj) : error LNK2001: unresolved external
symbol "int MESA_VERBOSE" (?MESA_VERBOSE@@3HA)
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll :
fatal error LNK1120: 1 un
See similar code for 3DSTATE_WM.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_vs_state.c |5 +++--
src/mesa/drivers/dri/i965/gen7_vs_state.c |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c
b/src/mesa/d
See similar code in gen7_wm_state.c.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_vs_state.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index e3234b5..
brw_wm_samplers actually enables any active samplers regardless of what
pipeline stage is using them, so it doesn't make much sense for it to be
WM-specific. So, rename it to "brw_samplers."
To properly generalize it, move sampler_count and sampler_offset from
brw_context::wm to a new brw_context
Like for the WM pull constants, we can merge the former prepare/emit
stages into one tracked state atom. Furthermore, the code that used to
handle the binding table was removed in the last commit, leaving some
rather silly looking short functions that can easily be folded in.
Signed-off-by: Kenne
Although the hardware supports separate binding tables for each pipeline
stage, we don't see much advantage over a single shared table.
Consider the contents of the binding table:
- Textures (16)
- Draw buffers (8)
- Pull constant buffers (1 for VS, 1 for WM)
OpenGL's texture bindings are global:
First, the texturing setup code is relevant for all pipeline stages,
while renderbuffer surfaces are only used by the WM.
Secondly, renderbuffer and texture setup depends on a different set of
dirty bits. There's no reason to walk the array of textures when
changing draw buffers, or vice-versa.
These were only split for historical reasons: brw_wm_constants used to
be the "prepare" step, while brw_wm_constant_surface was "emit". Now
that both happen at emit time, it makes sense to combine them.
Call the newly combined state atom "brw_wm_pull_constants" to indicate
help distinguish it fro
When reading the "brw_wm_constants" and "gen6_wm_constants" atoms
side-by-side, I initially failed to notice the crucial difference:
the Gen6 atoms are for Push Constants, while brw_wm_constants handles
Pull Constants. (Gen4/5 Push Constants are handled by "brw_curbe.")
Renaming these should clar
This code is fairly fragile, as it depends on the ordering of the
entries in the binding table, which will change soon.
Also, stop listening on the BRW_NEW_WM_CONSTBUF dirty bit as it's no
longer required.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 1
These fields control how many entries the hardware prefetches into the
state cache, so they only impact performance, not correctness. However,
it's not clear how to use this in a way that's beneficial.
According to the documentation, kernels "using a large number" of
entries may wish to program t
The comment states that brw_update_vs_constant_surface produces a
CACHE_NEW_SURF_BIND dirty bit, but it doesn't. In fact, that bit
no longer even exists.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c |3 +--
1 files changed, 1 insertions(+), 2 deletion
brw_vs_surfaces _produces_ the BRW_NEW_NR_VS_SURFACES dirty bit, so it
makes no sense for it to subscribe to it.
Fixes an assertion failure in many piglit tests when INTEL_DEBUG is set:
brw_state_upload.c:484: void brw_upload_state(struct brw_context *):
Assertion `!check_state(&examined, &gen
Comparing brw_upload_vs_pull_constants and brw_upload_wm_pull_constants,
it became evident that something was amiss: the VS code had both
CACHE_NEW_VS_PROG and BRW_NEW_VERTEX_PROGRAM, while the WM code was
missing the CACHE_NEW_WM_PROG flag.
Not observed to fix anything, but likely necessary.
Sig
Patches 1 and 2 are simple bug fixes.
Patches 3-10 significantly rework our binding table setup. They disable
prefetching of SURFACE_STATE entries, use a single binding table for all
pipeline stages, and most importantly, pave the way for getting textures
into the VS binding table. This may impa
From: Ian Romanick
These checks are now performed by the linker.
Signed-off-by: Ian Romanick
---
src/mesa/program/ir_to_mesa.cpp| 55
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 51 --
2 files changed, 0 insertions(+), 106 d
From: Ian Romanick
This is also done in ir_to_mesa and st_glsl_to_tgsi, but that code
will be removed soon.
Signed-off-by: Ian Romanick
---
src/glsl/linker.cpp | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.c
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/link_uniforms.cpp | 19 +--
src/mesa/main/mtypes.h |7 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 11447f3..ca5da30 100
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/link_uniforms.cpp | 29 -
src/mesa/main/mtypes.h |3 +++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index b9d5361..11447
This is the next step in the uniform-rework saga. Right now the i965
depends on ir_to_mesa doing some uniform related work for it. One of
those pieces of work, which is duplicated in st_glsl_to_tgsi, is
validating some resource usage against implementation limits. This
patch series pulls that co
On 8 November 2011 12:30, Jose Fonseca wrote:
> At the moment MSVC build's failing with the error
>
> mesa.lib(uniform_query.obj) : error LNK2001: unresolved external symbol
> "int MESA_VERBOSE" (?MESA_VERBOSE@@3HA)
> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal
> erro
On Tue, 8 Nov 2011 10:39:45 -0800, Kenneth Graunke
wrote:
> Now that we have vtable entries in place, we should use them. This
> allows us to drop the cut and pasted Gen7 brw_tracked_state atoms as
> they now do exactly the same thing as their brw_wm_surface_state
> counterparts.
>
> Signed-of
On 11/08/2011 12:30 PM, Jose Fonseca wrote:
> Second, it would really help to clearly distinguish headers that are meant to
> be used exclusive by C++ with a different suffix (e.g., .hpp). And leave .h
> for headers that are meant for joint C/C++ consuption.
>
> Take e.g., ../glsl/program.h, are
On 11/04/2011 03:01 PM, Eric Anholt wrote:
We don't get to use the 3-component formats, but faking of RGB with
RGBA seems to be working.
---
src/mesa/drivers/dri/intel/intel_context.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/src/mesa/
At the moment MSVC build's failing with the error
mesa.lib(uniform_query.obj) : error LNK2001: unresolved external symbol "int
MESA_VERBOSE" (?MESA_VERBOSE@@3HA)
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error
LNK1120: 1 unresolved externals
and trying to fix se
On 11/04/2011 03:01 PM, Eric Anholt wrote:
Texture filtering is not supported on floating-point textures until
gen5, which showed up as failures in texwrap in particular.
---
src/mesa/drivers/dri/intel/intel_extensions.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
d
While not required by any particular spec version, mplayer was asking
for L16 and hoping for actual L16 without checking. The 8 bits
allocated led to 10-bit planar video data stored in the lower 10 bits
giving only 2 bits of precision in video. While it was an amusing
effect, give them what they
We want to be able to support some formats for texturing that we can't
render to, which means that some choices for RenderbufferStorage end
up being incomplete (for example, L8 currently). For these, where we
don't render to them, we don't want to have to make up an rb->DataType
that's only used f
On 11/08/2011 07:23 AM, Brian Paul wrote:
Some of these were existing warnings (e.g., cols and rows in
_mesa_uniform_matrix) that I had meant to fix in a follow-on patch. In
all the chaos of getting this code read to commit, I forgot. Thanks for
following up.
Reviewed-by: Ian Romanick
-
Hi,
Not sure if it's directly related to this patch, but I got memory
corruption with 32-bit Lightsmark, bisected to corresponding commit.
I'm attaching related part of the valgrind log.
Vadim
==2800== Invalid write of size 4
==2800==at 0x4D7C510: memcpy (mc_replace_strmem.c:643)
==2800==
>From the GLSL 1.30 spec, section 8.7 "Texture Lookup Functions":
"In all functions below, the bias parameter is optional for fragment
shaders. The bias parameter is not accepted in a vertex shader."
This was a cut and paste mistake.
Signed-off-by: Kenneth Graunke
---
src/glsl/builtins/profil
Now that we have vtable entries in place, we should use them. This
allows us to drop the cut and pasted Gen7 brw_tracked_state atoms as
they now do exactly the same thing as their brw_wm_surface_state
counterparts.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state_upload.c
Gen7+ SURFACE_STATE is different from Gen4-6, so we need separate
per-generation functions for creating and updating it. However, the
usage is the same, and callers just want to utilize the appropriate
functions with minimal pain. So, put them in the vtable.
Since these take a brw_context pointe
On 11/07/2011 11:12 AM, Ian Romanick wrote:
From: Ian Romanick
This prevents other code from seeing a swizzle of the 16th component
of a vector, for example.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42517
On 7 November 2011 11:12, Ian Romanick wrote:
> From: Ian Romanick
>
> This prevents other code from seeing a swizzle of the 16th component
> of a vector, for example.
>
> NOTE: This is a candidate for the 7.11 branch.
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/sho
On Tue, Nov 8, 2011 at 10:59 AM, Paul Berry wrote:
> Commit 1401b96b (radeon: cleanup radeon shared code after r300 and
> r600 classic drivers removal) removed the file
> src/mesa/drivers/dri/radeon/server/radeon.h, but it left behind the
> symlink which was used to share that file into the
> src/
Commit 1401b96b (radeon: cleanup radeon shared code after r300 and
r600 classic drivers removal) removed the file
src/mesa/drivers/dri/radeon/server/radeon.h, but it left behind the
symlink which was used to share that file into the
src/mesa/drivers/dri/r200/server directory.
This patch removes th
On Tue, 2011-11-08 at 07:47 -0800, Jose Fonseca wrote:
> tgsi_exec is simple; llvm is fast; and tgsi_sse2 ends up being neither. So
> really serves no purpose and is currently broken.
>
Sounds good to me!
Keith
___
mesa-dev mailing list
mesa-dev@list
tgsi_exec is simple; llvm is fast; and tgsi_sse2 ends up being neither. So
really serves no purpose and is currently broken.
Patch is big, so please see it in:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=remove-tgsi-sse2&id=aa7a6ec9d2bba743166c93ab15ba2e0872aff0d2
___
On 11/07/2011 12:43 PM, Morgan Armand wrote:
Here is the updated patch.
Pushed. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/mesa/main/uniform_query.cpp | 12
src/mesa/main/uniforms.h|2 +-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 2ff8207..388e81a 100644
--- a/src/mesa/main/uniform_query.cpp
+
- Original Message -
> From: Dave Airlie
>
> This adds timer query support, though I'm not 100% sure about the bin
> stuff
> if we have multiple queries in flight, maybe it needs a linked list,
> suggestions
> welcome.
I think that taking the time interval to the last rasterization task
Hi everyone,
I'm currently looking on mesa source code for having informations
about graphic rendering. For example to get the amount of
triangles/tiles needed to render one frame.
I also want to have informations about the amount of cycles needed to
render triangles/tiles for each stages of t
https://bugs.freedesktop.org/show_bug.cgi?id=8645
--- Comment #9 from Wolfgang Draxinger
2011-11-08 06:42:35 PST ---
Indeed a single drawable may have serveral OpenGL render contexts on it, which
also may be active in multiple threads at the same time. This is a common setup
to allow for such th
On 8 November 2011 05:15, Marek Olšák wrote:
> On Tue, Nov 8, 2011 at 7:28 AM, Paul Berry
> wrote:
> > This patch modifies the GLSL linker to assign additional slots for
> > varying variables used by transform feedback, and record the varying
> > slots used by transform feedback for use by the d
On Tue, Nov 8, 2011 at 7:28 AM, Paul Berry wrote:
> This patch modifies the GLSL linker to assign additional slots for
> varying variables used by transform feedback, and record the varying
> slots used by transform feedback for use by the driver back-end.
>
> This required modifying assign_varyin
63 matches
Mail list logo
