On Mon, Feb 18, 2013 at 10:06 PM, Vinson Lee wrote:
> MinGW does not have clock_gettime.
>
> Signed-off-by: Vinson Lee
> ---
> configure.ac | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 16c2f8c..57d3a70 100644
> --- a/configure.ac
> +++ b/configur
MinGW does not have clock_gettime.
Signed-off-by: Vinson Lee
---
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])
case "$host_os" in
dar
On 02/18/2013 10:16 AM, Brian Paul wrote:
From: 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() function of xcb does not return
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
From: Roland Scheidegger
These used to be illegal a very long time ago, then for some more time
nothing really emitted these so this code path wasn't hit.
Just trivially iterate over box->depth.
(Might be worth refactoring at some point since nowadays all the code
doesn't really do much except fo
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
https://bugs.freedesktop.org/show_bug.cgi?id=61091
Priority: medium
Bug ID: 61091
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit glsl-fs-texture2drect regression
Sever
Fixes uninitialized scalar field defect reported by Coverity.
Signed-off-by: Vinson Lee
---
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 100644
--- a/src/glsl/li
v3: handle hw-specific cases
Signed-off-by: Vadim Girlin
---
cc: Andy Furniss
Hopefully this should work better on the non-evergreen chips
src/gallium/drivers/r600/r600_asm.c| 4 +-
src/gallium/drivers/r600/r600_asm.h| 29 +--
src/gallium/drivers/r600/r600_shader.c | 134 ++
From: Roland Scheidegger
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 copying over all vertex_e
On Tue, Feb 19, 2013 at 4:58 AM, Rob Clark wrote:
> On Mon, Feb 18, 2013 at 12:47 PM, Matt Turner wrote:
>> On Sun, Feb 17, 2013 at 11:33 AM, Rob Clark wrote:
>>>
>>> diff --git a/src/gallium/drivers/freedreno/Makefile.am
>>> b/src/gallium/drivers/freedreno/Makefile.am
>>> new file mode 100644
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #8 from Brian Crowell ---
On Mon, Feb 18, 2013 at 11:58 AM, wrote:
> Here's another patch to try. It uses the results of get_drawable_size() to
> initialize the buffer's dimensions. I've run other test programs and it
> seems
> to
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #7 from Roland Scheidegger ---
(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 XGetGeometry
Am 18.02.2013 19:14, schrieb Michel Dänzer:
> From: Michel Dänzer
>
> 11 more little piglits.
>
> NOTE: This is a candidate for the 9.1 branch.
>
> Signed-off-by: Michel Dänzer
> ---
>
> Any ideas why this seems necessary with radeonsi but not with r600g?
Maybe the hw uses an implicit 1 if th
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #6 from Brian Paul ---
(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 in the glx/xlib
On Mon, Feb 18, 2013 at 12:47 PM, Matt Turner wrote:
> On Sun, Feb 17, 2013 at 11:33 AM, Rob Clark wrote:
>>
>> diff --git a/src/gallium/drivers/freedreno/Makefile.am
>> b/src/gallium/drivers/freedreno/Makefile.am
>> new file mode 100644
>> index 000..10abdfb
>> --- /dev/null
>> +++ b/src/ga
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #5 from Roland Scheidegger ---
Created attachment 75068
--> https://bugs.freedesktop.org/attachment.cgi?id=75068&action=edit
another attempt to fix pbuffer initialization
Hmm is it legal to use XGetGeometry() with pbuffers?
I think
From: 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() function of xcb does not return the length of
the (optional, n>1) data but
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(
From: Michel Dänzer
11 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
---
Any ideas why this seems necessary with radeonsi but not with r600g?
src/gallium/drivers/radeonsi/si_state.c | 116 +---
src/gallium/drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #4 from Brian Paul ---
Created attachment 75065
--> https://bugs.freedesktop.org/attachment.cgi?id=75065&action=edit
Initialize the buffer's size in create_xmesa_buffer()
Here's another patch to try. It uses the results of get_dra
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() function of xcb does not return the length
https://bugs.freedesktop.org/show_bug.cgi?id=61003
Brian Paul changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com
|org
On Mon, Feb 18, 2013 at 2:31 AM, Ramesh Reddy Emmadi
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
___
On Sun, Feb 17, 2013 at 9:34 AM, Einar Már Björgvinsson
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 build complaints.
>
> My ma
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #3 from Roland Scheidegger ---
(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 with the
> pbuff
https://bugs.freedesktop.org/show_bug.cgi?id=61012
--- Comment #2 from Brian Paul ---
Created attachment 75059
--> https://bugs.freedesktop.org/attachment.cgi?id=75059&action=edit
llvmpipe texture size patch
Can you test the attached patch?
--
You are receiving this mail because:
You are the
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
ar
From: Vadim Girlin
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 packed together in a singl
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|
---
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 +1587,
---
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
+++ b/lib/Target/R60
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 e4
---
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
--- a/lib/Target/R600/R600
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 out
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
ope
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 a
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
https://bugs.freedesktop.org/show_bug.cgi?id=61026
--- Comment #4 from Brian Paul ---
Created attachment 75047
--> https://bugs.freedesktop.org/attachment.cgi?id=75047&action=edit
Fixed test program.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=61026
--- Comment #3 from Brian Paul ---
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 for the test progr
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 Pälli
https://bugs.freedesktop.org/show_bug.cgi?id=61003
Blaž Hrastnik changed:
What|Removed |Added
CC||speed.the.b...@gmail.com
--
You are rec
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=59876
--- Comment #5 from Stefan Brüns ---
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.
___
mes
https://bugs.freedesktop.org/show_bug.cgi?id=61052
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #1 from J
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 wrote:
> Stefan Seifert wrote:
>
>> Hi!
>>
>> Amazing work! I see some 50 % speed ups in FlightGear and even more. While
>> normally 3D clouds tear performance
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 the
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).
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'
Severit
https://bugs.freedesktop.org/show_bug.cgi?id=61036
José Fonseca changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@list
50 matches
Mail list logo