On Fri, 8 Mar 2002, Jens Owen wrote:
I've moved this field to the end of the structure and the libGL.so
compatability issue appears to be fixed.
Hmmm, that might be good enough, but I'm not 100% certain.
I'm worried that my hack of moving it to the end could possibly end up
writing over
On Monday 11 March 2002 01:55, Frank C. Earl wrote:
On Sunday 10 March 2002 11:44 am, Jos? Fonseca wrote:
I really don't know much about that, since it must happened before I
subscribed to this mailing list, but perhaps you'll want to take a look
to the Utah-GLX and this list archives. You
-duisburg.de/Radeon/FlightGear-20020311.tar.gz
It will appear there in about half an hour. You may skip /usr/local/lib/ and
/usr/local/lib/, it's only for building the stuff. The binary is statically
linked against libmk4. You should place .fgfsrc into you home directory.
If you encounter
I'm placing a ready to run binary package on:
Sorry, forgot two things:
- The binary you want to run is /usr/local/FlightGear/bin/fgfs
- Yes, you really _need_ all that stuff in /home/fgfsbase (or put it
elsewhere and change the location in ~/.fgfsrc),
Martin.
--
Unix _IS_ user friendly
Hi all
There are problems with the bleeding edge binaries:
1. First of all, the kernel module cannot be loaded because of some
unresolved symbols. And even when I do rm *.o, make, the resulting
mach64.o has some unresolved symbols (on depmod)! I do not know how it
is possible. insmod -f manages
On Mon, 2002-03-11 at 14:37, Sergey V. Udaltsov wrote:
Hi all
There are problems with the bleeding edge binaries:
1. First of all, the kernel module cannot be loaded because of some
unresolved symbols. And even when I do rm *.o, make, the resulting
The .o shouldn't be packaged, or even
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 the
Just a reminder of the weekly #dri-devel meeting on
irc.openprojects.net at 4pm EST today. That's 2100 UTC, and
1pm PST.
--
--
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190
I've got two radeons:
Radeon Mobility M6 LY in a couple laptops
Radeon RV200_QW in a desktop
that I'm having troubles with.
On the desktop machine, I'm running the TCL-0-0 branch from DRI, built
yesterday
glxgears shows a black window with a reasonable frame rate
Hello there,
I have just finished parrallelisation of Mesa vertex transformation and
found that as the Vertex buffer is quite small (~100 verticies to the nearest
order of magnitude) twhen using SMP vertex transformation you get no
noticable performance gain because of the parrallelisation
On Mon, 2002-03-11 at 21:17, Keith Packard wrote:
I've got two radeons:
Radeon Mobility M6 LY in a couple laptops
Radeon RV200_QW in a desktop
that I'm having troubles with.
XFree86 4.2 doesn't have the cool features of the CVS code you're
running but has been very solid
Q3A and RTCW don't take advantage of SMP on Linux yet. I have some patches
that need to be applied and a bit of testing to do first. Things got
delayed, but I'm still planning on releasing this.
regards
TTimo
--
Linux technology contract - Id Software inc.
On Mon, 11 Mar 2002 20:10:50 +
The .o shouldn't be packaged, or even built. I'll have to check why this
is happening.
Well, hope the next version will be free of these wrong object files.
Could you please past the output of insmod to see what are the failed
symbols?
Well, now it is OK. Sorry for disturbing on this issue.
On Mon, Mar 11, 2002 at 09:45:20PM +0100, Timothee Besset wrote:
Q3A and RTCW don't take advantage of SMP on Linux yet. I have some patches
that need to be applied and a bit of testing to do first. Things got
delayed, but I'm still planning on releasing this.
Heh...people have been waiting
Brian Paul wrote:
One question to ask is: regardless of the vertex buffer size, typically
how many vertices are issued between glBegin/End or state changes? Does
Q3 (for example) render any objects/characters with 1000 vertices?
Never. The maximum size of any locked array from the Q3
Keith Whitwell wrote:
Keith Whitwell wrote:
Jens Owen wrote:
Michael Fitzpatrick wrote:
Log message:
Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow
problem in Tuxracer)
Good work Michael. You got the Red Out! :-)
I am seeing
On 2002.03.11 21:41 Gareth Hughes wrote:
Seriously guys, this kind of thing is the last thing you should be
worrying about, at least until you have a working DMA implementation and
a fully-featured Mesa 4.x driver...
Just my 2c.
-- Gareth
Gareth, it's not a question of worrying. I
On Mon, 2002-03-11 at 20:37, Michael wrote:
If I run X at 640x480, 800x600 or 1280x1024 I get about 86.5 fps with
q3demo running @ 640x480 (86.5 because I've got debug code to print out
the total texture size which was 5mb so that's not an issue)
If I run X at 1024x768 (q3 still at
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
Heya,
I have a Radeon Mobility M6 LY running on a notebook using the i830 AGP
Chipset.. I was wondering is support for the i830 chipset rather flakey
at the moment, or is the radeon not well supported at this stage?
I have been able to get DRI/3D going but not consistently.. anytime I
run the X
Around 20 o'clock on Mar 11, Keith Whitwell wrote:
7500's aren't working with the driver in at least two different ways. The
first is the 'black window' problem - depth clears aren't working, the lockups
are yet to be investigated.
Thanks muchly. I'd offer to help, but I'm afraid I would
On Mon, Mar 11, 2002 at 08:34:15PM +, Keith Whitwell wrote:
Is this windowed or fullscreen?
It's actually both, but the testing and figures above were fullscreen.
glxgears is about 200fps slower in 1024x768 v 1280x1024 et al.
Hmm, having thought about it, I'm pretty sure that this didn't
22 matches
Mail list logo
