On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
Hi Topi,
The second more or less questionable part is the support for creating YUV
buffers. In order to test for YUV sampling one needs a way of providing them
for the EGL stack. Here I chose to augment the dri driver backing
Hi,
opt_constant_variable was marking a variable as constant as long as there
was exactly one constant assignment to it, but did not take into account
that this assignment might be in a dynamic branch or a loop.
Was happening on a fragment shader like this:
uniform float mode;
float func (float
On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger srol...@vmware.com wrote:
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the bind
flag set).
We'd really like to enforce these flags to be honored but
Hi,
A fix for lower_jumps progress reporting, very much like similar in
c1e591eed:
http://cgit.freedesktop.org/mesa/mesa/commit/src/glsl/lower_variable_index_to_cond_assign.cpp?id=c1e591eed
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
glsl-lower-jumps-fix.diff
- Original Message -
On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the bind
flag set).
We'd really like to
On 01.03.2013 11:30, Jose Fonseca wrote:
- Original Message -
On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the
- Original Message -
On 01.03.2013 11:30, Jose Fonseca wrote:
- Original Message -
On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used
On 02/28/2013 03:52 AM, Kristian Høgsberg wrote:
---
include/GL/internal/dri_interface.h| 14 +++-
src/mesa/drivers/dri/intel/intel_regions.c | 33 +++
src/mesa/drivers/dri/intel/intel_regions.h | 6
src/mesa/drivers/dri/intel/intel_screen.c | 53
On 02/28/2013 03:52 AM, Kristian Høgsberg wrote:
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index b5cd04a..1b42a98 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -451,6 +451,46 @@ static
Am 01.03.2013 08:50, schrieb Andreas Boll:
2013/3/1 srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which will
From: Roland Scheidegger srol...@vmware.com
With glsl 1.40 writing position is not required (useful for transform
feedback, though in fact it's still possible to rasterize such geometry
even if the results aren't too well defined).
Prevents crashes in that case. Fixes piglit
From: Roland Scheidegger srol...@vmware.com
Since c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2 llvmpipe checks if it's
actually legal to create a surface. The opengl state tracker doesn't quite
obey this so for now just warn instead of assert.
Also warn instead of disabled assert when creating
On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, Feb 26, 2013 at 04:05:25PM +, Tom Cooksey wrote:
Hi Topi,
The second more or less questionable part is the support for creating YUV
buffers. In order to test for YUV sampling one needs a way of
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
src/mesa/main/tests/Makefile.am |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/tests/Makefile.am b/src/mesa/main/tests/Makefile.am
index 012b353..4acc815 100644
---
2013/3/1 Jon TURNEY jon.tur...@dronecode.org.uk:
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
Reviewed-by: Andreas Boll andreas.boll@gmail.com
---
src/mesa/main/tests/Makefile.am |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
---
src/gallium/drivers/r600/r600_texture.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index acea19d..aefc40f 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++
---
src/gallium/drivers/r600/compute_memory_pool.c|1 +
src/gallium/drivers/r600/evergreen_compute.h |2 +-
src/gallium/drivers/r600/evergreen_compute_internal.c |1 +
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/drivers/r600/r600_pipe.h
Only the disassembler is used to dump shaders. Here's a few examples
how to use R600_DEBUG.
Log compute info:
R600_DEBUG=compute
Dump all shaders:
R600_DEBUG=fs,vs,gs,ps,cs
Dump pixel shaders only:
R600_DEBUG=ps
Disable Hyper-Z:
R600_DEBUG=nohyperz
Disable the LLVM backend:
---
src/gallium/drivers/r600/r600_asm.c | 239 ---
src/gallium/drivers/r600/r600_asm.h |1 -
2 files changed, 240 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 283682f..805467e 100644
---
---
src/gallium/auxiliary/util/u_dump_state.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_dump_state.c
b/src/gallium/auxiliary/util/u_dump_state.c
index d7df5b4..2f28f3c 100644
--- a/src/gallium/auxiliary/util/u_dump_state.c
+++
---
src/gallium/drivers/r600/r600_asm.c |8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 805467e..4e0cd01 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@
On Fri, Mar 1, 2013 at 7:28 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
Candidate for the stable branch?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
From: Roland Scheidegger srol...@vmware.com
Something I never got around to implement, but this is the tgsi execution
side for implementing texel offsets (for ordinary texturing) and explicit
derivatives for sampling (though I guess the ordering of the components
for the derivs parameters is
Looks good, just minor things below.
Reviewed-by: Brian Paul bri...@vmware.com
On 03/01/2013 11:41 AM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Something I never got around to implement, but this is the tgsi execution
side for implementing texel offsets (for
On 02/28/2013 03:45 PM, Chad Versace wrote:
This patch (1) extracts from intel_miptree_create() the spaghetti logic
that selects the tiling format, (2) rewrites that spaghetti into a lucid
form, and (3) moves it to a new function, intel_miptree_choose_tiling().
No behavioral change.
As a bonus,
On 26 February 2013 02:10, Chris Forbes chr...@ijw.co.nz wrote:
This series adds the core mesa bits for ARB_texture_multisample, and
support
in the i965 driver for Gen6 and Gen7.
I've addressed the issues that were raised for V3, and also fixed some
other
bugs which I found while beefing
On 02/28/2013 03:45 PM, Chad Versace wrote:
Miptree creation has a workaround for separate stencil buffers. After the
layout is created, we override the tiling to I915_NONE and align it 64x64,
the size of a W-tile.
Before this patch, the workaround occurs in an odd place:
On 03/01/2013 02:02 AM, Aras Pranckevicius wrote:
Hi,
opt_constant_variable was marking a variable as constant as long as
there was exactly one constant assignment to it, but did not take into
account that this assignment might be in a dynamic branch or a loop.
Was happening on a fragment
On 1 March 2013 02:02, Aras Pranckevicius a...@unity3d.com wrote:
Hi,
opt_constant_variable was marking a variable as constant as long as there
was exactly one constant assignment to it, but did not take into account
that this assignment might be in a dynamic branch or a loop.
Was
On 03/01/2013 11:00 AM, Ian Romanick wrote:
On 02/28/2013 03:45 PM, Chad Versace wrote:
Miptree creation has a workaround for separate stencil buffers. After the
layout is created, we override the tiling to I915_NONE and align it 64x64,
the size of a W-tile.
Before this patch, the
The minmax regression is addressed by my followup series, which adds
the internalformat_query interactions.
Do I need to fold that into this one?
On Sat, Mar 2, 2013 at 7:59 AM, Paul Berry stereotype...@gmail.com wrote:
On 26 February 2013 02:10, Chris Forbes chr...@ijw.co.nz wrote:
This
I've had a quick look at the push-pop-texture-state regression, and
that looks like a real bug I've introduced. I'm looking into it.
On Sat, Mar 2, 2013 at 8:44 AM, Chris Forbes chr...@ijw.co.nz wrote:
The minmax regression is addressed by my followup series, which adds
the internalformat_query
I missed a case in attrib.c; this small patch should be folded in with
the rest of the changes which add support for the new targets:
commit 8b16367bab07cfe2eb44cc96a22bb925593b1e20
Author: Chris Forbes chr...@ijw.co.nz
Date: Sat Mar 2 09:10:25 2013 +1300
fixup glPopAttrib(GL_TEXTURE_BIT)
The problem is that we mix bo handles and flinked names in the hash
table. Because kms type handles are not flinked they should not be
added to the hash table. If we do that we will sooner or later
get a situation where we will overwrite a correct entry because
the bo handle was the same as a
Am 01.03.2013 19:54, schrieb Brian Paul:
Looks good, just minor things below.
Reviewed-by: Brian Paul bri...@vmware.com
On 03/01/2013 11:41 AM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Something I never got around to implement, but this is the tgsi execution
https://bugs.freedesktop.org/show_bug.cgi?id=61364
Martin Stolpe martinsto...@gmail.com changed:
What|Removed |Added
CC|
On 02/27/2013 10:19 PM, John Kåre Alsaker wrote:
On Mon, Feb 25, 2013 at 8:55 PM, Ian Romanick i...@freedesktop.org wrote:
Also... are there piglit tests coming?
Not unless you convince me otherwise. I don't think I'll be able to
verify that said tests work however.
More recent versions of
https://bugs.freedesktop.org/show_bug.cgi?id=61364
--- Comment #2 from John Kåre Alsaker john.kare.alsa...@gmail.com ---
Created a LLVM bug report since it looks a LLVM issue:
http://llvm.org/bugs/show_bug.cgi?id=15410
--
You are receiving this mail because:
You are the assignee for the bug.
On Fri, Mar 1, 2013 at 4:34 PM, Martin Andersson g02ma...@gmail.com wrote:
The problem is that we mix bo handles and flinked names in the hash
table. Because kms type handles are not flinked they should not be
added to the hash table. If we do that we will sooner or later
get a situation where
On Fri, Mar 1, 2013 at 4:34 PM, Martin Andersson g02ma...@gmail.com wrote:
The problem is that we mix bo handles and flinked names in the hash
table. Because kms type handles are not flinked they should not be
added to the hash table. If we do that we will sooner or later
get a situation where
Hi,
I've generated a patch from the master branch of my llvm tree
(http://cgit.freedesktop.org/~tstellar/llvm/) that can be applied against
the LLVM 3.2 code base to add the R600 backend.
For the Mesa 9.1 release, this patch is required in order to use the
radeonsi driver, experimental compute
Since last September I've been gradually working on an extension to let
applications query information about the renderer before (and after)
creating a context. I've talked it over with a few ISVs and with
various other folks. I also gathered some input from folks at FOSDEM
after my talk
The second digit was off by one, which meant we accidentally treated
GT(n) as GT(n-1). This also meant no support for GT1 at all.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
include/pci_ids/i965_pci_ids.h | 18
From: Roland Scheidegger srol...@vmware.com
It seems easiest (and best) if we simply skip all the later stages
(after stream output).
(This is different to the llvm case at least for now where we will
simply try to render garbage, though both behaviors should be correct.)
Fixes piglit
AFAICT, all gallium drivers implemente TGSI_OPCODE_LRP.
Tested with softpipe, llvmpipe, svga drivers.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
Even when we don't have LLVM since there's other C++ code
in the resulting DRI driver object.
---
src/gallium/targets/dri-vmwgfx/Makefile.am |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/gallium/targets/dri-vmwgfx/Makefile.am
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paul bri...@vmware.com wrote:
Even when we don't have LLVM since there's other C++ code
in the resulting DRI driver object.
---
src/gallium/targets/dri-vmwgfx/Makefile.am |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paul bri...@vmware.com wrote:
AFAICT, all gallium drivers implemente TGSI_OPCODE_LRP.
Tested with softpipe, llvmpipe, svga drivers.
Oh yeah, looks like it. Cool. Maybe a comment to note the argument
ordering difference between ir_triop_lrp and
On 03/01/2013 05:23 PM, Matt Turner wrote:
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paulbri...@vmware.com wrote:
AFAICT, all gallium drivers implemente TGSI_OPCODE_LRP.
Tested with softpipe, llvmpipe, svga drivers.
Oh yeah, looks like it. Cool. Maybe a comment to note the argument
ordering
---
src/mesa/program/ir_to_mesa.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 5432323..486cf46 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2045,6
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..c41b583 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++
On 03/01/2013 04:52 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Similar fix to what is done for the non-llvm case, we could otherwise still
hit the stages (near certainly with gs) which crash. It is probably a much
better idea to skip trying to draw at that point
On 1 March 2013 15:14, Ian Romanick i...@freedesktop.org wrote:
Since last September I've been gradually working on an extension to let
applications query information about the renderer before (and after)
creating a context. I've talked it over with a few ISVs and with various
other folks.
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Make sure that you have recent patches, some problems with R7xx chips
were fixed yesterday. Then please check if there are any regressions
with piglit tests (as compared to the piglit results with R600_SB=0). If
there are regressions, send
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..c41b583 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=61647
Roland Scheidegger srol...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
isn't to friendly...Id appreciate some help with this.
If you click the
On 03/01/2013 04:36 PM, Brian Paul wrote:
---
src/mesa/program/ir_to_mesa.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 5432323..486cf46 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #6 from Dennis Heuer dh-b...@online.de ---
the check fails at glsl. as far as i understand, the missing support for
shaders is the reason. possibly i'm wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
On 03/01/2013 03:14 PM, Ian Romanick wrote:
New Procedures and Functions
Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
int renderer, int attribute,
unsigned int *value);
Bool
https://bugs.freedesktop.org/show_bug.cgi?id=61416
--- Comment #3 from Mike Lothian m...@fireburn.co.uk ---
There's a chance this might not be related to PRIME
I've tested this on another system that uses a Radeon 4200 (I know it doesn't
work with the R600 backend yet)
The interesting thing was
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
isn't to
On 03/02/2013 05:15 AM, Sebastien Caty wrote:
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Make sure that you have recent patches, some problems with R7xx chips
were fixed yesterday. Then please check if there are any regressions
with piglit tests (as compared to the piglit results with
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with
65 matches
Mail list logo
