Martin Spott wrote:
> The scenery that moves underneath is moving at different speed - not only
> dependent on the actual airspeed of my plane. It looks like the plane would
> move somewhat slower for half a second and another half second it moves a
> little bit faster so the picture is in sync w
"K. Petersen" wrote:
>
> I have come upon a reproducible lockup on my system when switching from a
> console virtual terminal to X. It can be produced as follows:
>
> Begin X
> Switch back to a virtual console
> Switch back to X
Does this cause the problem every time?
Also, just to confirm...
On Thu, 11 Apr 2002, Jens Owen wrote:
> "K. Petersen" wrote:
> >
> > I have come upon a reproducible lockup on my system when switching from a
> > console virtual terminal to X.
>
> [...]
>
> > I believe this to be the correct forum for this issue, but if it is not,
> > then feel free to forwar
Jose,
Thanks for doing this. I forgot to mention a couple of items on
monday. Here's some updates.
"José Fonseca" wrote:
>
> In the following of last IRC meeting, here is a draft of a FAQ with what
> was said. Comments are welcome.
>
> Regards,
>
> José Fonseca
>
> Binary compatibility
> =
In the following of last IRC meeting, here is a draft of a FAQ with what
was said. Comments are welcome.
Regards,
José Fonseca
Binary compatibility
1. What does binary compatibility means?
It means that that driver binaries made on previous releases
should work
Sergio Vergata wrote:
>
> Hi,
> I'm using
> [drm] Initialized radeon 1.2.0 20010405 on minor 0
>
> and have a problem when I switch to FB console (eg CTRL+ALT+F1)
> and then back to my running X server with DRI support.
>
> It strart building Xscreen but hangs up at 3/4 screen.
> On the local m
> Raystonn wrote:
>
> Odd, I sent a few emails to the list and I have received none of
> them. An hour after that I sent one more and I just got it from the
> list. This leaves me wondering of my other emails have sunken into a
> black hole somewhere...
>
> Has anyone else had these troubles o
> > You know what they found out with all of the hundreds of millions of
> dollars
> > they spent? Dedicated hardware still does it faster and cheaper. Period.
> > It's just like writing a custom routine to sort an array will pretty much
> > always be faster than using the generic qsort. When y
> > Here you are comparing different algorithms. A custom sort algorithm
will
> > perform much better than a standard qsort. I agree. Implementing
something
> > in hardware does not mean it uses a more efficient algorithm however. A
> > hardware implementation is just that, an implementation.
> If you had changed the last but one with the last but two value,
> then your eps would have looked nicer.
I chose that order intentionally. It is the order of screen
resolutions. The last two modes are double scan modes. Even though they
have a lower resolution they are slower, since the pixe
> I thought about it again and made a plot of the fps over the pixel
> clock. This indicates that the different performance is *only* related
> to the CRT refresh. This is the Octave code I used to
> generate the plot:
>
> modes=[125.00; 115.50; 69.65; 45.80; 57.75; 34.83];
> fps =[155.20;
> You aren't running the app maximized, are you? :-)
No :-), I the app is always the same size.
I thought about it again and made a plot of the fps over the pixel
clock. This indicates that the different performance is *only* related
to the CRT refresh. This is the Octave code I used to generate
Jose Fonseca wrote:
>
> On Thu, 2002-04-11 at 15:35, Felix Kühling wrote:
> > Hi,
> >
> > I recently found out that the 3d performance of the mach64 branch (in
> > terms of glxgears frame rates) is related to the physical screen
> > resolution. I got the following glxgears frame rates with differ
> I recently found out that the 3d performance of the mach64 branch (in
> terms of glxgears frame rates) is related to the physical screen
> resolution. I got the following glxgears frame rates with different
> resolutions:
>
> 1152x864: 155.2 fps
> 1024x768: 165.6 fps
> 800x600: 209.6 fps
>
On Thu, 2002-04-11 at 15:35, Felix Kühling wrote:
> Hi,
>
> I recently found out that the 3d performance of the mach64 branch (in
> terms of glxgears frame rates) is related to the physical screen
> resolution. I got the following glxgears frame rates with different
> resolutions:
>
But with
Felix Kühling wrote:
> Hi,
>
> I recently found out that the 3d performance of the mach64 branch (in
> terms of glxgears frame rates) is related to the physical screen
> resolution. I got the following glxgears frame rates with different
> resolutions:
>
> 1152x864: 155.2 fps
> 1024x768: 165.
[Sorry, my last message got sent a little early.]
Hi,
I recently found out that the 3d performance of the mach64 branch (in
terms of glxgears frame rates) is related to the physical screen
resolution. I got the following glxgears frame rates with different
resolutions:
1152x864: 155.2 fps
1024x
Hi,
I recently found out that the 3d performance of the mach64 branch (in
terms of glxgears frame rates) is related to the physical screen
resolution. I got the following glxgears frame rates with different
resolutions:
1152x864: 155.2 fps
1024x768: 165.6 fps
800x600: 209.6 fps
640x480: 2
"José Fonseca" wrote:
>
> On 2002.04.11 07:40 graeme fisher wrote:
> > Hi,
> >
> > Does anyone know if there is a detailed porting guide for porting a
> > graphics driver using Mesa 3.x to one using Mesa 4.x.
> >
>
> Is not really a porting guide but by comparing the following notes you get
> a
On Thu, 2002-04-11 at 15:34, Martin Spott wrote:
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread 1024 (LWP 1417)]
> 0x4763b4ff in _mesa_test_os_sse_exception_support ()
>from /usr/X11R6/lib/modules/dri/radeon_dri.so
That's the SSE test, just continue.
--
Ear
> If you can ssh in, can you run the program from gdb from a ssh session?
>
> export DISPLAY=:0
> gdb `which fgfs`
> run
>
> and see if you get 'Error could not get dma buffer... exiting' when your
> main machine locks up?
I see something totally different - whithout any FlightGear window showi
Hi,
I'm using
[drm] Initialized radeon 1.2.0 20010405 on minor 0
and have a problem when I switch to FB console (eg CTRL+ALT+F1)
and then back to my running X server with DRI support.
It strart building Xscreen but hangs up at 3/4 screen.
On the local machine i can do nothing via remote i can w
Good Job! :)
I sended mail to S3 Graphics and there was no answer too.
Now I'm going to download for your searching result. :)
Thank you. :)
- Original Message -
From: "José Fonseca" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 11, 2002 4:10 AM
Subject:
On Thu, 11 Apr 2002 00:26:17 -0700
"Raystonn" <[EMAIL PROTECTED]> wrote:
> Here you are comparing different algorithms. A custom sort algorithm will
> perform much better than a standard qsort. I agree. Implementing something
> in hardware does not mean it uses a more efficient algorithm howev
[EMAIL PROTECTED] wrote:
>
> Patches item #542220, was opened at 2002-04-10 22:47
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=300387&aid=542220&group_id=387
>
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: John
Jens Owen wrote:
>
> [Note: This e-mail get's into some additional design discussions, so I'm
> adding anybody who has responded to the DRM discussion to the CC list,
> to circumvent the sourceforge e-mail log jam.]
>
> Alan Hourihane wrote:
> >
> > On Fri, Apr 05, 2002 at 07:46:59 -0700, Jens O
On 2002.04.11 07:40 graeme fisher wrote:
> Hi,
>
> Does anyone know if there is a detailed porting guide for porting a
> graphics driver using Mesa 3.x to one using Mesa 4.x.
>
Is not really a porting guide but by comparing the following notes you get
a good picture:
http://dri.sourceforge.ne
> You know what they found out with all of the hundreds of millions of
dollars
> they spent? Dedicated hardware still does it faster and cheaper. Period.
> It's just like writing a custom routine to sort an array will pretty much
> always be faster than using the generic qsort. When you hand-tu
28 matches
Mail list logo
