https://bugs.freedesktop.org/show_bug.cgi?id=61036
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugs.freedesktop.org/show_bug.cgi?id=61052
Priority: medium
Bug ID: 61052
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48:
undefined reference to `dlopen'
Hi,
Can you please let us know is there any benchmark tool for opengles2 API's in
Linux and Windows.
Thanks and Regards,
Ramesh
CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s).
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders to maximum and enjoy
Well, the branch was said to work with EG. For HD4000, probably further
work is needed.
On Mon, Feb 18, 2013 at 12:20 PM, Andy Furniss andy...@ukfsn.org wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear
https://bugs.freedesktop.org/show_bug.cgi?id=61052
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
CC||jfons...@vmware.com
https://bugs.freedesktop.org/show_bug.cgi?id=59876
--- Comment #5 from Stefan Brüns stefan.bru...@rwth-aachen.de ---
Can *anyonye* act on this, please?
The bug is obvious and the fix is trivial ...
--
You are receiving this mail because:
You are the assignee for the bug.
On 02/18/2013 02:20 PM, Andy Furniss wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more.
While
normally 3D clouds tear performance down to an unflyable stutter, with
your
branch I can fly in densly clouded conditions at usable framerates. I
can
https://bugs.freedesktop.org/show_bug.cgi?id=61003
Blaž Hrastnik speed.the.b...@gmail.com changed:
What|Removed |Added
CC|
On 02/18/2013 12:12 AM, Tapani Pälli wrote:
This patch implements a stub for GL_EXT_discard_framebuffer with
required checks listed by the extension specification. This extension
is required by GLBenchmark 2.5 when compiled with OpenGL ES 2.0
as the rendering backend.
Signed-off-by: Tapani
https://bugs.freedesktop.org/show_bug.cgi?id=61026
--- Comment #3 from Brian Paul bri...@vmware.com ---
OK, I've found/fixed the problem. Your patch was incorrect. And your test
program has a few bugs too (I'll attach a fixed version).
After the patch has been reviewed I'll commit it. Thanks
https://bugs.freedesktop.org/show_bug.cgi?id=61026
--- Comment #4 from Brian Paul bri...@vmware.com ---
Created attachment 75047
-- https://bugs.freedesktop.org/attachment.cgi?id=75047action=edit
Fixed test program.
--
You are receiving this mail because:
You are the assignee for the bug.
We weren't mapping the PBO when using the bitmap cache (but we had
the PBO code for the non-cache path.)
Fixes ttps://bugs.freedesktop.org/show_bug.cgi?id=61026
Note: This is a candidate for the stable branches.
---
src/mesa/state_tracker/st_cb_bitmap.c | 13 +++--
1 files changed, 11
On 02/17/2013 03:35 AM, Chris Forbes wrote:
Pulls the checking of the sample count into a helper function, and
extends the existing logic to include the interactions with both
ARB_texture_multisample and ARB_internalformat_query.
_mesa_check_sample_count() checks a desired sample count against
On 02/17/2013 03:35 AM, Chris Forbes wrote:
Extends _mesa_check_sample_count() to properly support the
TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY targets, which
have subtly different limits than renderbuffers:
The ARB_texture_multisample spec (or GL3.2) says, when describing the
Vadim Girlin wrote:
Unrelated question wtr heaven 3.0 - does it work properly anyway?
For me running 64bit on rv790 with vanilla mesa with or without llvm I
have to set shaders to medium, on high it works but I get no
lighting/effects. There are also a couple of scenes that render as
flared
---
lib/Target/R600/R600Instructions.td | 8
test/CodeGen/R600/fdiv.v4f32.ll | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 0a01400..e4cc06e 100644
---
mayLoad complexify scheduling and does not bring any usefull info
as the location is not writeable at all.
---
lib/Target/R600/R600Instructions.td | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index
---
lib/Target/R600/AMDILISelDAGToDAG.cpp | 29 +
1 file changed, 29 insertions(+)
diff --git a/lib/Target/R600/AMDILISelDAGToDAG.cpp
b/lib/Target/R600/AMDILISelDAGToDAG.cpp
index 2e726e9..6b24117 100644
--- a/lib/Target/R600/AMDILISelDAGToDAG.cpp
+++
---
lib/Target/R600/R600Instructions.td | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 0a777f1..74106c9 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1587,6
Maintaining CONST_COPY Instructions until Pre Emit may prevent some ifcvt case
and taking them in account for scheduling is difficult for no real benefit.
---
lib/Target/R600/AMDGPU.h| 1 -
lib/Target/R600/AMDGPUTargetMachine.cpp | 1 -
lib/Target/R600/R600ISelLowering.cpp
From: Vadim Girlin vadimgir...@gmail.com
This is a skeleton for a pre-RA MachineInstr scheduler strategy. Currently
it only tries to expose more parallelism for ALU instructions (this also
makes the distribution of GPR channels more uniform and increases the
chances of ALU instructions to be
Vadim Girlin wrote:
Overcautious stack reservation caused significant loss of performance.
v2: fix stack depth computation
I get some corruption with this patch and heaven 3.0 with llvm on
HD4890, R600_LLVM=0 is OK.
It appears on sunlit areas over a certain distance and the patches move
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #2 from Brian Paul bri...@vmware.com ---
Created attachment 75059
-- https://bugs.freedesktop.org/attachment.cgi?id=75059action=edit
llvmpipe texture size patch
Can you test the attached patch?
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #3 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #0)
The following(ish) code produces an assertion failure using llvmpipe libGL
from Mesa 9.0.2:
Near as I can tell, the call responsible for storing that state
On Sun, Feb 17, 2013 at 9:34 AM, Einar Már Björgvinsson
einar.bjorgvins...@marel.com wrote:
Hi there
I'm currently trying to cross-compile the Mesa-9.0.1 before compiling QT 4.8
with OpenVG support.
I've tried some variation of compiling both the Mesa library and the libdrm
with several
On Mon, Feb 18, 2013 at 2:31 AM, Ramesh Reddy Emmadi
ramesh_emm...@infosys.com wrote:
Hi,
Can you please let us know is there any benchmark tool for opengles2 API's in
Linux and Windows.
Thanks and Regards,
Ramesh
glmark2, maybe: https://launchpad.net/glmark2
https://bugs.freedesktop.org/show_bug.cgi?id=61003
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #4 from Brian Paul bri...@vmware.com ---
Created attachment 75065
-- https://bugs.freedesktop.org/attachment.cgi?id=75065action=edit
Initialize the buffer's size in create_xmesa_buffer()
Here's another patch to try. It uses the
On 02/18/2013 10:48 AM, Roland Scheidegger wrote:
Am 05.02.2013 17:29, schrieb Stefan Brüns:
A single element in a GLX reply is contained in the header itself.
The number of elements is denoted in the n field of the reply, if
n is 1, the length of additional data is 0.
The XXX_data_length()
On Mon, Feb 18, 2013 at 12:47 PM, Matt Turner matts...@gmail.com wrote:
On Sun, Feb 17, 2013 at 11:33 AM, Rob Clark robdcl...@gmail.com wrote:
diff --git a/src/gallium/drivers/freedreno/Makefile.am
b/src/gallium/drivers/freedreno/Makefile.am
new file mode 100644
index 000..10abdfb
---
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #6 from Brian Paul bri...@vmware.com ---
(In reply to comment #5)
Created attachment 75068 [details] [review]
another attempt to fix pbuffer initialization
Hmm is it legal to use XGetGeometry() with pbuffers?
Not normally, but
Am 18.02.2013 19:14, schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
11 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
Any ideas why this seems necessary with radeonsi but not with r600g?
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #7 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #6)
(In reply to comment #5)
Created attachment 75068 [details] [review] [review]
another attempt to fix pbuffer initialization
Hmm is it legal to use
From: Roland Scheidegger srol...@vmware.com
Some parts calculated key size by using shader information, others by using
the pipe_vertex_element information. Since it is perfectly valid to have more
vertex_elements set than the vertex shader is using those may not be the same,
so we weren't
Fixes uninitialized scalar field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/link_uniforms.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index d457e4d..5e391ee
https://bugs.freedesktop.org/show_bug.cgi?id=61093
Priority: medium
Bug ID: 61093
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] lp_surface.c:68:lp_resource_copy: Assertion
On 02/15/2013 10:46 PM, Eric Anholt wrote:
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
On 02/18/2013 10:16 AM, Brian Paul wrote:
From: Stefan Brüns stefan.bru...@rwth-aachen.de
A single element in a GLX reply is contained in the header itself.
The number of elements is denoted in the n field of the reply.
If n is 1, the length of additional data is 0.
The XXX_data_length()
MinGW does not have clock_gettime.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
configure.ac | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure.ac b/configure.ac
index 16c2f8c..57d3a70 100644
--- a/configure.ac
+++ b/configure.ac
@@ -502,6 +502,8 @@ AC_SUBST([DLOPEN_LIBS])
On Mon, Feb 18, 2013 at 10:06 PM, Vinson Lee v...@freedesktop.org wrote:
MinGW does not have clock_gettime.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
configure.ac | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure.ac b/configure.ac
index 16c2f8c..57d3a70 100644
---
41 matches
Mail list logo
