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.
Also, roughly how much time would it take to do the port?
Thanks
Graeme
___
Dri-devel mailing list
[EMAIL PROTECTED]
On Wed, 10 Apr 2002, Steven Paul Lilly wrote:
Hi! Is it possible to have both the video features of my aiw radeon
working and the latest (tcl) 3d working at the same time? The two don't
seem to want to work at the same time for me.
Typically I merge the code from DRI or XFree86 CVS as
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-tune
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:
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 Owen
[EMAIL PROTECTED] wrote:
Patches item #542220, was opened at 2002-04-10 22:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=300387aid=542220group_id=387
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Knottenbelt
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 however. A
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:
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
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 showing
up
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.
--
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 good picture:
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:
[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
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.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 the
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:
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 different
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
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;
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 pixel
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. It
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
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 on this
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 machine i
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
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
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 forward me to the
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...you
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 with
30 matches
Mail list logo
