On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote:
> On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner wrote:
> > __glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized
> > tags. Instead, it treats the value as if it were the next tag, which can
> > happen
> > if th
>
> How is trying to make the best possible release with a given amount of
> resources and trying to get as much of this into any future release as
> well not the Linux way? Tho I can see how our long stabilization
> periods would conflict with other peoples view on how to do releases.
> See below
On Mon, May 3, 2010 at 1:20 AM, Chris Ball wrote:
> http://tinderbox.x.org/builds/2010-05-02-0034/logs/libGL/#build
>
> In file included from ../common/drisw_util.c:30:
> ../common/drisw_util.h:39:20: error: mtypes.h: No such file or directory
>
> In file included from ../common/drisw_util.c:30:
>
http://tinderbox.x.org/builds/2010-05-02-0034/logs/libGL/#build
In file included from ../common/drisw_util.c:30:
../common/drisw_util.h:39:20: error: mtypes.h: No such file or directory
In file included from ../common/drisw_util.c:30:
../common/drisw_util.h:62: error: expected ')' before 'glapi'
I meant to re-add this one but forgot. Commited. Thanks.
Jose
On Sun, 2010-05-02 at 16:12 -0700, Xavier Chantry wrote:
> From: Luca Barbieri
>
> Re-add commit 2d65a7caf97684aa654088c76a74b632fbd685fa
>
> Signed-off-by: Xavier Chantry
> ---
> src/gallium/auxiliary/util/u_format_s3tc.c |4
From: Luca Barbieri
Re-add commit 2d65a7caf97684aa654088c76a74b632fbd685fa
Signed-off-by: Xavier Chantry
---
src/gallium/auxiliary/util/u_format_s3tc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliar
On Sun, 2010-05-02 at 15:57 -0700, Xavier Chantry wrote:
> Signed-off-by: Xavier Chantry
> ---
> src/gallium/drivers/llvmpipe/.gitignore |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/.gitignore
> b/src/gallium/drivers/llvmpipe/.git
Signed-off-by: Xavier Chantry
---
src/gallium/drivers/llvmpipe/.gitignore |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/.gitignore
b/src/gallium/drivers/llvmpipe/.gitignore
index 257b72d..a1b6f56 100644
--- a/src/gallium/drivers/llvmpipe
On Sun, May 2, 2010 at 6:37 AM, Dave Airlie wrote:
>>
>> My thought about this is that this idea adds more work for all
>> developers, not only does the developer have to consider if a patch is
>> suitable for stable but they also need to update a wiki and a such get
>> bookkeeping overhead. If th
On Sun, May 2, 2010 at 10:17 PM, Dave Airlie wrote:
> On Mon, May 3, 2010 at 3:43 AM, Aaron Plattner wrote:
>> On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote:
>>> On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner
>>> wrote:
>>> > __glXInitializeVisualConfigFromTags doesn't skip the p
On Mon, May 3, 2010 at 3:43 AM, Aaron Plattner wrote:
> On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote:
>> On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner wrote:
>> > __glXInitializeVisualConfigFromTags doesn't skip the payload of
>> > unrecognized
>> > tags. Instead, it treats the
On Sun, May 2, 2010 at 10:48 AM, Eric Anholt wrote:
> On Sun, 2 May 2010 09:46:15 -0700, Dan Nicholson wrote:
>> Brian,
>>
>> I'm putting forward this request completely understanding your
>> position why you don't want automake and libtool in your project.
>> However, I think that mesa has outgr
https://bugs.freedesktop.org/show_bug.cgi?id=27939
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sun, May 2, 2010 at 11:57 AM, Marek Olšák wrote:
> The compilation is still broken here even after your commits. I've attached
> the log. My config:
>
> ./autogen.sh --with-dri-drivers=swrast,r300 --with-state-trackers=dri \
> --enable-glx-tls --enable-gallium-radeon --enable-debug \
>
On Sun, May 2, 2010 at 10:51 AM, José Fonseca wrote:
> I think the problem is that src/mesa/main/dispatch.h has
>
> #ifdef IN_DRI_DRIVER
> #define _GLAPI_USE_REMAP_TABLE
> #endif
>
> But we're missing #ifdef _GLAPI_USE_REMAP_TABLE .. #endif in a bunch of
> places. That is, all non-dri builds are b
On Mon, May 3, 2010 at 12:24 AM, Zack Rusin wrote:
> On Saturday 01 May 2010 15:27:45 Chia-I Wu wrote:
>> I've been working on and off for a while on a dispatcher builder called
>> mapi (multiple-api, in contrary to gl-api). The code is available at
>>
>> http://cgit.freedesktop.org/~olv/mesa/
On Sun, 2010-05-02 at 09:34 -0700, Corbin Simpson wrote:
> So I got bored a few days ago and broke ground on a little bit of code
> I've had in mind for a while. This is a new state tracker, Pylladium,
> that acts to expose the core Gallium objects of a driver in a clean,
> Pythonic fashion, withou
On Sun, 2 May 2010 09:46:15 -0700, Dan Nicholson wrote:
> Brian,
>
> I'm putting forward this request completely understanding your
> position why you don't want automake and libtool in your project.
> However, I think that mesa has outgrown the static Makefiles approach
> for a number of reasons
Brian,
I'm putting forward this request completely understanding your
position why you don't want automake and libtool in your project.
However, I think that mesa has outgrown the static Makefiles approach
for a number of reasons. For a project that's grown to the complexity
of mesa, I believe you
So I got bored a few days ago and broke ground on a little bit of code
I've had in mind for a while. This is a new state tracker, Pylladium,
that acts to expose the core Gallium objects of a driver in a clean,
Pythonic fashion, without being overly low-level or abstracted away.
So why make another
On Saturday 01 May 2010 15:27:45 Chia-I Wu wrote:
> Hi all,
>
> I've been working on and off for a while on a dispatcher builder called
> mapi (multiple-api, in contrary to gl-api). The code is available at
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
>
> The motivation is to build
On Sun, May 2, 2010 at 8:17 AM, José Fonseca wrote:
> On Thu, 2010-04-29 at 09:50 -0700, Karl Schultz wrote:
>> What version of Python is needed to run these build scripts? Are
>> there any other prerequisites?
>
> I just realized it's not just vanilla python. The GL API code generation
> require
https://bugs.freedesktop.org/show_bug.cgi?id=27939
Summary: glapitable.h: No such file or directory
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
C
On Thu, 2010-04-29 at 09:50 -0700, Karl Schultz wrote:
>
>
> On Thu, Apr 29, 2010 at 9:54 AM, Brian Paul wrote:
> Was: "Merging GLES1/2 to mesa/main"
>
> Chia-I Wu wrote:
> 2010/4/29 Kristian Høgsberg :
>
> Yeah, I noticed
I think the problem is that src/mesa/main/dispatch.h has
#ifdef IN_DRI_DRIVER
#define _GLAPI_USE_REMAP_TABLE
#endif
But we're missing #ifdef _GLAPI_USE_REMAP_TABLE .. #endif in a bunch of
places. That is, all non-dri builds are broken.
Jose
On Sun, 2010-05-02 at 07:42 -0700, José Fonseca wrote
Hi Kristian,
Most of the mesa builds (make and scons) got broken with this merge due
to missing *_remap_index symbols in remap_helper.h
I took a look but it's not obvious to me how to fix it.
Jose
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
-I../../src/gallium/auxiliary
On Sun, 2010-05-02 at 15:16 +0200, Marek Olšák wrote:
> On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
> wrote:
> This commit breaks compiz completely here on nvidia G50
> (Geforce 8400M)
> Compiz shows dark screen.
> (Using nouveau drivers)
>
> W
https://bugs.freedesktop.org/show_bug.cgi?id=27827
kowalski marcin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky wrote:
> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
> Compiz shows dark screen.
> (Using nouveau drivers)
>
> Without this commit compiz works almost perfectly.
>
> The error messages from compiz:
>
>
> debug_get_bool_opt
https://bugs.freedesktop.org/show_bug.cgi?id=27924
--- Comment #2 from Michał Lipski 2010-05-02 04:18:22 PDT ---
I've tried
Section "ServerFlags"
...
Option "GlxVisuals" "all"
...
EndSection
but it's still the same.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote:
> On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca wrote:
> > I read the extension and it is not crystal clear, but it seems to imply the
> > swizzles are orthogonal to the format, and applied as the very last step
> > before being used in a shad
On Fri, 2010-04-30 at 09:42 -0700, Corbin Simpson wrote:
> I think the big problem is the disconnect between VMWare and the rest
> of the developers in terms of communication. We all are on IRC
> extensively but at least Brian, Keith, Jose, and Vinson are not.
> Coincidentally, these are the people
On Sun, 2010-05-02 at 00:42 -0700, Dave Airlie wrote:
> So playing with swizzle found this bug in softpipe, I just wonder if
> the is_compat_view check needs further expansion or have I done
> enough?
At least this one
tc->format == view->format
should be added. The rest appears to be handled
On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner wrote:
> __glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized
> tags. Instead, it treats the value as if it were the next tag, which can
> happen
> if the server's GLX extension is not Mesa's. For example, this falls down
On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca wrote:
> I read the extension and it is not crystal clear, but it seems to imply the
> swizzles are orthogonal to the format, and applied as the very last step
> before being used in a shader. That is, the semantics are the same of adding
> a swizzle
I read the extension and it is not crystal clear, but it seems to imply the
swizzles are orthogonal to the format, and applied as the very last step before
being used in a shader. That is, the semantics are the same of adding a swizzle
instruction after a TEX opcode, regardless of the format. At
On Sat, May 1, 2010 at 6:47 PM, Dave Airlie wrote:
> In looking at adding EXT_texture_swizzle I'm a bit confused about what
> exactly should happen with BGRA textures, as on r300 we use the
> texture swizzling to do BGRA, so we would have some interaction at
> that point.
>
> To make sure we test
On Sun, May 2, 2010 at 5:42 PM, Dave Airlie wrote:
> So playing with swizzle found this bug in softpipe, I just wonder if
> the is_compat_view check needs further expansion or have I done
> enough?
I've added format to the check, as well locally.
Dave.
>
> this with my EXT_texture_swizzle work
So playing with swizzle found this bug in softpipe, I just wonder if
the is_compat_view check needs further expansion or have I done
enough?
this with my EXT_texture_swizzle work gets softpipe passing the glean tests.
Dave.
0001-softpipe-invalidate-cache-view-when-swizzles-are-dif.patch
Descrip
39 matches
Mail list logo
