Brian Paul wrote:
Just a quick note:
I was hoping to have released Mesa 4.0.2 by now but a trickle of bug
fixes and other odds ends have delayed it. I think I'm really close
to a release now, but I don't know if I'll get to it this weekend.
After I've done so, it would be good
I just discovered that my recent check-ins break the build in the server-side
GLX/Mesa code. I'm working on a fix now.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Jens Owen wrote:
Brian Paul wrote:
Jens Owen wrote:
Jens Owen wrote:
It looks like a new field was recently added to the GLXContextRec
xc/lib/GL/glx/glxclient.h:407
GLXDrawable currentReadable;
I added that last summer when I was implementing
Michael wrote:
On Sun, Mar 10, 2002 at 11:53:19PM +, Michael wrote:
At the moment 1024x768 (which I expected to get the biggest benefit)
hits lack of texture space and/or maybe depth clears / lack of
hierarchical z, even with the pixmap cache set to 1 page and low
texturing - at
Jens Owen wrote:
Jens Owen wrote:
It looks like a new field was recently added to the GLXContextRec
xc/lib/GL/glx/glxclient.h:407
GLXDrawable currentReadable;
I added that last summer when I was implementing the GLX_SGI_make_current_read
extension (glXMakeCurrentReadSGI()
Leif Delgass wrote:
On Mon, 4 Mar 2002, José Fonseca wrote:
On 2002.03.04 19:13 Leif Delgass wrote:
On Mon, 4 Mar 2002, José Fonseca wrote:
But why does the number of levels has to do with the maximum texture
size?
As I understand it, a mipmapped texture is
Jose Fonseca wrote:
On Thu, 2002-03-07 at 17:23, Brian Paul wrote:
...
You seem to have been confused by texture levels before. Looks like
you've figured it out now. It's basically the maximum number of mipmap
levels AND it's related to max texture size.
-Brian
Right after I
Jose Fonseca wrote:
Nevertheless I didn't found an explanation of why the maximum texture
size was being derived from the maximum texture level in Mesa. In the
specs it says that the the maximum allowable size of a texture must be
_at least_ 2^(k-lod)-2*b_t , and not equal.
On
Pasi Kärkkäinen wrote:
Hello!
Any plans yet about supporting OpenGL 2 in Mesa (and DRI) ?
No, not yet.
How much work will it require to have basic OpenGL 2 support in Mesa?
Hard to say before the spec is finished. It'll be some time before
2.0 is finalized and it's not at all clear
. Red Hat
Linux ships Mesa 3.4.2 from mesa3d.sf.net instead of the Mesa
that comes with XFree86 as it supports software OpenGL with 3.3.6
servers. We patch it with DRI support so that DRI works.
I emailed quite a while back asking about this, and Brian Paul
went ahead and implemented
Mike A. Harris wrote:
On Tue, 26 Feb 2002, Brian Paul wrote:
what I understood, 3.3.6 doesn't use GLX, which is why it didn't
work. I'm not quite clear on all of this however, so please
correct me if I'm wrong.
Hi Mike,
Sorry for not replying sooner. XFree86 4.2 does
#dri-devel on irc.openprojects.net
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Jose Fonseca wrote:
Luckily, after sending the previous email the script completed
sucessfully. The generated packages are available at:
http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/
Unfortunately, as you can notice the packages are huge. Attached is a
file list of the i810
Andy Furniss wrote:
On Tuesday 19 February 2002 12:33 am, you wrote:
Cool. I have Wolfenstien running on my system with Voodoo3 and it seems
to work fine. I was afraid this was going to be a really ellusive bug.
-Brian
I also run Wolfenstein on a Voodoo3 2000 - It works fine at
Robin Redeker wrote:
Hi,
i am just writing on a Gtk-application which uses
the GtkGLWidget for displaying OpenGL stuff.
When using the DRI-OpenGL-library which is delivered with
Xfree 4.1.0 and too tested with xfree 4.2.0, the programm crashes.
With a memory-debugger its saying memory
Robin Redeker wrote:
On Wed, Feb 20, 2002 at 09:08:22AM -0700, Brian Paul wrote:
Robin Redeker wrote:
[.snip-snap.]
Could you link your app with electric fence (-lefence) and see if
it detects the out-of-bounds write?
-Brian
Heh, it crashes earlier when linking with efence
Gareth Hughes wrote:
Brian Paul wrote:
OK, it looks like the templatized code for texture image conversion is
the problem. It's using the CONVERT_TEXEL_DWORD macro even when the
texture width is one, causing an out-of-bounds write.
I'll fix this up, Gareth :)
Hmmm, looks like
José Fonseca wrote:
On 2002.02.19 14:36 Michael Thaler wrote:
On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote:
...
(II) ATI(0): Direct rendering enabled
It definitely says direct rendering is enabled!
Yes. That's is definitely true.
...
I still get:
Ian Romanick wrote:
On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote:
What is the name of the extension? Since it's not implemented in the DRI,
I can tell for sure that it's not used on linux, and it's likely not used
on win32 either (at least for Q3, the number of
Dieter Nützel wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
Wolfenstein crashes after playing the intro at line 494 in
r128_texstate.c with an assert t failed message.
How do other drivers handle the same point?
I've updated the DRI user guide and compilation guide on the website
to reflect the current DRI source tree.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Ian Romanick wrote:
What follows is my understanding of the texture management system in the
DRI. This is all based on the Radeon driver in the 11-Feb-2002 CVS of the
mesa-4-0-branch. While it is based on the Radeon code, all drivers except
gamma and tdfx seem to use the same scheme (and
of the internal structure of Mesa and is
meant for those who are interested in modifying or enhancing Mesa, or just
curious.
[Note]
Based on the original Mesa Implementation Notes by Brian Paul.
3.3.5.1. Library State and Contexts
OpenGL uses the notion of a state machine. Mesa encapsulates
José Fonseca wrote:
On 2002.02.09 15:17 Brian Paul wrote:
Those implementation notes are _really_ dated (probably 5 years old).
I don't have time to edit/update them so please put a notice at the
beginning that this information is out of date and that the current
code diverges from
are interested in modifying or enhancing Mesa, or just
curious.
[Note]
Based on the original Mesa Implementation Notes by Brian Paul.
3.3.5.1. Library State and Contexts
OpenGL uses the notion of a state machine. Mesa encapsulates the state in
one large struct: gl_context, as seen in types.h
Vladimir Dergachev wrote:
On Fri, 8 Feb 2002, Brian Paul wrote:
Vladimir Dergachev wrote:
Would anyone know what was wrong with support for Radeon third texture
unit ?
The problem is that Mesa 3.4 only supported two texture units (there were
some bitfields that didn't have
Jose Fonseca wrote:
On Tue, 2002-02-05 at 14:50, James Hawtin wrote:
Is there a guide on how to setup DRI? I have never managed to ...
... to go to the DRI website and search for documentation? ;-)
Check http://dri.sourceforge.net/doc.phtml
It covers most of your questions!
Keith Whitwell wrote:
Michael wrote:
Attached patch fixes a bug where a newer texture state is disabled
prior to FlushPrims being called.
(examples : ground texture in rollercoaster doesn't display, various
glitches on mp_beach (maybe others?) in rtcw)
--
Michael.
Michael,
, Descent and glxgears.
There is (or used to be) a test suite which an implementation had
to pass in order to use the OpenGL logo.
I think that money might have been involved too, although Mesa might
have been offered an exemption.
Anybody (Brian Paul?) know the details ?
You're
Nobody's suggested a time yet. So I'll propose 12:00pm PST (3:00 EST)
so that those in Europe can more likely join in. That's about 2:15
from now.
Is that OK with everyone? I realize it's short notice but if we push
it much further back it'll be harder for those in the UK to join in.
-Brian
Dan wrote:
http://www.theregister.co.uk/content/54/23708.html
This does not look good for OpenGL / DRI.
The article is not very specific though.
I assume that xfree86 doesn't use anything affected by these patents,
otherwise it wouldn't be able to carry it's current license. Is this
Nick Hudson wrote:
My libglide3.so is located in /usr/lib.
Could this have something to do with it?
libGL error: dlerror() message: /usr/lib/libglide3.so: undefined symbol:
_trisetup_3DNow_win_nocull_valid
I donno but its there maybe the permissions arent set right?
My mistake, the
Dark Avenger wrote:
Re: 1) Seg. Fault and Xlib: unexpected async reply (sequence 0x1728)!
Re:
Re: I remember seeing problems like this when I was debugging multi-threaded
Re: apps. Does XMMS use threads in conjunction with OpenGL?
Yes sir, OpenGL + threads. The error above is, like
Dark Avenger wrote:
Subject: 5-10 lines of code. Do u see a bug?
Using XMMS 1.2.5 and the plugin OpenGL Spectrum Analyzer 1.2.5 that comes with it
gives errors on both X11 4.1.0 w/ DRI + tdfx driver and NVidia OGL driver. The errors
are of type:
1) Seg. Fault and Xlib: unexpected
Derrik Pates wrote:
Brian Paul wrote:
I remember seeing problems like this when I was debugging multi-threaded
apps. Does XMMS use threads in conjunction with OpenGL?
It's multithreaded, yes. The plugins generally run as separate threads.
I did try the fix that Dark Avenger
Gareth Hughes wrote:
On Fri, Dec 14, 2001 at 02:54:33PM -0500, [EMAIL PROTECTED] wrote:
I am seeing this too. I thought it was from me tweaking
stuff. Interestingly enough, quake works fine.
Is there any kind of DRM/DRI test app along the lines of x11perf ?
Quake3, viewperf... :-)
Leif Delgass wrote:
On Tue, 11 Dec 2001, Brian Paul wrote:
Sergey V. Udaltsov wrote:
Hi all
Is it possible to turn on/off some particular GL extenstions in Mach64
driver? Is mesa.conf in any help here? I would like to play with
texture-related extensions (probable
Sergey V. Udaltsov wrote:
Hi all
Is it possible to turn on/off some particular GL extenstions in Mach64
driver? Is mesa.conf in any help here? I would like to play with
texture-related extensions (probable, turning GL_ARB_multitextures off
would solve my problems in celestia?)
You can
Dag B wrote:
Hi.
I am sure these questions are answered in a FAQ, but I couldn't find this
info on the mesa website nor in the xfree86 docs. (May have overlooked
something.)
1.
XFree86 4.1.0 contains (pieces of) Mesa 3.4.2.
The most noticeable exception being glut, I guess.
Are
Jeff's in the process of moving from Colorado to Oklahoma. I'm sure
he'll tend to this when he gets settled in.
-Brian
--- Leif Sawyer [EMAIL PROTECTED] wrote:
Don't know if this will get through or not, but since Jeff doesn't seem
to (want to?) respond directly, perhaps somebody on this
Dieter Nützel wrote:
Anybody (Brian, Keith?) working on the Mesa-3.5-tree?
I've didn't see any activity for some days/weeks, now.
Here's the deal. The DRI developers, including myself, have been laid-off
from VA Linux. Today (Friday) is my last day.
There's an effort to relocate us to a
Janne Pänkälä wrote:
At the moment I'm open for suggestions that my motherboard is like
seriously fucked up. :(
I'd like to remove previous comment from the book... ;)
played UT in w2k for 3hours without any problems. Hence I deduct it is
probably something with tdfx_dri.so I guess.
Gareth Hughes wrote:
Brian Paul wrote:
I've looked into this a bit more. Looks like the token
is incorrectly defined to be 11 in
the current driver. It should be 12 in order to support 2Kx2K
textures. It looks like this can safely be changed from 11 to 12
without a kernel module
I'm planning on releasing Mesa 3.5 (the stand-alone version) tomorrow.
I'm also working on finishing up the mesa-3-5-branch in DRI CVS.
We still have to bring the Mesa 3.5 sources into the DRI tree and then
merge the DRI trunk into the mesa-3-5-branch branch to get all the
XFree86 4.1 updates.
If anyone has anything to add to the mesa-3-5-branch in CVS
let me know soon. I'd like to tag the branch tomorrow (with
mesa-3-5-20010621-freeze) and then begin the merge from the trunk.
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
Adam Williams wrote:
Using a Radeon 64MB, XFree86 4.1.0, kernel 2.4.5-ac16
Currently it looks like the largest texture I can upload is limited to
the nearest 2^n pixels below the horizontal resolution of the screen.
Is there any way to work around this and get a 2048x2048 texture on a
[EMAIL PROTECTED] wrote:
Good point - I have X4.1.0 and kernel 2.4.5, and no DRI with my Radeon under
Linux.
2.4.5 gives me radeon.o in /lib/modules/blah
X4.1.0 gives me a radeon_drv.o somewhere in /usr/X11R6/lib
insmod /path/to/it/radeon_drv.o doesn't do anything,
insmod radeon.o
Mike A. Harris wrote:
Does the DRM module code shipped with 4.0.3 work with a 2.2.x
kernel, or is it 2.4.x only?
The DRI requires 2.4.x.
Also, is 3.3.6 affected by DRM module changes at all? I have
never gotten into the 3.3.6 code much at all and don't believe it
uses DRI does it? I
[EMAIL PROTECTED] wrote:
Just wondering if anyone else saw something like this unresolved symbol
in their X11 logs:
(II) TDFX(0): Primary V_BIOS segment is: 0xc000
(II) TDFX(0): VESA BIOS detected
(II) TDFX(0): VESA VBE DDC supported
Symbol DRIMoveBuffersHelper from module
Pontus Hedman wrote:
Either submit the patch here if it's small enough, or submit
to patches on the DRI sourceforge page.
Ok; it's a trivial one-liner to r128ConvertTexture32bpp.
See below.
It's probably more of a workaround than a fix
(the image passed in from r128UploadSubImage()
zifnab wrote:
I am running CVS from Tuesday and I was playing Tribes 2 with no problem.
Then I came back a few hours later and started it up again. It took quite
a while to start up (at first I thought X had crashed but then Tribes
finally started). When I started to play it was painfully
Mike A. Harris wrote:
On Wed, 6 Jun 2001, Digital Z-Man wrote:
I'll read the agreement, but your statement about applying to join
the development team gives me the impression that there is a secret
magic ring. Just my observation.
Well ok then, there is a secret ring. If you don't
Mike Westall wrote:
We have an application (``instant'' radiosity) that needs to read
back depth information from the graphics card. We find that this
operation appears to work fine
(1) using software only rendering (e.g. by not loading r128.o
and
(2) on Nvidia GeForce2's
It
Pierre Letouzey wrote:
Sorry for the multi-purpose mail
1) Remarks concerning the installation of tdfx-0.7:
- first I was dummy enough to try installing without the Extras packages,
so I first got a ABI version error. I Read the F... Manual, and solved
this trouble.
- second and
Eric Anholt wrote:
I figured out (kind of) why the v5 causes segfaults in GL apps on FreeBSD.
It seems that when we try to dlopen() the extra symbols for v5, the dlopen
passes but the subsequent dlsym()s fail, so we end up executing these null
pointers at the first glide extension call. By
John Tobin wrote:
I have been monitoring the DRI since it first began and I have just
one question regarding the MGA driver.
I was wondering if you consider it to be functioning at the highest
performance that you can get out of it?
I ask this because I have been doing benchmarking
Mike A. Harris wrote:
I would like to know given x Mb of video RAM on a given DRI
supported video card, how can I calculate what the maximum
screen resolution should be?
width * height * fbbpp / 8 == 2D screensize
I'll need to take virtual screen dimensions into account, as well
as
I've taken a stab at fixing the libglide3.so for Voodoo3 vs Voodoo5 problem.
Basically, the tdfx driver looks at the screen's device ID and either loads
libglide3-v3.so or libglide3-v5.so (filenames not finalized) with dlopen()
and initializes a table of per-context Glide function pointers
Mike A. Harris wrote:
On Sat, 19 May 2001, John Cavan wrote:
I tried building the trunk code (according to the guide) and have run
into a raft of errors in the Mesa portion of the tree. Some sample error
messages:
gcc -E common_x86_asm.S common_x86_asm.s
common_x86_asm.S:37:22:
Petr Sebor wrote:
[snip]
With a test program I've determined that GL_LINEAR_MIPMAP_NEAREST and
GL_NEAREST_MIPMAP_LINEAR seem to be transposed. I think the Radeon
docs may be in error.
Try GL_NEAREST_MIPMAP_LINEAR in your program and see if that has the
desired effect. I'll
Petr Sebor wrote:
Hello,
I have reported this earlier, but this is a confirmation that
GL_LINEAR_MIPMAP_NEAREST is still broken in v0.7 with radeon 32 ddr.
Just to sum it up - first mipmap is rendered correctly with LINEAR filtering while
subsequent mips are rendered with NEAREST
Peter Ronnquist wrote:
I am trying to figure out how to update the screen
during vertical retrace. Is this possible to do with
glx(swap buffers) and using dri?
Maybe I have to set some configuration in
XF86Config-4?
Please CC me with replies since I am not currently
subscribed to
Jeffrey W. Baker wrote:
On Mon, 14 May 2001, Brian Paul wrote:
At first I was going to suggest a memory management bug in the driver
but after a quick check I see that the maximum viewport size in
Mesa 3.4.1 is 2048 x 1200.
I didn't realize that people were running screens
Allen Barnett wrote:
Hi,
Attached is a small example (test4.cpp) of using the Qt OpenGL widget to
draw a white filled triangle. I was hoping that someone else could try
it out and see if they get the same results I do. Here is a table of
what I see:
Video Rendering Method Result
Kreuzritter2000 wrote:
Hello
It would be great if there is a feature list on the dri website.
That tells the progress of the driver, in other words what features
of the Chip ist are allready supported and what features are not support.
In the moment the Driver status page only tells
Mark Allan wrote:
Mark Allan wrote:
Brian Paul wrote:
Pasi Kärkkäinen wrote:
Hello!
Are there known blending bugs in the mga-driver (g400)? When I render many
additive polygons on the top of each other with small alpha-value
(something like 0.05) the result
Kreuzritter2000 wrote:
Hello
I made some Benchmark comparisons with my Video card under WinME and Linux,
here are the resulst:
Perhaps using the new tdfx driver branch 3.1, DRI inbuild Mesa 3.5 and Kernel 2.4
could be a little
bit faster.
It might be a bit faster but I haven't
Andreas Ehliar wrote:
On Sun, Apr 29, 2001 at 10:56:42PM -0700, Frank Worsley wrote:
The DRM module from the DRI CVS seems to work fine in 2.4.4.
(The one in the kernel however does seem to be broken.)
Isn't it generally best to use the module from the CVS/packages in any
case, no
I've ported David's new Imakefile system for lib/GL from the trunk
to the 3.5 branch. My changes are checked in and I'm in the middle
of a test build on my second system. I might not be able to check
on whether it completes until tomorrow, however.
Alan, I had some trouble getting the gamma
Joseph Carter wrote:
I have occasionally seen replies to CVS commit messages on this list, but
I don't find a place where CVS commit messages are sent. Is there such a
place? A few people (me for instance) have pending problems which we know
about (in my case, VIA chipset + AGP gart +
Dieter Nützel wrote:
Sorry that I botther you and yes I know it IS under development but I will
try it on my V5 because I found some glitches in the trunk (more on this
tomorrow).
Which configuration are you using?
The old style or some configure stuff?
Mesa-3.5 is there and I have the
Allen Barnett wrote:
Is there a difference (performance or otherwise) between using indirect
DRI rendering (say, with LIBGL_ALWAYS_INDIRECT) and just linking against
the Mesa library?
Yes. DRI libGL used in in indirect mode sends GLX protocol messages
to the X server which are executed by
Allen Barnett wrote:
Brian Paul wrote:
Allen Barnett wrote:
Is there a difference (performance or otherwise) between using indirect
DRI rendering (say, with LIBGL_ALWAYS_INDIRECT) and just linking against
the Mesa library?
Yes. DRI libGL used in in indirect mode sends GLX
Frank Worsley wrote:
Ok, after thinking about this some more I guess there's no point in keeping
the page going as it is, since it doesn't make much sense.
I've made a generic listing of cards, check it out at
http://dri.sourceforge.net/status2.phtml and if it's ok I will replace the
Simon Cahuk wrote:
Hi!
Does DRI work under FreeBSD? Can I compile glide under it (my chip is
banshee)?
It was working at one time, with 3dfx hardware and the G400, I think.
I'm not sure what the status is. I don't think anyone is actively
maintaining FreeBSD support.
I suggest giving it a
Frank wrote:
Don't hesitate to send any messages to the mailing lists! If you are
interested in development subscribe to the dri-devel list.
I've forwarded your message to the list.
- Frank
- Original Message -
From: "David Gaarenstroom" [EMAIL PROTECTED]
To: [EMAIL
Buddy Smith wrote:
Hi.
This is a patch i made to add the RADEON VE chipset to the DRI source.
It's available at
http://foobar.resnet.gatech.edu/~nullset/radeon_ve-DRI-patch
I did not post it to the patch list, because i'm not sure if the format is
correct. i generated it using
Philip Willoughby wrote:
Today, Daryll Strauss wrote:
On Fri, Apr 20, 2001 at 05:24:37PM +0100, Alan Hourihane wrote:
On Fri, Apr 20, 2001 at 05:17:25PM +0100, Philip Willoughby wrote:
Is there a good reason for the xc directory nested in the DRI CVS xc
directory? I ask because it
Bill Currie wrote:
Getting the following (and tired of many lines of ? when I do a cvs up), I've
prepared some .cvsignore files for the trunk and mesa-3.5 branch of dri cvs.
make[4]: *** No rule to make target
`../../../../extras/Mesa/src/api_arrayelt.c', needed by `api_arrayelt.c'.
David Geldreich wrote:
Hello all,
I am wondering if there is any plan to support quad-buffering in
DRI.
GL_FRONT_LEFT
GL_BACK_LEFT
GL_FRONT_RIGHT
GL_BACK_RIGHT
One of the problems is keeping the flipping of LEFT/RIGHT in sync
with the vertical retrace. If you miss
Kreuzritter2000 wrote:
Hi
I heard somewhere that XFree86 DRI will get a major rework in the
next few months.
What kind of rework are these, what can we expect?
Is there something like a Roadmap?
Where is DRI going to? What will we see in future?
In Joseph Carter's message from
Brian Paul wrote:
Adam K Kirchhoff wrote:
I pulled the DRI cvs this afternoon (main trunk) and gave it a whirl.
X never fully starts up. After about five-ten seconds, the monitor puts
itself to sleep and /var/log/XFree86.0.log ends with:
32 128x128 slots
601 - 682 of 682 matches
Mail list logo
