On 03/30/2012 11:48 PM, Vinson Lee wrote:
Fixes a Coverity resource leak defect.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson Lee
---
src/glsl/link_uniforms.cpp |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/
Fixes a Coverity resource leak defect.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson Lee
---
src/glsl/link_uniforms.cpp |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 613c9b7..2f1c9f5
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" wrote:
> On 03/30/2012 02:15 PM, Adam Jackson wr
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
d
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++ fil
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 Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca 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 drivers. To
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 to
On 03/30/2012 09:00 AM, Eric Anholt wrote:
On Thu, 29 Mar 2012 18:20:43 -0700, Ian Romanick 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 p
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.
I
-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 --
- 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
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 pipe
On Fri, Mar 30, 2012 at 10:12 AM, Jose Fonseca 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 in that case
- 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.
> Woul
- 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
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 -a
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 sc
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: Ken
https://bugs.freedesktop.org/show_bug.cgi?id=36792
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, 29 Mar 2012 18:20:43 -0700, Ian Romanick 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 don't have separ
On Thu, 29 Mar 2012 18:29:19 -0700, Ian Romanick 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 (I want t
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 wrote:
> gallivm/llvmpipe is not thread safe.
>
> To fix it, we need to have separate LLVMContext
On Fri, 30 Mar 2012 01:31:12 -0700, Kenneth Graunke
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 least with -auto -f
On Thu, 29 Mar 2012 23:17:31 -0700, 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 possibl
On Fri, Mar 23, 2012 at 1:40 AM, Francisco Jerez 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 +63,7 @@ struct
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 to
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 happe
- 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
> catego
https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #7 from Fabio Pedretti 2012-03-30 03:05:21
PDT ---
This patch was dropped in Ubuntu: "no longer needed, now breaks things":
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commitdiff;h=5ba285e9ca2f6f6d8baba231c80dcd41c2f9
On 03/29/2012 06:29 PM, Ian Romanick 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 (I want the time back I've lost to
regen
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 at
On 30 March 2012 03:29, Ian Romanick 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 can also use ARB_sh
On Thu, 29 Mar 2012 14:16:10 -0700
Ian Romanick 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 Lee
> >> ---
>
34 matches
Mail list logo
