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 bac
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 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 it doesn't
>
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
Descri
- Original Message -
> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger
> 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 enforc
On 01.03.2013 11:30, Jose Fonseca wrote:
> - Original Message -
>> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger
>> 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
- Original Message -
> On 01.03.2013 11:30, Jose Fonseca wrote:
> > - Original Message -
> >> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger
> >> wrote:
> >>> Hi,
> >>>
> >>> there is some sloppy usage of bind flags in the opengl state tracker
> >>> (that is, resources get u
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 co
Am 01.03.2013 08:50, schrieb Andreas Boll:
> 2013/3/1 :
>> From: Roland Scheidegger
>>
>> 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 be difficult,
>> plus EXT_p
From: Roland Scheidegger
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 glsl-1.40-tf-no-position.
Not quite sure
From: Roland Scheidegger
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 sampler views
(same reaso
On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
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 providing
>> > t
Signed-off-by: Jon TURNEY
---
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
--- a/src/mesa/main/tests/Makefile.am
+++ b/src/mesa/main/t
2013/3/1 Jon TURNEY :
> Signed-off-by: Jon TURNEY
Reviewed-by: Andreas Boll
> ---
> 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 10
---
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
+++ b/src/
---
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:
R600_DEBU
---
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
--- a/src/galli
---
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
+++ b/src/gall
---
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
@@ -28
On Fri, Mar 1, 2013 at 7:28 AM, Jon TURNEY wrote:
> Signed-off-by: Jon TURNEY
> ---
Candidate for the stable branch?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Roland Scheidegger
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 debatable).
There is ce
Looks good, just minor things below.
Reviewed-by: Brian Paul
On 03/01/2013 11:41 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
Something I never got around to implement, but this is the tgsi execution
side for implementing texel offsets (for ordinary texturing) and explicit
derivativ
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 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 up the pigl
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:
intel_miptree_create()
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 shade
On 1 March 2013 02:02, 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 fra
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 wrote:
> On 26 February 2013 02:10, Chris Forbes wrote:
>>
>> This series adds the core mesa bits for ARB_t
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 wrote:
> The minmax regression is addressed by my followup series, which adds
> the internalformat_query interactions.
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
Date: Sat Mar 2 09:10:25 2013 +1300
fixup glPopAttrib(GL_TEXTURE_BIT)
diff --git a/src
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 flink
Am 01.03.2013 19:54, schrieb Brian Paul:
> Looks good, just minor things below.
>
> Reviewed-by: Brian Paul
>
> On 03/01/2013 11:41 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Something I never got around to implement, but this is the tgsi execution
>> side for implementing t
https://bugs.freedesktop.org/show_bug.cgi?id=61364
Martin Stolpe changed:
What|Removed |Added
CC||martinsto...@gmail.com
--
You are recei
On 02/27/2013 10:19 PM, John Kåre Alsaker wrote:
On Mon, Feb 25, 2013 at 8:55 PM, Ian Romanick 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 the spec template incl
On Fri, Mar 1, 2013 at 10:01 PM, Ian Romanick wrote:
> On 02/27/2013 10:19 PM, John Kåre Alsaker wrote:
>>
>> On Mon, Feb 25, 2013 at 8:55 PM, Ian Romanick wrote:
>>>
>>> Also... are there piglit tests coming?
>>
>> Not unless you convince me otherwise. I don't think I'll be able to
>> verify tha
https://bugs.freedesktop.org/show_bug.cgi?id=61364
--- Comment #2 from John Kåre Alsaker ---
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 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 we will overwr
On Fri, Mar 1, 2013 at 4:34 PM, Martin Andersson 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 we will overwr
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 su
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 ther
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
---
include/pci_ids/i965_pci_ids.h | 18 +-
src/mesa/drive
From: Roland Scheidegger
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 glsl-1.40-tf-no-position with
From: Roland Scheidegger
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 anyway.
---
.../draw/draw_pt_fetch_shade_pipeline_llvm.c | 42 +
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
b/src/mesa/state_tracker/st_g
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
b/src/gallium/targets/dri-vmwgfx/Ma
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paul 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 a/src/gallium/tar
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paul 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 TGSI_OPCODE_LRP? Either
way:
On 03/01/2013 05:23 PM, Matt Turner wrote:
On Fri, Mar 1, 2013 at 3:56 PM, Brian Paul 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_
---
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 +204
---
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
+++ b/sr
On 03/01/2013 04:52 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
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 anyway.
---
.../dra
On 1 March 2013 15:14, Ian Romanick 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. I also gathered s
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, sen
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 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty 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 test {pass,fail,crash}
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
+++ b/s
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger 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
>> b/src/mesa/s
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #6 from Dennis Heuer ---
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 glXQueryCurrentR
https://bugs.freedesktop.org/show_bug.cgi?id=61416
--- Comment #3 from Mike Lothian ---
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 when X was running
https://bugs.freedesktop.org/show_bug.cgi?id=61416
--- Comment #4 from Mike Lothian ---
Both tests were run via ssh so it seems the issue only appears when X is the
active VT
--
You are receiving this mail because:
You are the assignee for the bug.
__
On March 1, 2013 06:24:01 PM Matt Turner wrote:
> On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
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
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
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
is
68 matches
Mail list logo
