On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every
texture format
The pipebuffer library works well with purely user space suballocation
of a big pinned buffer, but there are some further tweaks necessary in
order to use it with kernel TTM-like memory managers.
For example, one problem with pb_bufmgr_cache is that it doesn't try to
check if a buffer is busy
http://bugs.freedesktop.org/show_bug.cgi?id=26692
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, Feb 21, 2010 at 3:33 PM, Keith Packard kei...@keithp.com wrote:
The bash 'cd' command tends to emit random stuff to stdout when the
CDPATH variable is set, so clear it to keep extra filenames from being
emitted from the expand_archive function, which would otherwise cause
mklib to
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote:
The bash 'cd' command tends to emit random stuff to stdout when the
CDPATH variable is set, so clear it to keep extra filenames from being
emitted
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote:
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
Marek,
I don't particularly like that patch, because it doesn't really fix the
problem with the extension handling.
There are lots of extension listed there which should not be advertized
by default, so picking one out won't fix the others.
I think they are there because driInitExtensions
On Fri, Feb 19, 2010 at 5:16 PM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While we're on the topic of removing dead weight, can we remove support
for color index rendering? None of the hardware drivers support color
index rendering, and color
On Sat, Feb 20, 2010 at 9:32 AM, Xavier Chantry
chantry.xav...@gmail.com wrote:
On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry
chantry.xav...@gmail.com wrote:
It seems the commit below will always report an user error
On Mon, Feb 22, 2010 at 08:17:31AM -0700, Brian Paul wrote:
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote:
The bash 'cd' command tends to emit random stuff to stdout when the
CDPATH variable
On 10-02-19 07:16 PM, Ian Romanick wrote:
While we're on the topic of removing dead weight, can we remove support
for color index rendering? None of the hardware drivers support color
index rendering, and color index rendering is deprecated in OpenGL 3.0
(and removed in 3.1).
Can it please
On Mon, Feb 22, 2010 at 7:17 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote:
The bash 'cd' command tends to emit random stuff to stdout when the
CDPATH
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
glu/mesa
GLUT:
glut/fbdev
glut/ggi
glut/directfb
glut/dos
glut/mini
glut/os2
non-DRI drivers:
drivers/allegro
drivers/directfb
drivers/d3d
drivers/dos
drivers/ggi
drivers/glide
drivers/svga
Glide is a GL-glide driver, right? So it is not needed for libglide apps?
Posting from a mobile, pardon my terseness. ~ C.
On Feb 22, 2010 8:40 AM, Brian Paul bri...@vmware.com wrote:
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
Corbin wrote:
Glide is a GL-glide driver, right? So it is not needed for libglide apps?
Yes, correct.
-Brian
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find
Please commit to both master and mesa_7_7_branch. Thanks.
mesa_7_7_branch doesn't use 'cd' in mklib.
--
keith.pack...@intel.com
pgpjLL31Tv2B8.pgp
Description: PGP signature
--
Download Intel#174; Parallel Studio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
glu/mesa
GLUT:
glut/fbdev
glut/ggi
glut/directfb
glut/dos
glut/mini
glut/os2
non-DRI drivers:
Hi,
I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv
the code generation functionality in the gen subdir.
Please review,
regards,
George.
--
Download Intel#174; Parallel Studio Eval
Try the new
On Mon, Feb 22, 2010 at 2:46 PM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
glu/mesa
GLUT:
glut/fbdev
glut/ggi
I'm actually in the process of gathering hardware to revive gamma (or
rewrite its stack all together).
So I don't know whether it should be removed or not. Certainly the
mesa component of the stack won't be touched until I get a memory
manager working.
I suspect any attempt at reviviing it
-Original Message-
From: Ian Romanick i...@freedesktop.org
To: mesa3d-dev@lists.sourceforge.net mesa3d-dev@lists.sourceforge.net
Sent: Mon, Feb 22, 2010 1:46 pm
Subject: Re: [Mesa3d-dev] Mesa removals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Starting a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Sapountzis wrote:
Hi,
I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv
the code generation functionality in the gen subdir.
Please review,
I'm curious... what is the reason for these changes?
I do like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Brian Paul wrote:
I think we could get by with a shorter beta period. There's a few
more things that would be nice to do for 7.8 which I doubt I'd get to
before the 26th:
Part of the reason for the long lead time is to
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote:
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
24 matches
Mail list logo
