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 ->
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
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
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
---
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
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
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
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.
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
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
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
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 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 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 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 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
> 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
> 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
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 ---
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
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
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/
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/
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
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
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
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,
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
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
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
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 |
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
- 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
- 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
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
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
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
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
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,
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
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
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
42 matches
Mail list logo
