http://bugs.freedesktop.org/show_bug.cgi?id=27403
Brian Hall changed:
What|Removed |Added
CC||brian.h...@gmail.com
--- Comment #2 from
http://bugs.freedesktop.org/show_bug.cgi?id=27403
--- Comment #1 from Ian Romanick 2010-04-01 21:18:05
PST ---
(In reply to comment #0)
> uniform sampler3D volShadSampler0;
>
> struct VolShad
> {
> sampler3D texture;
> int samples;
> int channels;
> mat4 wo
On Thu, Apr 1, 2010 at 6:17 PM, Luca Barbieri wrote:
> Are you sure about this?
>
> I've tried doing it, and it turns out that basically every Gallium
> module needs this initialized.
>
> For instance:
> st/mesa due to glReadPixels
> vg/mesa due to vgReadPixels
> st/python due to mesa sampling
> s
http://bugs.freedesktop.org/show_bug.cgi?id=27418
Chia-I Wu changed:
What|Removed |Added
AssignedTo|mesa3d- |olva...@gmail.com
|d...@li
Excerpts from Brian Paul's message of Fri Mar 26 16:13:35 + 2010:
> Following up on an message from a while ago:
>
> Brian Paul wrote:
> > Robert Bragg wrote:
> >> Hi,
> >>
> >> Every now and then while working on the Clutter toolkit we end up with
> >> glGet{Integer,Float}v in our profiles. O
This helps debugging on darwin.
Signed-off-by: Jeremy Huddleston
---
progs/xdemos/Makefile | 45 +++--
1 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index f81aafe..038e21c 100644
--- a/pro
Are you sure about this?
I've tried doing it, and it turns out that basically every Gallium
module needs this initialized.
For instance:
st/mesa due to glReadPixels
vg/mesa due to vgReadPixels
st/python due to mesa sampling
several programs in rbug to dump textures to disk
softpipe due to texture
On Apr 1, 2010, at 15:27, Dan Nicholson wrote:
> On Thu, Apr 1, 2010 at 2:40 PM, Jeremy Huddleston
> wrote:
>>
>> On Apr 1, 2010, at 14:18, Dan Nicholson wrote:
>>
+$(PROGS): $(PROGS:%=%.o)
>>>
>>> Is this necessary? I would think the prereq would be picked up
>>> implicitly like the .c
On Apr 1, 2010, at 15:12, Dan Nicholson wrote:
>> This is against 7.8 ... perhaps you should cherry-pick the appropriate
>> change into the 7.8 branch then.
>
> Well, now I'm getting conflicts because you pushed this patch 25
> minutes after you posted it. I'll try to straighten it out, though.
On Apr 1, 2010, at 15:13, tom fogal wrote:
> Jeremy Huddleston writes:
>>> BTW, what config are you using, and what prevents you from using
>>> autoconf?
>>
>> I can't use autoconf because it is nowhere near capable of handling
>> darwin, and I haven't wanted to address the issue until the
>> t
Crap. I accidentally pushed to mainline instead of my tree, sorry. I pushed a
commit to 7.8 that reverts that series of patches.
These changes aren't ready for mainline. I want to clean them up a bit more
first. If you're interested in commenting now, I'd appreciate feedback, but
right now
http://bugs.freedesktop.org/show_bug.cgi?id=27418
Summary: latest eglut patches break build
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component
OK.
I'd like to add that u_atomic.h already requires either GCC, MSVC or
Solaris, and GCC and MSVC are already supported by this system.
Thus we do indeed now have a simple way to do global constructors,
that only removes support for non-GCC Solaris until someone figures
out how to do that.
And i
On Thu, Apr 1, 2010 at 4:29 PM, Luca Barbieri wrote:
> The half float conversion code initially used a global C++ constructor
> to initialize the tables.
>
> That fails to work since ld does not get the symbol from the shared
> library, so I changed to use register a global constructor from C,
> u
The half float conversion code initially used a global C++ constructor
to initialize the tables.
That fails to work since ld does not get the symbol from the shared
library, so I changed to use register a global constructor from C,
using GCC- or MSVC-specific code.
This is not necessarily the be
On Thu, Apr 1, 2010 at 2:40 PM, Jeremy Huddleston
wrote:
>
> On Apr 1, 2010, at 14:18, Dan Nicholson wrote:
>
>>> +$(PROGS): $(PROGS:%=%.o)
>>
>> Is this necessary? I would think the prereq would be picked up
>> implicitly like the .c from the .o.
>
> Nope. Without this, it tries to compile the .
Jeremy Huddleston writes:
> > BTW, what config are you using, and what prevents you from using
> > autoconf?
>
> I can't use autoconf because it is nowhere near capable of handling
> darwin, and I haven't wanted to address the issue until the
> transition to autotools was completed.
We're buildin
On Thu, Apr 1, 2010 at 2:36 PM, Jeremy Huddleston
wrote:
>
> On Apr 1, 2010, at 14:10, Dan Nicholson wrote:
>
>> On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
>> wrote:
>>>
>>> Signed-off-by: Jeremy Huddleston
>>> ---
>>> progs/xdemos/Makefile | 2 +-
>>> 1 files changed, 1 insertions(+
On Apr 1, 2010, at 14:18, Dan Nicholson wrote:
>> +$(PROGS): $(PROGS:%=%.o)
>
> Is this necessary? I would think the prereq would be picked up
> implicitly like the .c from the .o.
Nope. Without this, it tries to compile the .c directly to the executable
rather than the .o first.
>> +yuvrect
On Apr 1, 2010, at 14:10, Dan Nicholson wrote:
> On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
> wrote:
>>
>> Signed-off-by: Jeremy Huddleston
>> ---
>> progs/xdemos/Makefile |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/progs/xdemos/Makefile b/progs/
On Thu, Apr 1, 2010 at 12:36 PM, Jeremy Huddleston
wrote:
>
> This helps debugging on darwin.
>
> Signed-off-by: Jeremy Huddleston
> ---
> progs/xdemos/Makefile | 45 +++--
> 1 files changed, 15 insertions(+), 30 deletions(-)
>
> diff --git a/progs/xdemo
On Thu, Apr 1, 2010 at 12:35 PM, Jeremy Huddleston
wrote:
>
> Signed-off-by: Jeremy Huddleston
> ---
> progs/xdemos/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
> index e87d55d..d5c627a 100644
> --- a/progs/
This helps debugging on darwin.
Signed-off-by: Jeremy Huddleston
---
progs/xdemos/Makefile | 45 +++--
1 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index d5c627a..29cba0c 100644
--- a/pro
Signed-off-by: Jeremy Huddleston
---
progs/xdemos/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index e87d55d..d5c627a 100644
--- a/progs/xdemos/Makefile
+++ b/progs/xdemos/Makefile
@@ -11,7 +11,7 @@ LIB_DEP = $(T
This breaks platforms not using autoconf. You should change it to
-L$(INSTALL_LIB_DIR)
On Mar 11, 2010, at 20:09, Jeff Smith wrote:
>
>
>
>
> <0003-Add-L-libdir-for-xdemos-and-egl-so-that-the-right.patch>--
> Downl
> This constructor scheme is not working for me. I think that's because
> there isn't any symbol here that's used elsewhere, hence the linker is
> not linking this file.
I replaced the system with a different mechanism.
It should now work correctly, but only GCC and MSVC are supported, and
the la
On Thu, Apr 1, 2010 at 1:32 AM, Luca Barbieri wrote:
>> Once MS changes interfaces, then there's _no advantage_ to using DX10
>> internally, regardless of what WINE does, and one might as well use
>> OpenGL. Wine doesn't change that.
>
> [resent to ML, inadvertently replied only to Miles]
>
> Not
Hi Luca,
> Should be fixed now. BTW, if it is still not compiling due to
> the __sync* issues, try adding CFLAGS="-march=v9" to the build:
> it should fix that.
Thanks, both are fixed now.
- Chris.
--
Chris Ball
One Laptop Per Child
On Thu, 2010-04-01 at 04:33 -0700, Micha?? Kr??l wrote:
> Module: Mesa
> Branch: master
> Commit: 3ff175d6de89ad92d167362355501f99d06f0f97
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=3ff175d6de89ad92d167362355501f99d06f0f97
>
> Author: Luca Barbieri
> Date: Wed Mar 24 18:12:45
W dniu 2010-04-01 06:05, Luca Barbieri pisze:
> [sent to ML too]
>
> Michal,
> I noticed you made some commits related to half float support in Gallium.
>
> I had already done this work and implemented a fast conversion
> algorithm capable of handling all cases based on a paper cited in the
> commi
> Once MS changes interfaces, then there's _no advantage_ to using DX10
> internally, regardless of what WINE does, and one might as well use
> OpenGL. Wine doesn't change that.
[resent to ML, inadvertently replied only to Miles]
Note that my proposal was not to use DirectX 10 internally, but ra
31 matches
Mail list logo
