https://bugs.freedesktop.org/show_bug.cgi?id=91468
Krzysztof A. Sobiecki sob...@gmail.com changed:
What|Removed |Added
URL|
From: Marek Olšák marek.ol...@amd.com
This fixes the single-sample fast clear hang.
Cc: 10.6 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_state.c | 8
src/gallium/drivers/r600/r600_shader.c | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff
From: Marek Olšák marek.ol...@amd.com
Fixed by the CB_SHADER_MASK fix.
---
src/gallium/drivers/r600/r600_blit.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 88780, which changed state.
Bug 88780 Summary: Several Unity3D-based games render with foggy blueish
overlay
https://bugs.freedesktop.org/show_bug.cgi?id=88780
What|Removed |Added
From: Marek Olšák marek.ol...@amd.com
No effect, but this is what we should be doing.
---
src/gallium/drivers/r600/evergreen_state.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
This patch fixes a bug that is manifested in the read path of mesa when
running on big-endian machines. The effects can be seen when running
piglit sanity test and/or taking a screen capture.
The bug is caused when _mesa_format_convert receives src_format as
mesa_format, which it thens changes to
This patch fixes a bug in big-endian handling, where the previous
swizzle info wasn't cleared before a new swizzle info was inserted into
the format field using a bitwise-OR operation.
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
CC: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
On Saturday, August 01, 2015 05:43:26 PM Emil Velikov wrote:
On 6 July 2015 at 21:40, Kenneth Graunke kenn...@whitecape.org wrote:
On Monday, July 06, 2015 12:18:18 PM Matt Turner wrote:
On Mon, Jul 6, 2015 at 9:55 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
It looks like this was
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
No effect, but this is what we should be doing.
Hello Marek,
who should test this on which stuff?
BTW Do you think, we see GL 4.1 on r600g (Turks ;-) with 11.0.1?
Great work!
-Dieter
---
As a side effect, this fix clRetain/ReleaseEvent Piglit test
---
src/gallium/state_trackers/clover/api/transfer.cpp | 29 --
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/transfer.cpp
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
fixed.
Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at
On Sun, Aug 2, 2015 at 9:03 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
Am 02.08.2015 19:54, schrieb Dieter Nützel:
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g (Turks) ~10% performance drop for Mesa's
---
src/glsl/ir_print_visitor.cpp | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
index 78475f3..641a996 100644
--- a/src/glsl/ir_print_visitor.cpp
+++ b/src/glsl/ir_print_visitor.cpp
@@ -25,7
On Sun, Aug 2, 2015 at 7:05 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
No effect, but this is what we should be doing.
Hello Marek,
who should test this on which stuff?
I've tested it.
BTW Do you think,
Am 02.08.2015 19:54, schrieb Dieter Nützel:
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
fixed.
Mostly 'cause it is NOT on par as before (the
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #8 from Krzysztof A. Sobiecki sob...@gmail.com ---
I was trying to contact maintainer of http://llvm.org/apt/unstable/, now I will
fill a bug on llvms bugzilla.
--
You are receiving this mail because:
You are the QA Contact for the
On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:
Maybe just for completeness you could add this to the commit message
The util/hash_table was intended to be a fast hash table
replacement for the program/hash_table see 35fd61bd99c1 and 72e55bb6888ff.
---
src/glsl/ir_print_visitor.cpp
Am 02.08.2015 21:11, schrieb Marek Olšák:
On Sun, Aug 2, 2015 at 9:03 PM, Dieter Nützel die...@nuetzel-hh.de
wrote:
Am 02.08.2015 19:54, schrieb Dieter Nützel:
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g
For the series,
Reviewed-by: Dave Airlie airl...@redhat.com
On 2 August 2015 at 23:36, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
No effect, but this is what we should be doing.
---
src/gallium/drivers/r600/evergreen_state.c | 8 ++--
1 file changed, 6
Some perf numbers would be nice. How much is this winning?
- Chris
On Mon, Aug 3, 2015 at 11:18 AM, Timothy Arceri t_arc...@yahoo.com.au wrote:
On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:
Maybe just for completeness you could add this to the commit message
The util/hash_table
Oh, fair enough then.
On Aug 3, 2015 12:39 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Given that this is a debug-only thing, I doubt perf numbers are that
interesting.
I have no clue what the diff is between the two hash tables, but if
one is allegedly faster than the other, that should be
Given that this is a debug-only thing, I doubt perf numbers are that
interesting.
I have no clue what the diff is between the two hash tables, but if
one is allegedly faster than the other, that should be determined, and
we should just mass-migrate...
-ilia
On Sun, Aug 2, 2015 at 8:05 PM,
I'm starting to contribute and Timothy Arceri told me about this
task. The change was made at that sole file because we talked
about no need to migrate all tables at once, but we discuss this
and I take note to migrate all hash tables at once if everyone
agrees.
PS.: I forgot to add Reviewed-by
The util/hash_table was intended to be a fast hash table
replacement for the program/hash_table see 35fd61bd99c1 and
72e55bb6888ff.
---
src/glsl/ir_print_visitor.cpp | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/glsl/ir_print_visitor.cpp
it did not work.
off screen rendering might be a walkaround, but would it work for pixel buffer
surface?
thanks.
hilbert___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
background:
1)ubuntu
2)libgles1-mesa-dev libgles2-mesa-dev installed
problem
surface=eglCreatePbufferSurface
Pixmap = XCreatePixmap(d,w,width,height,32);
eglCopyBuffers(dpy,sur, EGLNativePixmap)pixmap) returns EGL_FALSE;
eglGetError()= 0x3000
Question:
1) was what I did right?
2)I got X
https://www.khronos.org/registry/gles/extensions/OES/OES_mapbuffer.txt
This extension adds to the vertex buffer object functionality supported
by OpenGL ES 1.1 or ES 2.0 by allowing the entire data storage of a
buffer object to be mapped into the client's address space.
So this only
27 matches
Mail list logo
