Re: [Dri-devel] Mach64 for ppc xf86-log etc
Peter, This is just a very quick reply on the few minutes I have before leaving. I'm sure that someone else on the list may elaborate further and give you indications to what try next. On 2002.04.25 02:02 Peter Andersson wrote: > ... > >> - Copy the Xfree86.0.log to a safe place and post it here. > > Its attatched to this email. Nothing unusual here. >> See if there is any application consuming all processor (top). > > It seems that the X server hangs too since when i try to backtrace it > nothing happens even though only about 2% of the processor are used by > the system processes. And if i try to backtrace before i run glxgears > the X server locks until i have quit gdb.. It's ok if X stops responding, but you should be able to get a stack backtrace anyway. I'm not sure if you need to press Ctrl-C inside gdb to get to the interactive input. You also need to be root to do this. > >> - Do the same steps as above with your opengl application. > > I can´t see that because i have to kill it before the computer (telnet) > responds to any commands. At least i think i am killing it (i am > pressing the x button and then things seem to work again (if you are > using telnet).. This is rather strange.. if you can click in the close button that means that X it's still alive there.. It's still not clear what is failing here.. > >> >> Before attempt to do the above get debug info from the DRM, doing from >> a X console as root: >> After the computer has crashed send that kmsg. > > Attached aswell... There is no kernel oops there. Don't know if the last call there could have problems or not. >> Take the time you need, as this can be a little boring. > > It sure is, but it is worth it! > > I also have another question, the mach64-0-0-4 branch is based on mesa > 4.0.2 right? Just wondering since the libGL is version 1.2 while the > version of libGL you get when compiling mesa 4.0.2 is 1.3.402. I just > thought that this might cause the problems, the libGL for mesa 3.3 (or > something) was called libGL.so.1.2. I just want to make sure that the > software configuration isn´t causing the problems... If when you run 'glxinfo' you see there Mach64 somewhere in the beginning you should be fine. Also, you should be able to run the app as software rendering only too by making: LIBGL_ALWAYS_INDIRECT=1 glxgears > > Peter > You could try to start the GL app (or even the X afterwards) by a remote telnet connection. Just do gdb glxgears run continue (it always breakspoints due to the SSE extensions check) In case there is a segfault you should be able to do "bt", otherwise press Ctrl-C and then get the backtrace. Another thing that needs to be checked, is that the endian is also accounted in the DDX, especially in the atidri.c file. Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] How to allocate DMA memory
On 2002.04.24 23:53 José Fonseca wrote: > Since my last reply that Yahoo hasn't delivering emails to me and I'm > not sure if you'll receive this one or not either. To make things even > worse I'll be away for the next couple days and I don't expect to be > able to check my mail. It's working again. I lost every mail sent between 19:00 and 23:00 GMT. So if someone here did send me a private email, please send it again.. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Thu, 2002-04-25 at 09:29, José Fonseca wrote: > > You could try to start the GL app (or even the X afterwards) by a remote > telnet connection. Just do > > gdb glxgears > run > continue(it always breakspoints due to the SSE extensions > check) No SSE on PPC, and no altivec support yet either... > In case there is a segfault you should be able to do "bt", otherwise press > Ctrl-C and then get the backtrace. > > > Another thing that needs to be checked, is that the endian is also > accounted in the DDX, especially in the atidri.c file. What are you thinking of there? Unless that file accesses the chip in different ways than the rest of the DDX, it should be fine, or 2D wouldn't work either. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Mach64 for ppc xf86-log etc
> Please do the following tasks via telnet and report > back to the list: > - See if there is any application consuming all processor (top). > - Copy the Xfree86.0.log to a safe place and post it here. > - Check if X is still running or not (ps -A | grep X) and > point down > it's pid, and if it is do: > - do "gdb " > - get a backtrace with "bt" and paste to somewhere > - quit "q" > - Do the same steps as above with your opengl application. > > Before attempt to do the above get debug info from the DRM, > doing from a X > console as root: >- rmmod mach64 >- insmod mach64 drm_opts=debug >- cat /proc/kmsg > kmsg.txt > > After the computer has crashed send that kmsg. So far that i know you can only restart kernel modules if their usage count is zero. This means as long as you are running X or some application (even when X is already down) it wont work. if it looks like the console is responsive, it still can prevent your machine from shutting down because the kernel module wont unload due to some module internal inconsistency or fault. successfully restarting X in such a case is unlikely as well. If i dont have remote access to the box i would just try to issu a "vga_reset" to et least get a workable screen and analyze the state. Sometimes console switching helps a tiny bit or restarting X (even if it doesnt work) but dont expect much to work, the system is already screwed. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
>> - Do the same steps as above with your opengl application. >> >> I can´t see that because i have to kill it before the computer (telnet) >> responds >to any commands. At least i think i am killing it (i am >> pressing the x button and then things seem to work again (if you are >> using telnet).. > This is rather strange.. if you can click in the close button that means > that X it's still alive there.. It's still not clear what is failing here.. I was a bit fuzzy in my reply here, i have to press "x" on the keyboard, the x server has definetly got stuck. Peter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Thu, 2002-04-25 at 14:52, Peter Andersson wrote: > > >> - Do the same steps as above with your opengl application. > >> > >> I can´t see that because i have to kill it before the computer (telnet) >> >responds to any commands. At least i think i am killing it (i am > >> pressing the x button and then things seem to work again (if you are > >> using telnet).. > > > This is rather strange.. if you can click in the close button that means > > that X it's still alive there.. It's still not clear what is failing here.. > > I was a bit fuzzy in my reply here, i have to press "x" on the keyboard, > the x server has definetly got stuck. If the app reacts to the button press, that also means the X server is still alive. Or where do you do it? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Mach64 for ppc xf86-log etc
On Thu, 2002-04-25 at 14:27, Alexander Stohr wrote: > > Please do the following tasks via telnet and report > > back to the list: > > - See if there is any application consuming all processor (top). > > - Copy the Xfree86.0.log to a safe place and post it here. > > - Check if X is still running or not (ps -A | grep X) and > > point down > > it's pid, and if it is do: > > - do "gdb " > > - get a backtrace with "bt" and paste to somewhere > > - quit "q" > > - Do the same steps as above with your opengl application. > > > > Before attempt to do the above get debug info from the DRM, > > doing from a X > > console as root: > >- rmmod mach64 > >- insmod mach64 drm_opts=debug > >- cat /proc/kmsg > kmsg.txt > > > > After the computer has crashed send that kmsg. > > So far that i know you can only restart kernel modules if their > usage count is zero. This means as long as you are running X > or some application (even when X is already down) it wont work. > > if it looks like the console is responsive, it still can prevent > your machine from shutting down because the kernel module wont > unload due to some module internal inconsistency or fault. Kernel modules don't need to be unloaded prior to shutdown. If that doesn't work, it may be that kernel internals got messed up by a buggy module. > successfully restarting X in such a case is unlikely as well. > > If i dont have remote access to the box i would just try > to issu a "vga_reset" to et least get a workable screen > and analyze the state. No VGA console on Macs, but fbset can help sometimes. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
Michel Dänzer wrote: >On Thu, 2002-04-25 at 14:52, Peter Andersson wrote: > - Do the same steps as above with your opengl application. I can´t see that because i have to kill it before the computer (telnet) >> >responds to any commands. At least i think i am killing it (i am pressing the x button and then things seem to work again (if you are using telnet).. >> >> >>>This is rather strange.. if you can click in the close button that means >>>that X it's still alive there.. It's still not clear what is failing here.. >>> >>I was a bit fuzzy in my reply here, i have to press "x" on the keyboard, >>the x server has definetly got stuck. >> > >If the app reacts to the button press, that also means the X server is >still alive. Or where do you do it? > > Actually i wish i could answer that. Since the screen freezes and the upper part of the screen turns into what looks like two small console windows who are syncronised, eg if i type something it shows in "both windows". Unfortunatley the font is too small to read, although if i make an effort i can read some of it, if you are interested i can post it to you. So i don´t know if the whole X server crashes into console mode or if an x-term pops up (but that has never happened to me before). Peter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Linux DRM update to 2.4.18 first draft.
I have a good start on a Linux DRM update. Alan was right all linux-drm-2.4.0
needed was rming Make.linux Imake mv Make.kernel to Make, theses are a given
for any and Linux DRM update, and *** FIX ME ***
*** removing agpgart dependency on radeon ***
was the only big change I made. Other changes made are numerous updates, 3dlabs
GMX 2000 is working now *I hope*, sis renamed to i830 (or one was removed and
the other added), dr{i,m}stat.c added, ffb_context.c removed.
The patch is avaliable http://The Low Bandwidth Server
/~cheako/linux-drm-4.2.0-kernel-2.4.18-patch.gz
E-Mail me for a copy, or just grab it if I all ready gave you the address. (I
just don't want 400 ppl dloading it)
It is only 40k (compressed) so I could post it to the list.
I do wonder if there are any known bugs that I should fix. There are major
changes in the CVS. If there is another snapshoot I should use drop me a line.
__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
Actually, this sounds like what happens if X crashes and drops you to a terminal without resetting some of the video. The screen is probably twice as wide and high as it should be for console, so the left "console window" is scan lines 0,2,4,.. and the right one is scan lines 1,3,5 - which would normally have wrapped at the screen pitch for console. Then the bottom of the screen has whatever was left in the video buffer before. Just a guess, but it sounds like something I've seen long ago. -Oly ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Mike Mestnik wrote:
>
> I have a good start on a Linux DRM update. Alan was right all linux-drm-2.4.0
> needed was rming Make.linux Imake mv Make.kernel to Make, theses are a given
> for any and Linux DRM update,
Great.
> and *** FIX ME ***
> *** removing agpgart dependency on radeon ***
> was the only big change I made.
Was this because the PCI GART functionality was added to the Radeon
driver?
> Other changes made are numerous updates,
> 3dlabs GMX 2000 is working now *I hope*,
I didn't see any patches to the gamma* files, what changed for gamma?
> sis renamed to i830 (or one was removed and the other added),
I realize the SiS driver is lagging behind in the current development
branch and will probably end up with 3D support disabled in XFree86 4.3
unless SiS can make documentation or engineering bandwidth available.
However, Thomas Winischhofer has been working hard to keep SiS support
going wherever possible, and it *might* be premature to remove the DRM
support for XFree86 4.2 if it still works for that release.
I recommend leaving the SiS support in the kernel, for now. Also, the
sis_ds.c patch appears to be reversed.
> dr{i,m}stat.c added,
I believe these are very old turnon programs that were used primarily
for DRM development before we had 3D drivers to exercise the DRM. Since
there aren't really actual drivers, and they not useful for diagnosing
current drivers, we should *not* submit them to the kernel. Perhaps we
should remove them from the current trunk (i.e. to keep them in the
Attic).
> ffb_context.c removed.
It looks as if you removed the entire ffb driver. I recommend leaving
this driver alone. It is being maintained by David Miller and he tends
to submit directly to the Linux kernel, bypassing our repository.
You could merge his driver back into our repository if you are picking
up other kernel development changes, but it's not really necessary.
> The patch is avaliable http://The Low Bandwidth Server
> /~cheako/linux-drm-4.2.0-kernel-2.4.18-patch.gz
>
> E-Mail me for a copy, or just grab it if I all ready gave you the address. (I
> just don't want 400 ppl dloading it)
>
> It is only 40k (compressed) so I could post it to the list.
>
> I do wonder if there are any known bugs that I should fix. There are major
> changes in the CVS. If there is another snapshoot I should use drop me a line.
CVS contains the *development* code as we progress towards XFree86 4.3.
We should focus on releasing stable, tested code to the Linux kernel
group from the XFree86 4.2 release.
I would encourage you to be cautious about bug *fixing* on this stable
release. Even simple fixes can break other things that you may not
notice, and it will be difficult to reproduce the amount of exposure the
*stable* code has already received. However, you can apply bug fixes
liberally to the trunk of our DRI CVS repository.
Finally, it looks like it would also be a good idea to review and
possibly move the kernel development changes back into our repository.
Specifically, I'm talking about changes to the schedule wait queses as
were done to drm_fops.h; changes to the page allocation in i810_dma.c;
and any other *new* changes from the kernel development branch. I
realize the merge from the kernel repository back to ours is more than
we originally talked about. However, it would help keep things
synchronized as we move forward. Understanding some of these changes
isn't as *mechanical*; and we need to make sure any of the changes we
move back to our repository still compile and work on older 2.4 kernels.
Regards,
Jens
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Jens Owen wrote: > > Mike Mestnik wrote: > > > > sis renamed to i830 (or one was removed and the other added), I don't know about 830, but SiS has been added. These are not the same... > I realize the SiS driver is lagging behind in the current development > branch and will probably end up with 3D support disabled in XFree86 4.3 > unless SiS can make documentation or engineering bandwidth available. Push them as hard as you can! (I don't hope for much from them, they don't seem to be interested in Linux at all. My history in "pressing" information out of them doesn't look promising. Either they do it themselves, or nobody does it. They did not agree to give me any docs, even after I had offered to sign a NDA.) > However, Thomas Winischhofer has been working hard to keep SiS support > going wherever possible, and it *might* be premature to remove the DRM > support for XFree86 4.2 if it still works for that release. SiS DRI in 4.2 works perfect on the 300 series (630, 540, 730, 300). These devices are very common in laptops in Europe. Dropping DRI for these devices would be a huge step backwards. So far, nobody could explain to me what direction the current development is going which makes it necessary to update the SiS driver in a way that requires additional docs. The 3D routines are all there, changing the API is primitive... I am far from being an expert on this matter, but an answer to this question would be interesting. > I recommend leaving the SiS support in the kernel, for now. Also, the > sis_ds.c patch appears to be reversed. What did that patch do? (In short words) Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> > Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > *** FIX ME ***
> > *** removing agpgart dependency on radeon ***
> > was the only big change I made.
>
> Was this because the PCI GART functionality was added to the Radeon
> driver?
>
> > Other changes made are numerous updates,
> > 3dlabs GMX 2000 is working now *I hope*,
>
> I didn't see any patches to the gamma* files, what changed for gamma?
>
In file Config.in:
I took the $CONFIG_AGP away from radeon because of a change in the Make.linux
file (Not included) it was that way and not like the others that had the dep.
I don't know if PCIGART should be released.
as for gamma was removed, now it is not. I'm guessing were leaving it in until
we don't want to.
The patch compiles fine, however I tweaked mga to see if he would compile with
ought AGPGART and I got no errors /w a kernel image.
> > sis renamed to i830 (or one was removed and the other added),
>
> I realize the SiS driver is lagging behind in the current development
> branch and will probably end up with 3D support disabled in XFree86 4.3
> unless SiS can make documentation or engineering bandwidth available.
> However, Thomas Winischhofer has been working hard to keep SiS support
> going wherever possible, and it *might* be premature to remove the DRM
> support for XFree86 4.2 if it still works for that release.
>
> I recommend leaving the SiS support in the kernel, for now. Also, the
> sis_ds.c patch appears to be reversed.
>
I double checked, that is that way it is in Alans home dir.
-#include
+#include /* <-- use this one. */
> > dr{i,m}stat.c added,
>
> I believe these are very old turnon programs that were used primarily
> for DRM development before we had 3D drivers to exercise the DRM. Since
> there aren't really actual drivers, and they not useful for diagnosing
> current drivers, we should *not* submit them to the kernel. Perhaps we
> should remove them from the current trunk (i.e. to keep them in the
> Attic).
>
> > ffb_context.c removed.
>
> It looks as if you removed the entire ffb driver. I recommend leaving
> this driver alone. It is being maintained by David Miller and he tends
> to submit directly to the Linux kernel, bypassing our repository.
>
> You could merge his driver back into our repository if you are picking
> up other kernel development changes, but it's not really necessary.
>
OK will do.
> > I do wonder if there are any known bugs that I should fix. There are major
> > changes in the CVS. If there is another snapshoot I should use drop me a
> line.
>
> CVS contains the *development* code as we progress towards XFree86 4.3.
> We should focus on releasing stable, tested code to the Linux kernel
> group from the XFree86 4.2 release.
>
> I would encourage you to be cautious about bug *fixing* on this stable
> release. Even simple fixes can break other things that you may not
> notice, and it will be difficult to reproduce the amount of exposure the
> *stable* code has already received. However, you can apply bug fixes
> liberally to the trunk of our DRI CVS repository.
No problem.
>
> Finally, it looks like it would also be a good idea to review and
> possibly move the kernel development changes back into our repository.
> Specifically, I'm talking about changes to the schedule wait queses as
> were done to drm_fops.h; changes to the page allocation in i810_dma.c;
> and any other *new* changes from the kernel development branch. I
> realize the merge from the kernel repository back to ours is more than
> we originally talked about. However, it would help keep things
> synchronized as we move forward. Understanding some of these changes
> isn't as *mechanical*; and we need to make sure any of the changes we
> move back to our repository still compile and work on older 2.4 kernels.
I'll keep that in mind. Who knows what the future would bring.
>
> Regards,
> Jens
>
> -- /\
> Jens Owen/ \/\ _
> [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Thu, 25 Apr 2002, José Fonseca wrote: > >> Before attempt to do the above get debug info from the DRM, doing from > >> a X console as root: > >> After the computer has crashed send that kmsg. > > > > Attached aswell... > > There is no kernel oops there. Don't know if the last call there could > have problems or not. Jose, I just tried removing agpgart before starting X, and I'm getting a kernel NULL pointer dereference. I think it's because we are using dev_priv->buffers->handle to read the vertex buffers -- for PCI, there's no DRM_FIND_MAP for dev_priv->buffers and no DRM_IOREMAP for dev_priv->buffers and therefore no handle. Is there another way to access the buffer for PCI (I know you were trying to use buf->address before), or do we need to initialize the handle another way for PCI? BTW, I don't know if this is related to Peter's crash in the dispatch_clear, but it will come up once that's fixed. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Quick question about FreeBSD
Can anyone fill me in really quickly about the status of the DRI under FreeBSD? I know that some cards work (Voodoo3 and G400, iirc), but is the latest code on the trunk usable under FreeBSD? Do you still need to pull the code from the BSD specific branch? In short, is it possible to get DRI on a Radeon7500 working under FreeBSD? :-) Adam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Thomas, I'll let Mike respond to most of your questions, since he's creating the patch. Thomas Winischhofer wrote: > So far, nobody could explain to me what direction the current > development is going which makes it necessary to update the SiS driver > in a way that requires additional docs. The 3D routines are all there, > changing the API is primitive... I am far from being an expert on this > matter, but an answer to this question would be interesting. If you think you can get the SiS driver ported to Mesa 4.0 without docs, then go for it. I have to say, it's been my experience that anytime the sequencing of the graphics state being written to the hardware changes, you are going to need to have a good understanding for how the hardware works in order to debug any problems. That's why there is need for hardware documentation, IMO. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Jens Owen wrote: > > So far, nobody could explain to me what direction the current > > development is going which makes it necessary to update the SiS driver > > in a way that requires additional docs. The 3D routines are all there, > > changing the API is primitive... I am far from being an expert on this > > matter, but an answer to this question would be interesting. > > If you think you can get the SiS driver ported to Mesa 4.0 without docs, > then go for it. Well... as said, I am not an expert. It just sounds a little weird to reduce the amount of working DRI choices (=number of drivers) in favor of a new API > I have to say, it's been my experience that anytime the sequencing of > the graphics state being written to the hardware changes, you are going > to need to have a good understanding for how the hardware works in order > to debug any problems. That's why there is need for hardware > documentation, IMO. Do you think it is possible to create some kind of compatibility layer for 3.4 drivers? Are all the other DRI drivers up-to-date for MESA 4? Dropping the driver from 4.3 will keep a lot of people from using it As soon as I have time, I will take a look. From the last time I read the code, I remember it was quite well documented (or spoke for itself). Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Thomas Winischhofer wrote: > > Jens Owen wrote: > > > So far, nobody could explain to me what direction the current > > > development is going which makes it necessary to update the SiS driver > > > in a way that requires additional docs. The 3D routines are all there, > > > changing the API is primitive... I am far from being an expert on this > > > matter, but an answer to this question would be interesting. > > > > If you think you can get the SiS driver ported to Mesa 4.0 without docs, > > then go for it. > > Well... as said, I am not an expert. It just sounds a little weird to > reduce the amount of working DRI choices (=number of drivers) in favor > of a new API As opposed to sacrificing progress on the supported chipsets for the sake of a poorly supported one? The infrastructure has to move ahead, the drivers that people or companies care about will come too. Please note that all of the drivers which were working in the dri cvs at the time we did mesa 3.5 were ported across as part of that effort. The sis driver was totally broken and unsupported at that time. You can keep the 4.0 driver quite close to the 3.4 driver if you want, which might make your task easier. > > I have to say, it's been my experience that anytime the sequencing of > > the graphics state being written to the hardware changes, you are going > > to need to have a good understanding for how the hardware works in order > > to debug any problems. That's why there is need for hardware > > documentation, IMO. > > Do you think it is possible to create some kind of compatibility layer > for 3.4 drivers? It should be fairly easy to examine the differences in interfaces and make only the minimal set of changes. There isn't *that* huge of a difference. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
Keith Whitwell wrote: > > Thomas Winischhofer wrote: > > > > Jens Owen wrote: > > > > So far, nobody could explain to me what direction the current > > > > development is going which makes it necessary to update the SiS driver > > > > in a way that requires additional docs. The 3D routines are all there, > > > > changing the API is primitive... I am far from being an expert on this > > > > matter, but an answer to this question would be interesting. > > > > > > If you think you can get the SiS driver ported to Mesa 4.0 without docs, > > > then go for it. > > > > Well... as said, I am not an expert. It just sounds a little weird to > > reduce the amount of working DRI choices (=number of drivers) in favor > > of a new API > > As opposed to sacrificing progress on the supported chipsets for the sake > of a poorly supported one? Well, my point was just finding a middle way (like my question for a compatibility layer was meant to point out). But you're of course right. > You can keep the 4.0 driver quite close to the 3.4 driver if you want, > which might make your task easier. This is assumingly the only way to do this without additional specs. > > Do you think it is possible to create some kind of compatibility layer > > for 3.4 drivers? > > It should be fairly easy to examine the differences in interfaces and make > only the minimal set of changes. There isn't *that* huge of a difference. I will take a look. Is there a document on these differences somewhere? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
Perhaps this will solve some questions about what happens when the system craches when i run glxgears. After close inspection of the screen i get aftewards i have been able to make out the following by trying to combine the symbols in the "two" windows. But don´t trust the numbers or any details for that matter since it is extremely hard to read the small letters in the console or whatever it is. The numbers might be very wrong since it is much harder (impossible?) for me to connect them in the same way i can with the letters that build words, but perhaps they can tell you something. Vector 800 at pc - d58fb02c , lr -d58fb64 mxr - 9032, xp -4200 current - c99fc000, pid - 1077, comm -glxgears mon> When i type "?" the following menu rolls up: d dump bytes didump instructions dfdump float values dddump double values eprint exception information hdump hash table mmmove a block of memory ms set a block of memory mdcompare two blocks of memory Mprint system.map rprint registers Sprint special registers tprint backtrace lalookup adress in system.map lslookup symbol in system.map xexit monitor I tried the backtrace option but it only produced a bunch of numbers and letters, and since i am not exactly sure if i am able to read them right i don´t think they are useful for anyone, but if you want me to give it a try please let me know. Peter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon Card Features DRI Checklist.
Howzit? Here is my "alpha" list of features I would apreciate feedback on what should be on the feature checklist, the grouping and most importantly the *status* of these features. (I deliberately included everything bar the kitchen sink that I can find so that I dont have to add them in future. Which means that some of it is marketing blurb.) This is about as simple as I can make it. Simply put Yes / No, HW / SW, or any other apropriate comment next to the feature. Feel free to point me to any existing list(s) indicating the level of suport that these features currently enjoy. ATI R100 (Radeon) = Anti-aliasing = Full Screen Line & Edge Double Buffering --- Filtering = Anisotrophic texture --- Bilinear --- Trilinear -- KTX buffer region extension Key Frame Interpolation Gamma Control -- Guard Band Clipping Mapping === Bump --- Cubic Envionment --- Dot Product 3 -- Dual-Parabloid - Emboss - Mip Perspectively Correct Texture -- Page Flipping -- Single-Pass Multi-Texture -- System Memory Blits Superscalar Rendering -- Specular Highlights Table Fog -- TCL Back Face Culling -- TCL Hardware --- Twin Cache Architecture Texture Units per pipeline (3) - Triangle Setup Engine -- True Colour Rendering -- Texture === Cache -- Compositing (De)Compression Vertical Sync -- Vertex Skinning Volume Textures W Buffer --- W Fog -- Z Plane === Z Fog -- Z Mask - Fast Z Clear --- HierachicalZ --- HyperZ - Z-buffer: 16, 24, 32 bits -- 8 bit Stencil -- Effects? Fog Effects Texture Lighting --- Video Textures - Reflections Shadows Spotlights - LOD Biasing Texture Morphing --- Video Features == Adaptive De-interlacing - Motion compensation - IDCT (sp?) -- Driver Optimisations 3DNow! - SSE SSE2 --- ciao Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Tired Of Your High Mortgage Rate - REFINANCE TODAY...
Warning Unable to process data: multipart/mixed;boundary="=_NextPart_000_00A2_56E41D5C.D5662C28"
[Dri-devel] Mach64-0-0-4-branch currently unusable
Hi, I cvs updated mach64-0-0-4-branch last night and recompiled (previous update was on sunday). Right after starting glxgears the screen switched off (like with xset dpms force off) and the machine hung. The sysrq keys didn't work. Maybe Peter Anderson's problems are not PowerPC specific? Peter, which branch are you trying? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
