Nothing actually relied on them being mutable, and there was at least
one cast which discarded const qualifiers. The next patch would have
introduced many more.
Casting away const qualifiers should be avoided if at all possible.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
From: Eric Anholt e...@anholt.net
We have lexer recognition of a bunch of our types based on the
handling. This code was mapping those recognized tokens to an enum
and then to a string of their name. Just drop the enums and provide
the string directly in the parser.
Reviewed-by: Ian Romanick
On Thu, 29 Mar 2012 14:16:10 -0700
Ian Romanick i...@freedesktop.org wrote:
On 03/29/2012 10:41 AM, Kenneth Graunke wrote:
On 03/28/2012 11:43 PM, Vinson Lee wrote:
Fixes a Coverity resource leak defect.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson
On 30 March 2012 03:29, Ian Romanick i...@freedesktop.org wrote:
I'm not super excited about GL_EXT_gpu_shader4. Do we know of any
applications that use that EXT and don't use either GLSL 1.30 or GLSL 1.40?
Wine will use it for the texture sampling functions with explicit
derivatives, but it
Certain applications don't call SwapBuffers before exiting. Yet, we'd
really like to see a bitmap containing the final rendered image even if
they choose never to present it.
In particular, Piglit tests (at least with -auto -fbo) fall into this
category. Many of them failed to dump any images
https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #7 from Fabio Pedretti fabio@libero.it 2012-03-30 03:05:21
PDT ---
This patch was dropped in Ubuntu: no longer needed, now breaks things:
- Original Message -
Certain applications don't call SwapBuffers before exiting. Yet,
we'd
really like to see a bitmap containing the final rendered image even
if
they choose never to present it.
In particular, Piglit tests (at least with -auto -fbo) fall into this
category.
gallivm/llvmpipe is not thread safe.
To fix it, we need to have separate LLVMContext / JIT engines for each
pipe_context (i.e., each thread).
I'm working on a branch that does most of this, and I plan to commit over the
next month or so. That branch also has changes for the compilation to
On 03/28/2012 11:58 AM, Eric Anholt wrote:
This gets the texture buffer object support to the point of running
and passing the piglit core tests other than deprecated formats on
i965.
Patch 2 is the glapi regen (I want the time back I've lost to
regen failure this week).
Patch 13 we may want
On Fri, Mar 23, 2012 at 1:40 AM, Francisco Jerez curroje...@riseup.net wrote:
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index aaeeb81..de990fe 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -63,6
On Thu, 29 Mar 2012 23:17:31 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Nothing actually relied on them being mutable, and there was at least
one cast which discarded const qualifiers. The next patch would have
introduced many more.
Casting away const qualifiers should be avoided
On Fri, 30 Mar 2012 01:31:12 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Certain applications don't call SwapBuffers before exiting. Yet, we'd
really like to see a bitmap containing the final rendered image even if
they choose never to present it.
In particular, Piglit tests (at
Ok, what if I one uses a global lock around every gl call? Would that
work with the current version of pipeline before proper thread support
is in place?
On Fri, Mar 30, 2012 at 3:42 AM, Jose Fonseca jfons...@vmware.com wrote:
gallivm/llvmpipe is not thread safe.
To fix it, we need to have
On Thu, 29 Mar 2012 18:29:19 -0700, Ian Romanick i...@freedesktop.org wrote:
On 03/28/2012 10:58 AM, Eric Anholt wrote:
This gets the texture buffer object support to the point of running
and passing the piglit core tests other than deprecated formats on
i965.
Patch 2 is the glapi regen
On Thu, 29 Mar 2012 18:20:43 -0700, Ian Romanick i...@freedesktop.org wrote:
On 03/29/2012 02:59 PM, Eric Anholt wrote:
The samplerBuffer type will be undefined in !glsl 1.40, and the
keyword is marked as reserved. The [iu]samplerBuffer types are not
marked as reserved pre-1.40, so they
https://bugs.freedesktop.org/show_bug.cgi?id=36792
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
Status|NEW |RESOLVED
On 03/29/2012 11:17 PM, Kenneth Graunke wrote:
Nothing actually relied on them being mutable, and there was at least
one cast which discarded const qualifiers. The next patch would have
introduced many more.
Casting away const qualifiers should be avoided if at all possible.
Signed-off-by:
Building the i965 driver with --enable-32-bit is just broken on Fedora
15. It seems to work for folks on other distros, but I get a lot of
failure during linking i965_dri.so. Linking i915_dri.so works, and the
difference seems to be the presence of C++ files in i965.
The generated libtool
On 03/30/2012 03:12 AM, Jose Fonseca wrote:
- Original Message -
Certain applications don't call SwapBuffers before exiting. Yet,
we'd
really like to see a bitmap containing the final rendered image even
if
they choose never to present it.
In particular, Piglit tests (at least with
- Original Message -
On 03/30/2012 03:12 AM, Jose Fonseca wrote:
- Original Message -
Certain applications don't call SwapBuffers before exiting. Yet,
we'd
really like to see a bitmap containing the final rendered image
even
if
they choose never to present it.
- Original Message -
Ok, what if I one uses a global lock around every gl call?
What do you mean with around every gl call? You mean not on the GL driver but
in the GL application? Yeah, that'd work. Though in that case there's not much
point to use GL from multiple threads.
Would
On Fri, Mar 30, 2012 at 10:12 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Ok, what if I one uses a global lock around every gl call?
What do you mean with around every gl call? You mean not on the GL driver but
in the GL application? Yeah, that'd work. Though
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware drivers. To my knowledge, nv50 can
only do 12 bits and r600 can only do 16 bits. There's no such
limitation on
- Original Message -
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware drivers. To my knowledge, nv50 can
only do 12 bits and r600 can only do 16
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I also, am having trouble building 32 bit..
I use this configure command
CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/usr
- --libdir=/usr/lib --with-dri-drivers=
- --with-gallium-drivers=r600,swrast --enable-gallium-egl
- --enable-openvg
On 03/30/2012 09:48 AM, Ian Romanick wrote:
On 03/30/2012 03:12 AM, Jose Fonseca wrote:
- Original Message -
Certain applications don't call SwapBuffers before exiting. Yet,
we'd
really like to see a bitmap containing the final rendered image even
if
they choose never to present it.
On 03/30/2012 09:00 AM, Eric Anholt wrote:
On Thu, 29 Mar 2012 18:20:43 -0700, Ian Romanicki...@freedesktop.org wrote:
On 03/29/2012 02:59 PM, Eric Anholt wrote:
The samplerBuffer type will be undefined in !glsl 1.40, and the
keyword is marked as reserved. The [iu]samplerBuffer types are not
On 03/28/2012 10:58 AM, Eric Anholt wrote:
This gets the texture buffer object support to the point of running
and passing the piglit core tests other than deprecated formats on
i965.
Patch 2 is the glapi regen (I want the time back I've lost to
regen failure this week).
Patch 13 we may want
On Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware
Hi,
I noticed that GLSL compiler sometimes produces different code for the
same shader source, e.g.:
Vertex shader source:
gl_Position = gl_Vertex;
gl_FrontColor = gl_Vertex;
GLSL IR:
(assign (xyzw) (var_ref gl_Position) (var_ref gl_Vertex) )
(assign (xyzw)
On 3/30/12 12:31 PM, Ian Romanick wrote:
Building the i965 driver with --enable-32-bit is just broken on Fedora
15. It seems to work for folks on other distros, but I get a lot of
failure during linking i965_dri.so. Linking i915_dri.so works, and the
difference seems to be the presence of C++
On 03/30/2012 02:15 PM, Adam Jackson wrote:
On 3/30/12 12:31 PM, Ian Romanick wrote:
Building the i965 driver with --enable-32-bit is just broken on Fedora
15. It seems to work for folks on other distros, but I get a lot of
failure during linking i965_dri.so. Linking i915_dri.so works, and the
I actually got it working again, without using setarch. I had to drop the
--enable-xorg and added LDFLAGS=-m32. And then re applied my patch and I
could build in 32 bit mode again after a make clean.
Kevin
On Mar 30, 2012 3:32 PM, Ian Romanick i...@freedesktop.org wrote:
On 03/30/2012 02:15 PM,
33 matches
Mail list logo
