>Da: kei...@vmware.com
>Data: 05/10/2011 11.39
>A: "Christopher James Halse Rogers"
>Cc: "Joakim Sindholt", , "Fabio"
>Ogg: Re: [Mesa-dev] libgallium.so and miscelaneous buildsystem patches
>
>On Wed, 2011-10-05 at 20:14 +1100, Christopher James Halse Rogers wrote:
>> On Wed, 2011-10-05 at 09:24 +0
On 10/06/2011 01:23 PM, Jason Wood wrote:
> Match the comments regarding identifiers containing "__" being reserved
> in GLSL 1.10
>
> From: Jason Wood
>
> --- b/src/glsl/ast_to_hir.cpp2011-10-06 12:03:01.378402382 -0600
> +++ a/src/glsl/ast_to_hir.cpp2011-10-06 12:05:21.338400674 -0600
On Fri, Oct 7, 2011 at 3:21 AM, Zack Rusin wrote:
> On Thursday, October 06, 2011 04:58:45 PM Marek Olšák wrote:
>> I am cc'ing Zack, because he was the one to design the first interface.
>
> Hi Marek.
>
> I'm swamped right now and won't have time to review the patches. FWIW, the
> interface initi
Hi Ian,
This regresses Chrome GPU acceleration for all GPUs (I tested i915g,
llvmpipe, i965).
Stéphane
On Fri, Sep 30, 2011 at 16:44, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/glsl/linker.cpp | 138 +++--
On Thursday, October 06, 2011 04:58:45 PM Marek Olšák wrote:
> I am cc'ing Zack, because he was the one to design the first interface.
Hi Marek.
I'm swamped right now and won't have time to review the patches. FWIW, the
interface initially did have the stream output data in the shader state,
ul
On Thu, Oct 6, 2011 at 11:41 PM, Ian Romanick wrote:
> On 10/06/2011 02:11 PM, Marek Olšák wrote:
>>
>> If I get this right... Why not use a vertex array with stride == 0
>> instead?
>
> In the GL API, stride == 0 is a magic value that tells the GL implementation
> to figure out what the stride sh
On 10/06/2011 02:11 PM, Marek Olšák wrote:
If I get this right... Why not use a vertex array with stride == 0 instead?
In the GL API, stride == 0 is a magic value that tells the GL
implementation to figure out what the stride should be. As far as I
know, most hardware can't do true zero-stri
On 10/06/2011 09:36 AM, Eric Anholt wrote:
These will be used by the FF VS/FS to represent the current attributes
when they don't have an active vertex array.
I just want to make sure I grok this completely. These are arrays of
vec4 uniforms that are used when, for example, glColor is called
What I would prefer to assert is that, for each region that is currently
mapped, no batch is emitted that uses that region's bo. However, it's much
easier to implement this big hammer.
CC: Eric Anholt
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 +
s
On Fri, 30 Sep 2011 20:59:39 -0700, Ben Widawsky wrote:
> Clean the code up, and always use a BO when creating a new buffer. I've
> not seen any regressions but haven't yet tried this on < Gen6.
You have a bunch of different patches squashed into this here:
Replacing GL_TRUE/GL_FALSE with true/f
If I get this right... Why not use a vertex array with stride == 0 instead?
Marek
On Thu, Oct 6, 2011 at 6:36 PM, Eric Anholt wrote:
> These will be used by the FF VS/FS to represent the current attributes
> when they don't have an active vertex array.
> ---
> src/glsl/ir_variable.cpp | 25 ++
On 10/06/2011 02:38 PM, Eric Anholt wrote:
On Wed, 5 Oct 2011 20:57:24 -0600, Brian Paul wrote:
From: Brian Paul
This fixes failures found with the new piglit texsubimage test.
Two things were broken:
1. The dxt code doesn't handle sources images where width != row stride.
Check for that
I am cc'ing Zack, because he was the one to design the first interface.
See also my inline comments below.
On Thu, Oct 6, 2011 at 4:50 PM, Brian Paul wrote:
[snip]
> Thanks for digging into this. I was working on xformfb a while back (and
> still have some patches sitting around) but was far fr
On Fri, 30 Sep 2011 20:59:40 -0700, Ben Widawsky wrote:
> When mapping a range of a buffer that has the UNSYNCHRONIZED_BIT, and is
> only writable, we can take some shortcuts and let people shoot their
> feet.
Mesa patches to rely on new libdrm functionality need that libdrm
released and need to
On Tue, 04 Oct 2011 23:55:21 -0700, Kenneth Graunke
wrote:
> On 10/03/2011 03:41 PM, Eric Anholt wrote:
> > The condmod instruction ends up generating garbage condition codes,
> > because apparently the comparison happens on the accumulator value (33
> > bits for UD), not the truncated value that
On Wed, 5 Oct 2011 20:57:24 -0600, Brian Paul wrote:
> From: Brian Paul
>
> This fixes failures found with the new piglit texsubimage test.
>
> Two things were broken:
> 1. The dxt code doesn't handle sources images where width != row stride.
>Check for that and take the _mesa_make_temp_ub
Match the comments regarding identifiers containing "__" being reserved
in GLSL 1.10
From: Jason Wood
--- b/src/glsl/ast_to_hir.cpp2011-10-06 12:03:01.378402382 -0600
+++ a/src/glsl/ast_to_hir.cpp2011-10-06 12:05:21.338400674 -0600
@@ -2803,8 +2803,7 @@
_mesa_glsl_error(& loc,
2011/10/6 Ian Romanick :
> You will have to *completely* uninstall the NVIDIA closed-source driver in
> order to use the Mesa driver. NVIDIA installs their own kernel module and
> their own libGL, so it is impossible for both to live on the same system.
Well, last time I checked (2 months ago), n
https://bugs.freedesktop.org/show_bug.cgi?id=24226
Jeremy Huddleston changed:
What|Removed |Added
CC||elu...@ecce.se
--- Comment #19 from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/2011 09:36 AM, Eric Anholt wrote:
> glDeleteProgram should only be able to remove the one refcount for the
> user's reference to the program from the hash table (even though that
> ref does live on in the hash table until the last other ref is
These will be used by the FF VS/FS to represent the current attributes
when they don't have an active vertex array.
---
src/glsl/ir_variable.cpp | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/src/glsl/ir_variable.cpp b/src/glsl/ir_variable.cpp
ind
This is a slight simplification on the way to actually generating GLSL
fragment shaders.
---
src/mesa/main/ff_fragment_shader.cpp | 15 +++
1 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
ind
On converting fixed function programs to generate GLSL, the linker
became cranky that we were trying to make something that wasn't a
linked vertex+fragment program. Given that the Mesa GLES2 drivers
also support desktop GL with EXT_sso, just telling the linker to shut
up seems like the easiest sol
Here's this patch series again, part of the kill-Mesa-IR goal we have
for next release. It's been no regressions for me for a while, I was
just trying to track down a 2% performance regression on gen6. It
turns out that on my gen4 system, it's no performance regression, and
on gen7 (at least acco
glDeleteProgram should only be able to remove the one refcount for the
user's reference to the program from the hash table (even though that
ref does live on in the hash table until the last other ref is
removed).
Fixes piglit ARB_shader_objects/delete-repeat.
---
src/mesa/main/shaderapi.c |8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/2011 11:02 AM, Romain Failliot wrote:
> 2011/10/6 Heath Feather :
>> Try seeing which libraries you're picking up , here my LD_LIBRARY_PATH
>> was set to /home/hfeather/work/downloads/Mesa-7.0.1/lib64/
>
> Thanks!
> Actually I don't have a li
2011/10/6 Heath Feather :
> Try seeing which libraries you're picking up , here my LD_LIBRARY_PATH
> was set to /home/hfeather/work/downloads/Mesa-7.0.1/lib64/
Thanks!
Actually I don't have a lib64 directory, but just lib.
What did you do to build for 64 bits?
BTW I've got F15 64bits.
___
On 10/05/2011 11:09 PM, Romain Failliot wrote:
2011/9/27 Romain Failliot:
I'll get my hand in the code now.
Be right back as soon as I can run my own mesa code :)
Sorry for the delay, I lost my internet connection for a week...
So I started compiling mesa thanks to the site Benjamin Bellec gav
Julian,
Try seeing which libraries you're picking up , here my LD_LIBRARY_PATH
was set to /home/hfeather/work/downloads/Mesa-7.0.1/lib64/
> which glxinfo
/usr/bin/glxinfo
> ldd /usr/bin/glxinfo
libGL.so.1 =>
/home/hfeather/work/downloads/Mesa-7.0.1/lib64/libGL.so.1
(0x2af16f371000)
On Tue, 20 Sep 2011 15:37:20 -0400
Matt Turner wrote:
> One more nail in the coffin of XF86VidMode.
>
> Signed-off-by: Matt Turner
> ---
> I'm not sure how to test this, but the translation from XF86VidMode
> Xrandr seems to be pretty straightforward. Almost certainly there's
> something wrong
On 10/04/2011 06:51 PM, Marek Olšák wrote:
Namely:
- EXT_transform_feedback
- ARB_transform_feedback2
- ARB_transform_feedback_instanced
The old interface was unusable for OpenGL and had to go away.
This interface was originally designed for OpenGL, but additional
changes have been made in orde
On 10/04/2011 01:22 PM, Paul Gotzel wrote:
Hello,
I've recently upgraded to mesa 7.11 and I've noticed significant
performance degradation when using osmesa. Here's my results when
comparing the versions:
Version Time
7.6.14s
7.10.3 16s
7.11 23s
This is
https://bugs.freedesktop.org/show_bug.cgi?id=36792
--- Comment #3 from Brian Paul 2011-10-06 07:14:03 PDT
---
So with this patch we'll try to link with a file name libLLVM-x.y.so? I only
have static LLVM libs here and there's no libLLVM-2.9.so file. I get this
error:
/usr/bin/ld: cannot find
On 10/06/2011 06:44 AM, Julian Adams wrote:
It's possible that the instructions will only switch you over to your
locally built version version of Mesa if you are already running a
shipped Mesa as your driver. It looks like you're running the Nvidia
blob. Perhaps you need to switch to Mesa/Nouvea
2011/10/6 Julian Adams :
> It's possible that the instructions will only switch you over to your
> locally built version version of Mesa if you are already running a shipped
> Mesa as your driver. It looks like you're running the Nvidia blob. Perhaps
> you need to switch to Mesa/Nouveau first?
Wel
It's possible that the instructions will only switch you over to your
locally built version version of Mesa if you are already running a shipped
Mesa as your driver. It looks like you're running the Nvidia blob. Perhaps
you need to switch to Mesa/Nouveau first?
On 6 October 2011 07:09, Romain Fail
Le 06/10/2011 08:09, Romain Failliot a écrit :
> 2011/9/27 Romain Failliot :
>> I'll get my hand in the code now.
>> Be right back as soon as I can run my own mesa code :)
>
> Sorry for the delay, I lost my internet connection for a week...
> So I started compiling mesa thanks to the site Benjamin
https://bugs.freedesktop.org/show_bug.cgi?id=36792
Fabio changed:
What|Removed |Added
Attachment #46283|0 |1
is obsolete|
38 matches
Mail list logo
