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
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 woul
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
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
> > texturin
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
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.
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 R
On 2002.03.11 20:56 Sergey V. Udaltsov wrote:
> > 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.
>
Well.. this can take a few days since I have to get some time to mess with
thes
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
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
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
Andrew James Richardson wrote:
>
> 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 performanc
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
> 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 issu
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 +
An
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.
>
> On the desktop machine, I'm running the TCL-0-0 branch from DRI, built
> yesterday
>
> glxgears shows a bl
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
> > texturin
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 s
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 ov
On Sat, Mar 09, 2002 at 11:41:02AM +, José Fonseca wrote:
> > VQ texture compression on Rage Pro? Now, they aren't talking about DXTC,
> > are they? I wouldn't really call the VQ, but then again, I don't write
> > press releases. :) So here's the question for the guys working on the
> > ma
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 (15
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 the mo this is still
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 Pitt
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
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 ev
"Mike A. Harris" wrote:
>
> 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 mov
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" manag
> 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
package on:
http://document.ihg.uni-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 direc
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 archive
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
>w
30 matches
Mail list logo
