Ian Romanick wrote:
Michel Dnzer wrote:
- libGL.so
Why not move this to Mesa as well? A single libGL which works with most
things you can think of throwing it at would be great I think.
I don't think it belongs there. The libGL in the DRI tree is 100%
specific to X11. The amount of
Jon Smirl wrote:
--- Otto Solares [EMAIL PROTECTED] wrote:
How can i interface with your changes?, currently i open the fbdev,
mmap fb and mmio region, set desired fbdev mode, load r200 dso, pull hooks
and
everything is ok from there. The only thing i dislike with the current
aproach
is that we
Ian Romanick wrote:
A long time ago I promided to refactor the firstLevel / lastLevel
calculation code from the various *SetTexImages routines. I have a
patch that does this, and it follows the definition of how firstLevel
lastLevel selection should work pretty closely. The only problem is
Keith Whitwell wrote:
Alan Hourihane wrote:
On Tue, Sep 30, 2003 at 11:02:13AM +0100, Alan Hourihane wrote:
Is it worth moving the remaining DRI drivers into Mesa for the 6.0
release ?
It seems as though mga, r128, r200 and radeon are already there.
Actually,
Do it this way we can fork the
Dave Airlie wrote:
Bug 509 in Bugzilla is reported fixed in Mesa.. has this made it into the
DRI yet?
if not is something major stopping it?
if yes, thanks :-)
Mesa 5.1 will use less memory for vertex buffers and display lists. I
was hesitant to back-port the changes into the 5.0.x code since
Alan Hourihane wrote:
Now that Mesa 5.0.2 is out the door, maybe we should tag the trunk and
merge with XFree86 ?
Obviously 5.0.2 is the last version of Mesa based on the old directory
layout and should be fairly easily dropped back into XFree86 too.
Then, we can start working on bringing in Mesa
Dieter Nützel wrote:
/opt/Mesa cvs update
cvs [update aborted]: connect to cvs.mesa3d.sourceforge.net:2401 failed:
Connection refused
I have no plans to move the Mesa CVS repository at this time.
The anon CVS problems don't seem as critical for Mesa. I'm willing to
wait a bit longer to see if
Matt Sealey wrote:
What exactly is the problem with Sourceforge anonymous CVS
anyway? I heard that the problems were a temporary measure
before they got new hardware to reduce the strain, but I
never saw any updates or new news about it after that.
From the 8/29 SourceForge newsletter:
[...]
I
Linus Torvalds wrote:
Ok, this is pretty off-topic, but I'm wondering what the status is for
open-source support of 3D-capable drivers for such studly monitors as the
IBM T221.
Yes, it's still expensive as hell, but it isn't nearly as bad as it was a
few years ago when it was very limited
Keith Harrison wrote:
- Original Message -
From: Ian Romanick [EMAIL PROTECTED]
To: DRI developer's list [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 6:48 PM
Subject: [Mesa3d-dev] Question about glcore.h
I have a question about the __GLcontextModesRec structure in
Ian Romanick wrote:
I have a question about the __GLcontextModesRec structure in glcore.h.
Is it safe to extend that structure? I'd like to extend it to have the
additional fields that are in __GLXFBConfigRec (from DRI's
include/GL/glxint.h). If that were done, I could remove
Ian Romanick wrote:
I was looking at something only tangentally related (implementing
IBM_multimode_draw_arrays before Mesa-5.1 is released), and I noticed
that EXT_multi_draw_arrays isn't exposed in any of the DRI drivers. Is
there any reason not to export that extension?
Not that I know of.
Ian Romanick wrote:
I have a question about the libGL ABI. The OpenGL Application Binary
Interface for Linux document
(http://oss.sgi.com/projects/ogl-sample/ABI/index.html#3) says that only
GLX entry points that are required to be static are those in the GLX 1.3
standard. Based on that, I
Dave Airlie wrote:
I'm running my own internal application (lots of texturing) and I'm
crashing out in the i810UploadTexImages, trying to upload a level 11
mipmap, but the i810tex.h has MAX_TEXLEVELS set to 10, so of course I'm
corrupting memory earlier when assigning the pointers in
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
There are two ways to go on this. One way is to make a new
GLX_MESA_memory_allocate extension that just extends the existing
glXAllocateMemoryNV, glXFreeMemoryNV, and glXGetAGPOffsetMESA to take
a display pointer and screen. This
Ian Romanick wrote:
Ian Romanick wrote:
As I mentioned in a couple earlier threads, there are some problems
with enabling this extension in a couple different drivers. Because
of that I have not committed any device-dependent code. Attached to
this message are the patches to the Radeon and
Matt Sealey wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick
Sent: Friday, August 01, 2003 8:09 PM
To: DRI developer's list
Subject: Re: [Dri-devel] SGI_make_current_read is in CVS
Ian Romanick wrote:
As I mentioned in a couple earlier
Keith Whitwell wrote:
Ian Romanick wrote:
Felix Kühling wrote:
On Wed, 30 Jul 2003 09:20:28 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I see: C SPECIFICATION
const char * glXQueryExtensionsString( Display *dpy,
int screen
Dieter Nützel wrote:
http://www.heise.de/newsticker/data/ola-29.07.03-007/
http://www.sgi.com/newsroom/press_releases/2003/july/opengl15.html
Brian any timeline, yet? ;-)
Nope.
-Brian
---
This SF.Net email sponsored by: Free pre-built
Alex Deucher wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
- snip -
what exactly is a cliprect? I've read over the FAQ and the source
and
it seems to define a clipping region if you have overlapping
windows.
That's basically it. The cliprect list is a list of non-overlapping
2D rectangles
Ian Romanick wrote:
I have completed all of the device-independent support (both client-side
server-side) for SGI_make_current_read. I wanted to update a couple
drivers to support this extension before committing it. I was able to
update the MGA driver without any problems. The Radeon
Laurent Pinchart wrote:
3DLabs have released their GL2 SDK today and claim that the latest version
of glslang was approved by the ARB at the June meeting. There's a revised
version of the spec and some examples.
http://www.3dlabs.com/support/developer/ogl2/index.htm
Is there any roadmap
Alex Deucher wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2003-06-27 at 18:42, Alan Hourihane wrote:
The savage-1_0_0-branch wont work until the 3D driver is fixed up
for
Mesa 4.x - it's still based on Mesa 3.4.
Is there any good info on doing this since the CLE266 driver has the
same
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
I'm rounding out the final bits of support for SGI_make_current_read.
I've hit a (hopefully) minor snag, and I'd like some advice on how to
proceede. At this point, *all* of the client-side support, both in
libGL.so and in at least
Ian Romanick wrote:
I'm rounding out the final bits of support for SGI_make_current_read.
I've hit a (hopefully) minor snag, and I'd like some advice on how to
proceede. At this point, *all* of the client-side support, both in
libGL.so and in at least one driver, is in place. I'm now working
Anyone who's interested in the construction of shared libs on Linux
should check out the following:
http://people.redhat.com/drepper/dsohowto.pdf
Good info. Mike Harris pointed me to it.
Ulrich Drepper's home page has other good info too:
http://people.redhat.com/drepper/
-Brian
José Fonseca wrote:
On Mon, Jun 16, 2003 at 02:52:45AM +0200, Alexander Stohr wrote:
In response to the attached list of spam
(18 spam e-mails to dri-devel in only 3 days!)
i have to ask if the dri-devel mailing list
can now be set to subscribers-only policy?
i dont feel thats any longer
Jacek Popawski wrote:
I am trying to understand DRI source, now from start, i.e. from OpenGL calls.
I was analizing file: lib/GL/glx/g_render.c, if I understand correctly there is
stream build there, but where it's readed?
For example in glColor3f there is identifier: X_GLrop_Color3fv. I grep
Just a heads-up regarding non-power of two (NPOT) textures.
An ARB extension for NPOT 1D, 2D, 3D and cube textures is coming.
Parameterized texture coordinates (i.e. [0,1] range) will be used,
rather than [0,w]x[0,h] like GL_NV_texture_rectangle.
I'll probably implement this feature in core
Keith Whitwell wrote:
Andreas Stenglein wrote:
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell
Felix Kühling wrote:
Hi,
even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful if you havn't
flushed the 3D hardware graphics pipeline before? I believe the driver
Felix Kühling wrote:
On Thu, 05 Jun 2003 16:51:27 -0600
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do
Ian Romanick wrote:
Since I seem to have launched into another round of GLX clean-up, I've
added SGI_make_current_read to my hit list. There are a coupld of
obvious libGL-to-driver interface changes that need to happen to support
this.
1. Add 'GLXDrawable currentReadable' to the end of
Ian Romanick wrote:
After Brian reported some problems to me with the fbconfig code in the
client-side GLX, I decided to make some GLX updates before leaving for
vacation (I'm away 6/10 through 6/22). I wanted to add GLX protocol
support for as many of the enum only extensions as I could. I
Denis Oliver Kropp wrote:
Quoting Keith Whitwell ([EMAIL PROTECTED]):
Brian Paul wrote:
dri/- dri driver interface
api/- public api
common/- reusable driver code
radeon/ - DRI driver
r200
Matt Sealey wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick
Sent: Wednesday, June 04, 2003 4:49 PM
To: DRI developer's list
Subject: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore,
but.. (pointers to colour buffers again..)
Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Hmm - I think that's a side issue to this reorg. Let's keep to code
that exists - I'm not sure that everyone's communicating acurately at
the moment.
I think that there will probably always be some small details about
the code
Denis Oliver Kropp wrote:
What do you mean by drivers not based on Mesa?
ATI, for example, has Linux OpenGL drivers that use the DRI but don't
use Mesa.
It seems to be common misconception that the DRI was designed around
Mesa, but it's not.
-Brian
David Dawes wrote:
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs add/remove
Here's the latest proposed layout. It may need some fine tuning at
some point, but I think it's a pretty good starting point.
-Brian
Mesa/
docs/ - documentation
include/
GL/ - OpenGL public headers
gl.h
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch] - dispatcher files
APIspec file
Jens Owen wrote:
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
Keith Whitwell wrote:
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc.
The dri
Ian Romanick wrote:
Nicholas Wourms wrote:
Keith Whitwell wrote:
The patch does have a few issues. Firstly it doesn't apply cleanly
to the current trunk so there'll be a bit of work wiggling it in.
[SNIP]
I noticed that, but I also noticed something else. It seems that
trunk has some
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands to move everything
around. This would work, but it would be
Keith Whitwell wrote:
Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands to move everything
Keith Whitwell wrote:
Keith Whitwell wrote:
Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are
two approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
My first step would be to wrap-up version 5.0.2 (bug fix release) and
get that out of the way.
That would leave the embedded-* branches. Do those of you working on
those branches have any concerns?
The embedded-2-branch which
Keith Whitwell wrote:
Brian Paul wrote:
David Dawes wrote:
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are
two approaches to doing
Adam K Kirchhoff wrote:
Well, it doesn't seem to be a false alarm any more. I found out that the
problem with the kernel build is a known issue between gcc 3.3 and 2.4.20.
In addition, I have been able to successfully compile XFree86 4.3.0,
without any problems...
So, anyone else have any ideas
Vanson Wu wrote:
Hi All,
we are trying to setup up multi-screen in my system. as we knows, the DRI
module not support Xinerama yet.
it will be software rendering, but when i running glxgears. no matter we use
dual-adapter system or dual-head system.
The second screen always can't display
José Fonseca wrote:
Now that, thanks to Brian, the textures are pretty much taken care of,
I'm moving into the TNL module for the C++ framework.
First, some definitions. TnL here is defined as the object [or module]
that handles all the geometric (vertex) data (as oppsed to the context
which
Jens Owen wrote:
Michel,
You're bring in issues that effect more than just the X development
community here, so I'm copying the DRI and Mesa developers.
Michel Dänzer wrote:
On Don, 2003-04-03 at 22:03, Alan Cox wrote:
From the DRI people's point of view, it leads to more work as we'd
want
Ian Romanick wrote:
Brian Paul wrote:
I've updated the Mesa sources on the DRI trunk to 5.0.1 with some
minor, post-release bug fixes. I also removed the $Id$ stuff.
I just noticed a couple things in the trunk's Mesa code.
swrast/s_texture.c is missing support for ATI_texture_env_combine3
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system are
very mismatched, the immediate API already has an impact on performance
I've updated the Mesa sources on the DRI trunk to 5.0.1 with some minor,
post-release bug fixes. I also removed the $Id$ stuff.
-Brian
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of
José Fonseca wrote:
[...]
/**/
/** \name Read - Important */
/**/
/[EMAIL PROTECTED]/
I really ask for the Doxygen
Ian Romanick wrote:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 10:57:05AM -0700, Brian Paul wrote:
I'd really rather not put the 5.1 code into DRI at this point. With
lots of
changes going on, it's too much of an upkeep hassle to keep the DRI
code up to
date.
Also, the current 5.1 code
Andreas Stenglein wrote:
Hello,
it looks as ctx-Color.AlphaEnabled isn't set,
at least not in glMaterialfv() (or at all?).
So in VTXFMT Mode, RADEON_CP_VC_FRMT_FPALPHA isnt added to ind,
and so some programs dont look as good as they do when
NO_VTXFMT=1 is set.
(exaple: arkhart-demo
Chris Rankin wrote:
Hi,
I have heard from the xscreensaver maintainer, after I
mentioned that I could run OpenGL xscreensaver hacks
by doing (e.g.)
$ flyingtoasters -root
but that they all failed when launched from
xscreensaver. His reply was:
The window that it's drawing on might have a
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
An issue perhaps, but not a bug.
There's no X or GLX policy that says the root window
must use a GLX visual
that features a depth buffers, stencil buffer, alpha
channel, double-buffering, etc.
Perhaps not, but:
a) XFree86 4.2.1, 4.2
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
there's no guarantee that any of them will
give you a root window with particular GLX
attributes. Sometimes you might get lucky.
[I've lost count of how many times this has come up
over the years, BTW.]
Hmm, makes me wonder
Brian Paul wrote:
Well, from my point of view I've been dealing with this issue on and off
for over three years. I've explained it more than enough times. I'm
tired of hearing of it.
I've (finally) added this to the DRI FAQ.
-Brian
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 01:40:57AM +, Alan Hourihane wrote:
I'll finish up tomorrow, sorry for the build bustage for now.
O.k. there's another issue here. I think I remember Ian merging in
a fairly early rev of Mesa 5.1 into the trunk which is causing a lot
of merge
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 06:52:57AM -0700, Brian Paul wrote:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 01:40:57AM +, Alan Hourihane wrote:
I'll finish up tomorrow, sorry for the build bustage for now.
O.k. there's another issue here. I think I remember Ian
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 05:34:00PM +, Keith Whitwell wrote:
I'm not averse to changing this policy for this merge (as opposed to
backing these changes out bringing something else in).
I'll stop the merge for now, until we get a consensus on how to
continue.
I'll
Keith Whitwell wrote:
Gareth Hughes wrote:
Keith Whitwell wrote:
Yes, very nice.
Utah did have some stuff going for it. It was designed as a
server-side-only accelerated indirect renderer. My innovation was
to figure out that the client could pretty easily play a few linker
tricks load
OK, I'm getting caught up on email and have read through this thread.
Comments follow, and in subsequent messages...
José Fonseca wrote:
As I've been writing the Mesa C++ wrappers I've come across some
dificulties posed by the way the interfaces are exported. As I
progressed I started to realize
Keith Whitwell wrote:
José Fonseca wrote:
2. On user space, the current drivers are structured (with some
exceptions not relevent now) as follows:
Client application
| |
v v
glapiGLX
| |
v v
Mesa DRI
| |
v v
Pasi Kärkkäinen wrote:
Hello!
I have been debugging a problem I am seeing with SDL when used with glew (glew
is OpenGL extension handler library, http://glew.sf.net).
When you use Mesa-based OpenGL drivers, and your app is using SDL for
OpenGL, and you link your program with glew, _SDL_ starts to
Jens Owen wrote:
Ian,
Looks like you've been busy. Here are some comments from the 10,000'
level. Keep in mind I haven't looked at your branch, yet. So feel free
to point me at the code if my comments are way off base.
Ian Romanick wrote:
Most of the changes that were in my previous Final
Smitty wrote:
Hi Brian
In light of your well maintained:
http://dri.sourceforge.net/doc/dri_driver_features.phtml
I think it's about time that:
http://dri.sourceforge.net/doc/dri_radeon_features.html
crawled into a hole and died.
Do you want to pull in anything from this page or can I get rid
Chris Rankin wrote:
Hi,
I have installed XFree86 4.3 on my Linux-2.4.20 SMP machine (with Matrox
G400), and recompiled xscreensaver 4.08 against the new libraries.
However, all of the OpenGL hacks now core-dump when they try to run on
the root window. They all run fine inside their own
Ian Romanick wrote:
Brian Paul wrote:
Leif Delgass wrote:
Add to list:
---
GL_ARB_multisample - R200, R100, mga (What's necessary for a driver
to support this?)
I wouldn't advertise support for GL_ARB_multisample until it really
works. The OpenGL spec allows one to support
Nicholas Leippe wrote:
On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote:
Who is the audience for the table? Is it the end user checking to see if a
feature is available and/or has some form of HW acceleration? Or is the
audience the DRI developer, looking to see what pieces need
Leif Delgass wrote:
On Sat, 8 Mar 2003, Brian Paul wrote:
Nicholas Leippe wrote:
On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote:
Who is the audience for the table? Is it the end user checking to see if a
feature is available and/or has some form of HW acceleration
Andreas Karrenbauer wrote:
José Fonseca wrote:
Andreas,
Do you have an SourceForge user account? I want to give CVS write
access.
Well, I just created one. My login is karrenbauer. I'm used to CVS but
not for such huge projects with different branches. Thus, I have to read
the policies and
Nicholas Leippe wrote:
Brian,
I scratched an itch and made this dynamic. You can see it at:
http://lfm.sourceforge.net/dritest/dri_driver_features.phtml
and of course grab it if you want from:
/home/groups/l/lf/lfm/htdocs/dritest/dri_driver_features.phtml
Neat - I like it.
I was thinking it
Felix Kühling wrote:
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for
Felix Kühling wrote:
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if
Ian Romanick wrote:
NOTE TO IHVs: If you make binary-only drivers, READ THIS as it will
effect you!
Today I am sending out the last of the patches that I intend to commit
to the texmem-0-0-1 branch. After these patches are committed and Leif
is satisfied with the state of the r128 driver, I
Felix Kühling wrote:
On Fri, 21 Feb 2003 01:36:01 +
José Fonseca [EMAIL PROTECTED] wrote:
Felix, D. Hageman,
On Wed, Feb 19, 2003 at 09:52:47AM +0100, Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back
Felix Kühling wrote:
On Fri, 21 Feb 2003 07:43:24 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Fri, 21 Feb 2003 01:36:01 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
I don't if it is possible at all, but it surely would be nice if we
didn't have to rely
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least on
hic-up when trying to test UT2k3 with
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported
I mean that they are not listed by GL_EXTENSIONS. This caused at
least on hic-up when trying
Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice that the structure is quite similar to Ians texmem
Smitty wrote:
Hi Rich
Is there anything that can be done to cut down the spam on dri-devel?
Several other mailing lists I'm on hold submissions by non-subscribers
for approval. I'd even be willing to sort the non-subscribed emails,
so that everyone else could avoid them...
That would be
Adam K Kirchhoff wrote:
Hey folks,
I'm trying to find out the branch to use for NetBSD. I know that
Eric Anholt posted it here in the not-too-distant past, but I can't seem
to find the e-mail from him anywhere (and the search mechanism on
sourceforge doesn't seem to be working).
Also, would
Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86
Pasi Kärkkäinen wrote:
On Fri, Feb 07, 2003 at 07:27:42AM -0700, Brian Paul wrote:
Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6
David Dawes wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
this function doesn't exist in XFree86 trunk, nor DRI trunk (going by
grep), how ever it is used in
Alan Hourihane wrote:
On Fri, Feb 07, 2003 at 11:26:53AM -0500, David Dawes wrote:
On Fri, Feb 07, 2003 at 08:36:27AM -0700, Brian Paul wrote:
David Dawes wrote:
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
in XFree86 log
Symbol xf86strtof from module
/usr/X11R6/lib
Ian Romanick wrote:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Ian Romanick wrote:
[...]
Regarding glean, I need to test again, but I was seeing some other
failures even with the mesa-4-0-4 and trunk. I think there were some
off-by-one scissor errors and a couple of others. One question I
Leif Delgass wrote:
On Thu, 6 Feb 2003, Brian Paul wrote:
The mask values indicate which bits in the pixel (word) correspond to each
color channel. The buffer size is the sum of the red, green, blue, and alpha
bits.
Mach64/R128
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 6 Feb 2003, Brian Paul wrote:
The mask values indicate which bits in the pixel (word) correspond to
each color channel. The buffer size is the sum of the red, green,
blue, and alpha bits.
Mach64/R128
r g b a amaskbsz ar ag ab aa
Alexander Stohr wrote:
first let me separate the framebuffer data from GL data
by four more spaces.
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
alphaMask should be
Leif Delgass wrote:
Well, the interesting thing is that when running X at depth 24 w/ 32 fbbpp
on Radeon, glxinfo still shows buffer size as 24 after the patch. Is this
because it's being intersected with the X visual depth of 24? Afaik,
there's no such thing as a depth 32 in the Xserver
Keith Whitwell wrote:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar
circumstances, but goes into an infinite loop inside
DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value
301 - 400 of 682 matches
Mail list logo
