> It falls back gracefully though (I think TTM did as well, though this API is
> smaller in that it doesn't pass a huge gob of flags around), so if we think
> the libdrm bufmgr interface is stable there should be no problem.
The problem is I am not that happy that the bufmgr interface is stable
Dave Airlie wrote:
>> On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
>>
>>> Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
>>> tarball. Could this be?
>>>
>> See my other reply on mesa3d-dev, they're from libdrm git master.
>
> So I see a couple of ways to resolve this,
>
On Tuesday, August 19, 2008 4:26 pm Dave Airlie wrote:
> > On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
> > > Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
> > > tarball. Could this be?
> >
> > See my other reply on mesa3d-dev, they're from libdrm git master.
>
> So I se
> On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote:
>
> > Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the
> > tarball. Could this be?
> >
> See my other reply on mesa3d-dev, they're from libdrm git master.
So I see a couple of ways to resolve this,
1) Back out GEM, release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul schrieb:
> Yet another Mesa 7.1 release candidate is at http://www.mesa3d.org/beta/
>
> This includes the latest GLSL fixes/features plus other assorted fixes
> from the past 2-3 weeks.
>
> Hoping to wrap up 7.1 pretty soon...
I just upg
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integration&id=20e634059e02b41d061149a45e53dd4933c39953
.
Kristof
>From 20e634059e02b41d061149a45e53dd4933c39953 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= <[EMAIL PROTECTED]>
Date: Tue, 19 Aug 2008 1
Patches item #2058899, was opened at 2008-08-18 21:06
Message generated for change (Settings changed) made by brianp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=33&aid=2058899&group_id=3
Please note that this message will contain a full copy of the comment t
Ralovich, Kristóf wrote:
> This patch is at
> http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integration&id=18deb0897ede0d1406bcfc7419b12654ceddf6af
> .
>
> Kristof
>
>
>>From 18deb0897ede0d1406bcfc7419b12654ceddf6af Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= <[E
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integration&id=18deb0897ede0d1406bcfc7419b12654ceddf6af
.
Kristof
>From 18deb0897ede0d1406bcfc7419b12654ceddf6af Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= <[EMAIL PROTECTED]>
Date: Tue, 19 Aug 2008 14
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integration&id=fe0c68634ade8dafda2e8decaab077e50fea99e1
.
Kristof
>From fe0c68634ade8dafda2e8decaab077e50fea99e1 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=B3f?= <[EMAIL PROTECTED]>
Date: Tue, 19 Aug 2008 1
This patch is at
http://cgit.freedesktop.org/~tade/mesa/diff/?h=xcb-integration&id=0e78c256e9fd9a2bab5acb4b639c5240357129f7
. I am sure this #include is not elegant, but it works.
Kristof
>From 0e78c256e9fd9a2bab5acb4b639c5240357129f7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=20Krist=C3=
This patch is at
http://cgit.freedesktop.org/~tade/mesa/commit/?h=xcb-integration&id=45737d791ca91fc33a8f6bfb2514c28409548c73
. This leak was only exposed when LIBGL_ALWAYS_INDIRECT is set.
Kristof
>From 45737d791ca91fc33a8f6bfb2514c28409548c73 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ralovich,=
Dear Mesa developers,
I am a 2008 GSOC student working on further integrating XCB into Mesa.
My work involved reviewing and trying to understand most of the client
side GLX implementation. During this work I have found some memory
leaks too. I have prepared patches to plug them. See my following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Hähnle wrote:
> Hi,
>
> referring to the recent commit 12e84a8b84c331d0afef63e6119fe356c84bf383, this
> overrides the OpenGL state machine states. Are you sure that this is correct?
> It seems like quite an evil thing to do on the face of it
Hi,
referring to the recent commit 12e84a8b84c331d0afef63e6119fe356c84bf383, this
overrides the OpenGL state machine states. Are you sure that this is correct?
It seems like quite an evil thing to do on the face of it.
Essentially this means that whenever a program with FogOption != NONE is use
15 matches
Mail list logo