On Friday 15 February 2013 02:21:56 Vadim Girlin wrote:
> I pushed the fix for one problem that I noticed with FlightGear to that
> branch, please test if it helps with your lockups as well.
I have a commit d6327a397ed54b3b2e40d521a762a380c25cba48 but the lockups still
occur:
[ 125.082988] rad
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
"LLVM backend is the future" is a pretty abstract argument. I prefer to
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
"LLVM backend is the future
Just wow! It would be crime not to merge this branch, with the sole reason
"LLVM is the future".
Fantastic work Vadim.
On Fri, Feb 15, 2013 at 1:00 PM, Vadim Girlin wrote:
> On 02/14/2013 02:42 PM, Christian König wrote:
>
>> Hi Vadim,
>>
>> nice work, I think you've made quite a progress here,
On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
> On 02/14/2013 02:42 PM, Christian König wrote:
> >
> > nice work, I think you've made quite a progress here, but on the other
> > hand it should be clear that the LLVM backend is the future and we
> > should concentrate on that.
>
> "LLVM b
From: Michel Dänzer
Based on r600g commit 2b9659c9e627ad03160899b8be04f96307d098eb .
Fixes crashes with 4 piglit tests which are now hitting these formats.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_state.c | 95
From: Michel Dänzer
7 more little dwarves^W piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/r600_texture.c | 3 +--
src/gallium/drivers/radeonsi/si_state.c | 14 +-
2 files changed, 10 insertions(+), 7 delet
On Fri, Feb 15, 2013 at 03:00:24PM +0400, Vadim Girlin wrote:
> On 02/14/2013 02:42 PM, Christian König wrote:
> >Hi Vadim,
> >
> >nice work, I think you've made quite a progress here, but on the other
> >hand it should be clear that the LLVM backend is the future and we
> >should concentrate on th
- Original Message -
> From: Roland Scheidegger
>
> (Though it looks glsl won't emit it.)
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
> b/src/gallium/auxiliary/gallivm/lp_bld_t
- Original Message -
> From: Roland Scheidegger
>
> Need to take the type into account. Also, if we want to allow
> mov's with modifiers we need to pick a type (assume float).
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 54
> ++-
> 1 file changed, 5
I think the bad result of llvm can be explained because of the lack of muladd
support currently. Unigine 3.0 has a lot of geometry and i suspect vertex
shader being almost twice bigger than they are in tgsi case does not help.
Fwiw with an hd 6950 I have the same performance in unigine 3 high, m
Am 15.02.2013 15:55, schrieb Jose Fonseca:
>
>
> - Original Message -
>> From: Roland Scheidegger
>>
>> Need to take the type into account. Also, if we want to allow
>> mov's with modifiers we need to pick a type (assume float).
>> ---
>> src/gallium/auxiliary/gallivm/lp_bld_tgsi.c |
From: Roland Scheidegger
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
v2: don't allow all modifiers on all type, in particular don't allow
absolute on non-float types and don't allow negate on unsigned.
Also treat UADD
I think that we should probably allow signed everywhere.
The operation and result may be unsigned, but the arguments may need to be
negated to become unsigned.
Imagine:
int a = -1;
unsigned b = 10 / (unsigned)-a;
That is
MOV TEMP[0], INT IMM{-1}
UDIV TEMP[1], UINT IMM{10}, -TEMP
Allowing that looks very odd to me, and it seems no API does that.
FWIW the MOV with negation can't work like that (not in a consistent way
at least) since for ordinary temps etc. we don't know the type (hence
arguements are considered floats).
I think if you'd really want to do something like that
On Thu, 14 Feb 2013 20:39:36 -0800
Zack Rusin wrote:
> GLX_INTEL_swap_event is broken on the server side, where it's
> currently unconditionally enabled. This completely breaks
> systems running on drivers which don't support that extension.
> There's no way to test for its presence on this side,
Fair enough. I don't feel strongly either way.
Jose
- Original Message -
> Allowing that looks very odd to me, and it seems no API does that.
> FWIW the MOV with negation can't work like that (not in a consistent way
> at least) since for ordinary temps etc. we don't know the type (hence
I have two machines {bubbles, murron} doing nightly dashboard builds of
VTK using nightly Mesa.
Each machine does a build of VTK using swrast and one with OSMesa.
Many tests pass on both machines when using OSMesa and fail on both
machines using swrast.
This is an example :
Test failing on bubb
On 02/14/2013 09:39 PM, Zack Rusin wrote:
GLX_INTEL_swap_event is broken on the server side, where it's
currently unconditionally enabled. This completely breaks
systems running on drivers which don't support that extension.
There's no way to test for its presence on this side, so instead
of disa
From: Michel Dänzer
4 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/
When a trace_surface object is created in trace_surf_create() we
weren't correctly setting the surface's context pointer. Instead of
it being the trace context, it was the wrapped driver's context.
This caused things to blow up sometimes during surface deallocation.
---
src/gallium/drivers/trace/
To help catch mixed up context pointer bugs in the future, add a
trace_context_check() function and some new assertions.
---
src/gallium/drivers/trace/tr_context.c | 15 +++
src/gallium/drivers/trace/tr_context.h |7 +++
src/gallium/drivers/trace/tr_texture.c |1 +
3 file
Both patches look great to me.
Reviewed-by: Jose Fonseca
- Original Message -
> To help catch mixed up context pointer bugs in the future, add a
> trace_context_check() function and some new assertions.
> ---
> src/gallium/drivers/trace/tr_context.c | 15 +++
> src/galliu
tex->Sright and tex->Ttop are initialized during texture allocation.
This fixes depth buffer blitting failures in khronos conformance tests
when run on desktop GL 3.0.
Note: This is a candidate for stable branches.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/common/meta.c | 17 ---
> Seems like we should also fix the server to not advertise the extension
> if the driver doesn't have the appropriate hooks implemented. But I
> have no problem with doing this on the client side too.
I've sent a patch last night to xorg-devel to handle it. But since it's likely
to only be inc
> Should we also test for the swrast driver?
That is actually handled by a hack in the Xserver.
http://cgit.freedesktop.org/xorg/xserver/commit/glx?id=988d7ace19a009991a4528e783d1a94c2444c66a
The extension was manually removed from the list of extensions that are at all
available to the software
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should co
On 02/15/2013 04:06 PM, Michel � wrote:
On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concent
On 02/15/2013 06:31 PM, Tom Stellard wrote:
On Fri, Feb 15, 2013 at 03:00:24PM +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future
On 12 February 2013 18:59, Jordan Justen wrote:
> Previously when an input varying was optimized out of the
> FS we would still retain it as an output of the VS.
>
> We now build a hash of live FS input varyings rather
> than looking in the FS symbol table. (The FS symbol table
> will still conta
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should co
https://bugs.freedesktop.org/show_bug.cgi?id=60938
Priority: medium
Bug ID: 60938
Keywords: regression
CC: bri...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit
interpolation-no
https://bugs.freedesktop.org/show_bug.cgi?id=60943
Priority: medium
Bug ID: 60943
Assignee: mesa-dev@lists.freedesktop.org
Summary: /usr/include/xorg/fb.h(98): catastrophic error: #error
directive: "GLYPHPADBYTES must be 4"
S
From: Christopher James Halse Rogers
_mesa_delete_renderbuffer does not call the driver-specific
renderbuffer delete function, so the blorp code was leaking the
Intel-specific bits, including some GEM objects.
Call the renderbuffer's ->Delete() method instead, which does the
right thing.
Fixes
The desktop spec asks for gl_PointCoord to be defined only when
GL_POINT_SPRITE is enabled, and it's undefined otherwise (why?!). The
ES spec doesn't have GL_POINT_SPRITE and gl_PointCoord is always
defined. So just make our implementation always give you gl_PointCoord
regardless of the enable.
We were correctly relaying the smear from MOV's src, but if the MOV
didn't do a smear, we don't want to smash the smear value from the
instruction being propagated into. Prevents a regression in the
upcoming UBO change.
---
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp |3 ++-
1 file
We could potentially do some CSE even when the dst types aren't the same
on gen6 where there is no implicit dst type conversion iirc, or in the
case of uniform pull constant loads where the dst type doesn't impact
what's stored. But it's not worth worrying about.
---
src/mesa/drivers/dri/i965/brw
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c1ccd92..35cdc6a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b
Improves on a major performance regression for the dolphin wii emulator
from its move to using UBOs. Performance in the UBO codepath (as
replayed through apitrace) is up 21.1% +/- 2.3% (n=26/29).
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git
This should fix the register allocation explosion on the GLES 3.0
test on gen6.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 63 +-
src/mesa/drivers/dri/i965/brw_fs.h |1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 28 ++--
3 files chang
Hi,
On Friday, February 15, 2013 15:00:24 Vadim Girlin wrote:
> "LLVM backend is the future" is a pretty abstract argument. I prefer to
> operate with real facts. After a year of LLVM backend development what
> are the real benefits for the users? What are the real use cases where
> the users mig
christopher.halse.rog...@canonical.com writes:
> From: Christopher James Halse Rogers
>
> _mesa_delete_renderbuffer does not call the driver-specific
> renderbuffer delete function, so the blorp code was leaking the
> Intel-specific bits, including some GEM objects.
>
> Call the renderbuffer's ->
42 matches
Mail list logo
