From: SourceForge.net <no...@so...> - 2004-02-09 03:55:27
|
Bugs item #893194, was opened at 2004-02-08 22:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100387&aid=893194&group_id=387 Category: ATI OpenGL Group: X Server Hang/Core Dump Status: Open Priority: 5 Submitted By: Hod McWuff (hod) Assigned to: Nobody/Anonymous (nobody) Summary: Radeon locks up with complex GL apps Initial Comment: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. I can SSH into the machine, but nothing is in any of the logs, just the application and X server both have to be sigkilled. Usually after the X server dies, the machine locks up altogether a few seconds later. I have no idea how to track this one down. Suggestions, anyone? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100387&aid=893194&group_id=387 |
From: Michel <mi...@da...> - 2004-02-10 01:55:14
|
[ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > I just ported the latest CVS drm-kernel code into the > 2.6.2 vanilla kernel. Do you have a patch for us to look at? Does the same problem occur if you just build the DRM from DRI CVS? > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others > lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Email A. <ar...@wu...> - 2004-02-10 07:45:21
|
On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > [ Following up to the dri-devel mailing list, we aren't really using the > sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > >=20 > > I just ported the latest CVS drm-kernel code into the > > 2.6.2 vanilla kernel.=20 >=20 > Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. >=20 >=20 > Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. >=20 > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others= =20 > > lock the X server up hard, such as tuxracer and BillardGL. >=20 > Are you using the 3D driver built from DRI and Mesa CVS, or an older > version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. >=20 |
From: Michel <mi...@da...> - 2004-02-10 15:17:58
|
On Tue, 2004-02-10 at 08:45, Email Archive wrote: > On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: > > [ Following up to the dri-devel mailing list, we aren't really using the > > sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > > > > I just ported the latest CVS drm-kernel code into the > > > 2.6.2 vanilla kernel. > > > > Do you have a patch for us to look at? > > Yes, I think I posted it to the SourceForge bug tracker. It's down right > now, or I'd be including a bug ID #. You mean the one in the subject? :) I've looked at the patch briefly. First of all, I find unified diffs much easier to read than context diffs. Then, I don't understand what exactly the patch was made against. Can hardly be against the 2.6.2 kernel, and at least the AGP related changes have been in DRI CVS for a while... > > Does the same problem occur if you just build the DRM from DRI CVS? > > It won't compile. Aside from a small number of API changes, the > Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. > > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others > > > lock the X server up hard, such as tuxracer and BillardGL. > > > > Are you using the 3D driver built from DRI and Mesa CVS, or an older > > version? > > I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos > package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-02-10 16:34:39
|
Michel D=C3=A4nzer wrote: > Works perfectly here... Do you have current DRI CVS from > freedesktop.org? If so, please post the errors. Speaking of that, I've seen some users get dri cvs from sourceforge.net=20 accidentally. Couldn't someone commit a "fix" so when you try to build=20 it you just get some error (preferably written in ALL_CAPS ;)) like=20 "it's outdated, use cvs from freedesktop instead". |
From: Hod M. <ho...@wu...> - 2004-02-10 17:14:10
|
OK, I managed to compile just the kernel portion from what I hope is the new CVS tree (:pserver:ano...@dr...:/cvs/dri) I get this in the X server output, which is also about what I expect to see from the ones in the kernel: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.10.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. On Tue, 2004-02-10 at 10:17, Michel D=E4nzer wrote: > On Tue, 2004-02-10 at 08:45, Email Archive wrote: > > On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > > > [ Following up to the dri-devel mailing list, we aren't really using = the > > > sf.net bug tracker anymore but rather the kernel and XFree86 bugzilla= s ] > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > >=20 > > > > I just ported the latest CVS drm-kernel code into the > > > > 2.6.2 vanilla kernel.=20 > > >=20 > > > Do you have a patch for us to look at? > >=20 > > Yes, I think I posted it to the SourceForge bug tracker. It's down righ= t > > now, or I'd be including a bug ID #. >=20 > You mean the one in the subject? :) >=20 > I've looked at the patch briefly. First of all, I find unified diffs > much easier to read than context diffs. Then, I don't understand what > exactly the patch was made against. Can hardly be against the 2.6.2 > kernel, and at least the AGP related changes have been in DRI CVS for a > while... >=20 >=20 > > > Does the same problem occur if you just build the DRM from DRI CVS? > >=20 > > It won't compile. Aside from a small number of API changes, the > > Makefile.linux is *severely* broken about include directories under 2.6= . >=20 > Works perfectly here... Do you have current DRI CVS from > freedesktop.org? If so, please post the errors. >=20 >=20 > > > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some ot= hers=20 > > > > lock the X server up hard, such as tuxracer and BillardGL. > > >=20 > > > Are you using the 3D driver built from DRI and Mesa CVS, or an older > > > version? > >=20 > > I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos > > package and a manual install from the latest ati.2 cvs sources. >=20 > No lockups with tuxracer or BillardGL running the DRM from current DRI > CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want > to try a newer 3D driver. >=20 |
From: Hod M. <ho...@wu...> - 2004-02-10 22:17:12
|
OK, onward and upward... I'm starting to investigate what it would take to merge the GATOS functionality into the current DRI. I'm sure the XFree side is going to be a pain in the ass, but I'm starting with the kernel modules. The first discrepancy I need cleared up is about driver support. The current DRI source seems to have drivers for: i810,i830,mga,r128,radeon,sis,tdfx Some are split between multiple files, some are in a single file. If there's a document somewhere saying what files have what, then it'd help to see it. The kernel copy also has a 'ffb' driver, which I'm assuming until someone tells me otherwise is an out of date hack. The Gatos copy has the same drivers as the DRI source, but all split amongst many files. I have a feeling the gamma and SIS drivers in this copy are screwed totally anyway - in fact probably only the radeon and r128 drivers from Gatos are relevant anyway, plus any changes in the drm_* files. So, to summarize, I need to know *roughly* what's changed since the Gatos folks forked, in terms of what-moved-where and an idea of any structural changes. I can read the different sources and figure out the code changes myself, but I need to know what I'm looking for. It would seem the best approach is to merge their changes - conceptually, one by one - into the current DRI sources. |
From: Jon S. <jon...@ya...> - 2004-02-10 22:44:19
|
Did GATOS make changes to the DRM drivers? Is it using I2C to get to the TV tuner on ATI cards? What else get changed in the Xfree drivers? --- Hod McWuff <ho...@wu...> wrote: > > OK, onward and upward... I'm starting to investigate what it would take > to merge the GATOS functionality into the current DRI. I'm sure the > XFree side is going to be a pain in the ass, but I'm starting with the > kernel modules. > > The first discrepancy I need cleared up is about driver support. The > current DRI source seems to have drivers for: > i810,i830,mga,r128,radeon,sis,tdfx > > Some are split between multiple files, some are in a single file. > If there's a document somewhere saying what files have what, then it'd > help to see it. > > The kernel copy also has a 'ffb' driver, which I'm assuming until > someone tells me otherwise is an out of date hack. > > The Gatos copy has the same drivers as the DRI source, but all split > amongst many files. I have a feeling the gamma and SIS drivers in this > copy are screwed totally anyway - in fact probably only the radeon and > r128 drivers from Gatos are relevant anyway, plus any changes in the > drm_* files. > > So, to summarize, I need to know *roughly* what's changed since the > Gatos folks forked, in terms of what-moved-where and an idea of any > structural changes. I can read the different sources and figure out the > code changes myself, but I need to know what I'm looking for. > > It would seem the best approach is to merge their changes - > conceptually, one by one - into the current DRI sources. > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html |
From: Hod M. <ho...@wu...> - 2004-02-11 04:10:49
|
On Tue, 2004-02-10 at 17:44, Jon Smirl wrote: > Did GATOS make changes to the DRM drivers? > Yes, for a while I was tracking its CVS and rebuilding often. I had 3D and video working together just fine under 2.4. Gentoo Linux even went as far as making a drm-kernel ebuild that patched for gatos. :pserver:ano...@cv...:/cvsroot/gatos module drm-kernel > Is it using I2C to get to the TV tuner on ATI cards? No. I2C, so far as I know, isn't involved at all. > > What else get changed in the Xfree drivers? They have an ati.2 module (same CVSROOT) that you xmkmf against a compiled XFree tree, then make ; make install, that provides access to the tuner and v4l playback (MPEG acceleration). A separate kernel module is required for video capture. The ati.2 module replaces /usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o and adds /usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o > > --- Hod McWuff <ho...@wu...> wrote: > > > > OK, onward and upward... I'm starting to investigate what it would take > > to merge the GATOS functionality into the current DRI. I'm sure the > > XFree side is going to be a pain in the ass, but I'm starting with the > > kernel modules. > > > > The first discrepancy I need cleared up is about driver support. The > > current DRI source seems to have drivers for: > > i810,i830,mga,r128,radeon,sis,tdfx > > > > Some are split between multiple files, some are in a single file. > > If there's a document somewhere saying what files have what, then it'd > > help to see it. > > > > The kernel copy also has a 'ffb' driver, which I'm assuming until > > someone tells me otherwise is an out of date hack. > > > > The Gatos copy has the same drivers as the DRI source, but all split > > amongst many files. I have a feeling the gamma and SIS drivers in this > > copy are screwed totally anyway - in fact probably only the radeon and > > r128 drivers from Gatos are relevant anyway, plus any changes in the > > drm_* files. > > > > So, to summarize, I need to know *roughly* what's changed since the > > Gatos folks forked, in terms of what-moved-where and an idea of any > > structural changes. I can read the different sources and figure out the > > code changes myself, but I need to know what I'm looking for. > > > > It would seem the best approach is to merge their changes - > > conceptually, one by one - into the current DRI sources. > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > -- > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > ===== > Jon Smirl > jon...@ya... > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html |
From: Jon S. <jon...@ya...> - 2004-02-11 04:34:00
|
There are two mainpieces to this that I know of, maybe more. 1) The tuner 2) video overlays xserver may render video overlays pointless. Once we get hardware compositing going you should be able to rebuild the entire screen on every TV frame. You may want to review what is happening with xserver before spending a lot of time on overlays. How does this play with the current state of XV? Don't the All-in-wonder boards use the bt8x8 tuner chips? Any idea why the BT driver in drivers/media/video won't work for the ATI cards? I have the docs for the AIW but they're in RTF, I'm downloading OpenOffice right now. It might be easier to just fix the existing BT driver to work on the ATI cards. I see also that there are drivers for the remote control and TV output. TV out probably has to be intergrated into the X driver. Remote control should work standalone. --- Hod McWuff <ho...@wu...> wrote: > > On Tue, 2004-02-10 at 17:44, Jon Smirl wrote: > > Did GATOS make changes to the DRM drivers? > > > > Yes, for a while I was tracking its CVS and rebuilding often. I had > 3D and video working together just fine under 2.4. Gentoo Linux even > went as far as making a drm-kernel ebuild that patched for gatos. > > :pserver:ano...@cv...:/cvsroot/gatos > > module drm-kernel > > > Is it using I2C to get to the TV tuner on ATI cards? > > No. I2C, so far as I know, isn't involved at all. > > > > > What else get changed in the Xfree drivers? > > They have an ati.2 module (same CVSROOT) that you xmkmf against a > compiled XFree tree, then make ; make install, that provides access to > the tuner and v4l playback (MPEG acceleration). A separate kernel module > is required for video capture. > > The ati.2 module replaces > /usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o > > and adds > /usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o > > > > > > > --- Hod McWuff <ho...@wu...> wrote: > > > > > > OK, onward and upward... I'm starting to investigate what it would take > > > to merge the GATOS functionality into the current DRI. I'm sure the > > > XFree side is going to be a pain in the ass, but I'm starting with the > > > kernel modules. > > > > > > The first discrepancy I need cleared up is about driver support. The > > > current DRI source seems to have drivers for: > > > i810,i830,mga,r128,radeon,sis,tdfx > > > > > > Some are split between multiple files, some are in a single file. > > > If there's a document somewhere saying what files have what, then it'd > > > help to see it. > > > > > > The kernel copy also has a 'ffb' driver, which I'm assuming until > > > someone tells me otherwise is an out of date hack. > > > > > > The Gatos copy has the same drivers as the DRI source, but all split > > > amongst many files. I have a feeling the gamma and SIS drivers in this > > > copy are screwed totally anyway - in fact probably only the radeon and > > > r128 drivers from Gatos are relevant anyway, plus any changes in the > > > drm_* files. > > > > > > So, to summarize, I need to know *roughly* what's changed since the > > > Gatos folks forked, in terms of what-moved-where and an idea of any > > > structural changes. I can read the different sources and figure out the > > > code changes myself, but I need to know what I'm looking for. > > > > > > It would seem the best approach is to merge their changes - > > > conceptually, one by one - into the current DRI sources. > > > > > > > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > -- > > > _______________________________________________ > > > Dri-devel mailing list > > > Dri...@li... > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > ===== > > Jon Smirl > > jon...@ya... > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Finance: Get your refund fast by filing online. > > http://taxes.yahoo.com/filing.html ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html |
From: Alex D. <ag...@ya...> - 2004-02-11 14:50:35
|
--- Jon Smirl <jon...@ya...> wrote: > There are two mainpieces to this that I know of, maybe more. > > 1) The tuner > 2) video overlays > > xserver may render video overlays pointless. Once we get hardware > compositing > going you should be able to rebuild the entire screen on every TV > frame. You may > want to review what is happening with xserver before spending a lot > of time on > overlays. How does this play with the current state of XV? There are some nice features in the Gatos Xv support (RGB overlays, de-interlacing, capture/tuner support) that would be useful in the general xfree86 driver. The radeon overlay also has alpha blending capabilites. I wrote a patch for radeon that GATOS accepted. I was waiting for 4.4 to be released to add the patch to xfree86. It will really be useful once visuals with an alpha value are supported in the server. You can adjust the alpha value of the overlay and the graphics layer. you can do some cool hacks with it now. patch is here: http://www.botchco.com/alex/radeon/Xv/xv_alpha/ > > Don't the All-in-wonder boards use the bt8x8 tuner chips? Any idea > why the BT > driver in drivers/media/video won't work for the ATI cards? I have > the docs for > the AIW but they're in RTF, I'm downloading OpenOffice right now. It > might be > easier to just fix the existing BT driver to work on the ATI cards. Most use the ati theater chip for the capture and decoding, and then a regular tuner for tuning in RF signals. i2c IS used. see gatos radeon_video.c. > > I see also that there are drivers for the remote control and TV > output. TV out > probably has to be intergrated into the X driver. Remote control > should work > standalone. Probably input should move to the linux input layer. Alex > > > > > --- Hod McWuff <ho...@wu...> wrote: > > > > On Tue, 2004-02-10 at 17:44, Jon Smirl wrote: > > > Did GATOS make changes to the DRM drivers? > > > > > > > Yes, for a while I was tracking its CVS and rebuilding often. I had > > 3D and video working together just fine under 2.4. Gentoo Linux > even > > went as far as making a drm-kernel ebuild that patched for gatos. > > > > :pserver:ano...@cv...:/cvsroot/gatos > > > > module drm-kernel > > > > > Is it using I2C to get to the TV tuner on ATI cards? > > > > No. I2C, so far as I know, isn't involved at all. > > > > > > > > What else get changed in the Xfree drivers? > > > > They have an ati.2 module (same CVSROOT) that you xmkmf against a > > compiled XFree tree, then make ; make install, that provides access > to > > the tuner and v4l playback (MPEG acceleration). A separate kernel > module > > is required for video capture. > > > > The ati.2 module replaces > > /usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o > > > > and adds > > > /usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o > > > > > > > > > > > > --- Hod McWuff <ho...@wu...> wrote: > > > > > > > > OK, onward and upward... I'm starting to investigate what it > would take > > > > to merge the GATOS functionality into the current DRI. I'm sure > the > > > > XFree side is going to be a pain in the ass, but I'm starting > with the > > > > kernel modules. > > > > > > > > The first discrepancy I need cleared up is about driver > support. The > > > > current DRI source seems to have drivers for: > > > > i810,i830,mga,r128,radeon,sis,tdfx > > > > > > > > Some are split between multiple files, some are in a single > file. > > > > If there's a document somewhere saying what files have what, > then it'd > > > > help to see it. > > > > > > > > The kernel copy also has a 'ffb' driver, which I'm assuming > until > > > > someone tells me otherwise is an out of date hack. > > > > > > > > The Gatos copy has the same drivers as the DRI source, but all > split > > > > amongst many files. I have a feeling the gamma and SIS drivers > in this > > > > copy are screwed totally anyway - in fact probably only the > radeon and > > > > r128 drivers from Gatos are relevant anyway, plus any changes > in the > > > > drm_* files. > > > > > > > > So, to summarize, I need to know *roughly* what's changed since > the > > > > Gatos folks forked, in terms of what-moved-where and an idea of > any > > > > structural changes. I can read the different sources and figure > out the > > > > code changes myself, but I need to know what I'm looking for. > > > > > > > > It would seem the best approach is to merge their changes - > > > > conceptually, one by one - into the current DRI sources. > > > > > > > > __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html |
From: Mike A. H. <mh...@ww...> - 2004-02-11 06:41:33
|
On Tue, 10 Feb 2004, Hod McWuff wrote: >So, to summarize, I need to know *roughly* what's changed since the >Gatos folks forked, in terms of what-moved-where and an idea of any >structural changes. I can read the different sources and figure out the >code changes myself, but I need to know what I'm looking for. Presumeably the best way to find out what the GATOS developer(s) changed, would be to ask them. ;o) >It would seem the best approach is to merge their changes - >conceptually, one by one - into the current DRI sources. That sounds sane, however some of it may require a bit of discussion to iron out issues. For example, anything that might break ABI would be a no-go. If I recall correctly, in the past there were ABI changing differences, however I have no idea if that is the case nowadays. That said, it would indeed be nice to have GATOS efforts work out of the box with one single unified driver set. -- Mike A. Harris |
From: Hod M. <ho...@wu...> - 2004-02-11 07:20:45
|
On Wed, 2004-02-11 at 01:41, Mike A. Harris wrote: > On Tue, 10 Feb 2004, Hod McWuff wrote: > > >So, to summarize, I need to know *roughly* what's changed since the > >Gatos folks forked, in terms of what-moved-where and an idea of any > >structural changes. I can read the different sources and figure out the > >code changes myself, but I need to know what I'm looking for. > > Presumeably the best way to find out what the GATOS developer(s) > changed, would be to ask them. ;o) That's not what I meant - I mean, what big things have happened in the *DRI* tree since the Gatos fork. I need an idea of that to be able to sort gatos-related changes from simple base-version differences. > > >It would seem the best approach is to merge their changes - > >conceptually, one by one - into the current DRI sources. > > That sounds sane, however some of it may require a bit of > discussion to iron out issues. For example, anything that might > break ABI would be a no-go. If I recall correctly, in the past > there were ABI changing differences, however I have no idea if > that is the case nowadays. At this stage I'm mainly concerned with the kernel module. I've gotten some mixed results so far - including a blind copy of the radeon* files from the gatos version into a copy of the latest DRI sources hand-merged into the 2.6.2 build tree. That one actually runs tuxracer well, but locks the console (not the machine) after about 2 seconds. So, right now my focus is to isolate what the Gatos folks did to get the kernel module to work with their XFree driver. It did under 2.4. The challenge is, the development from ancient->recent, ancient->2.6-compatible, and ancient->gatos-compatible all happened separately, and may have been partially (haphazardly?) merged. > > That said, it would indeed be nice to have GATOS efforts work out > of the box with one single unified driver set. > Darn right. At the moment I'll settle for getting a 2.6.2 kernel module that handles ati.2 drivers on top of XFree 4.3.0... of course the next phase would be to merge the changes in the XFree driver. I suspect that's where many of the incompatibilities will be. I haven't found any changed constants between any of the forks, only changes to #ifdef/#if, minor internal data type and semantic changes, and large blocks of code moving around and morphing somewhat. It's those large blocks I'm trying to understand now. By the way, there are some apparently trivial changes present only in the 2.6.2 copy - apparently someone has added ia-64/x86-64 to a few arch sensitive defines. One of my next few posts will include a patch against the DRI copy of the relevant files. It should be pretty short. I'm trying to take this a step at a time, and the one after that is to merge the DRI kernel driver changes back into my 2.6.2 tree for smoother test building. If y'all like I'll send along a copy of that patch too. Once I get there, and complete the analysis of the gatos changes, I'll write a third patch to merge *that* into 2.6.2 and test the hell out of it. Given the previous merging, that patch should apply to the DRI tree after changing a few of the pathnames in the diff. Once again, the A/V features depend solely on the XFree-level Gatos changes. They work even with no DRM loaded at all. If I can get partial or intermittent 3D to work, via brute hacking at that, then it stands to reason further tweaking of the kernel module will get me to solid 3D performance. |
From: Michel <mi...@da...> - 2004-02-11 22:29:05
|
On Wed, 2004-02-11 at 08:20, Hod McWuff wrote: > > That's not what I meant - I mean, what big things have happened in the > *DRI* tree since the Gatos fork. I need an idea of that to be able to > sort gatos-related changes from simple base-version differences. Once you have found the common ancestor of the DRI and GATOS code, a three way merge tool should be helpful. > So, right now my focus is to isolate what the Gatos folks did to get the > kernel module to work with their XFree driver. They changed the locations of the framebuffer and GART apertures to the same places as in their 2D driver, don't know if they changed anything else. The DRM and 3D driver in current DRI CVS should theoretically be able to work with their 2D driver. Its aperture setup may have to be changed slightly though. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Hod M. <ho...@wu...> - 2004-02-11 23:27:07
|
On Wed, 2004-02-11 at 17:28, Michel D=E4nzer wrote: > On Wed, 2004-02-11 at 08:20, Hod McWuff wrote: > >=20 > > That's not what I meant - I mean, what big things have happened in the > > *DRI* tree since the Gatos fork. I need an idea of that to be able to > > sort gatos-related changes from simple base-version differences. >=20 > Once you have found the common ancestor of the DRI and GATOS code, a > three way merge tool should be helpful. >=20 I've been poking around the Gatos CVS tree. Their last merge with XFree was roughly a year ago, and the first merge roughly a year before that. By the way, where can I find a three-way merge tool? ;) >=20 > > So, right now my focus is to isolate what the Gatos folks did to get th= e > > kernel module to work with their XFree driver. >=20 > They changed the locations of the framebuffer and GART apertures to the > same places as in their 2D driver, don't know if they changed anything > else. I've found Gatos-related changes in radeon_cp.c, radeon_drv.h, and radeon_state.c. I've reimplemented what changes I could find... there's something I'm still missing though. >=20 > The DRM and 3D driver in current DRI CVS should theoretically be able to > work with their 2D driver. Its aperture setup may have to be changed > slightly though. The one in 2.6.2 works with 2D (after faking the version number) both before and after applying the changes in current DRI CVS. It even allows the 3D app to run, but with blank window contents. After manually patching in Gatos-related changes I get the same behavior. I must be missing something important. Is dev_priv->fb_offset equivalent to the old dev_priv->fb->offset ? Attached patches:=20 drm-arch-tests.diff merges recent Linus changes into DRM CVS 2.6.2-update.patch merges current DRI CVS into the 2.6.2 tree drm-gatos.diff merges what I THINK the gatos changes are into either the patched 2.6.2 tree or (probably) into the DRI CVS tree. >=20 |
From: Michel <mi...@da...> - 2004-02-12 00:04:53
|
On Thu, 2004-02-12 at 00:26, Hod McWuff wrote: > On Wed, 2004-02-11 at 17:28, Michel Dänzer wrote: > > By the way, where can I find a three-way merge tool? ;) I like meld, for example. > I've found Gatos-related changes in radeon_cp.c, radeon_drv.h, and > radeon_state.c. I've reimplemented what changes I could find... They're mostly superfluous AFAICT. Again, the DRM in current DRI CVS should basically work with the GATOS 2D driver, that one just needs to set up things similarly to how the 2D driver in DRI CVS does. > > The DRM and 3D driver in current DRI CVS should theoretically be able to > > work with their 2D driver. Its aperture setup may have to be changed > > slightly though. > > The one in 2.6.2 works with 2D (after faking the version number) Faking the version number is obviously a bad idea. The GATOS 2D driver should work with the 1.10.0 radeon DRM with the changes described above. The GATOS 3D driver only works with the old GATOS DRM and 2D driver, but the 3D driver in current DRI CVS should work with anything, or at least fail gracefully. > 2.6.2-update.patch merges current DRI CVS into the 2.6.2 tree BTW, AFAIK the DRM in the -mm kernel tree is already fairly up to date. Some of the stuff in DRI CVS is only needed for compatibility with older kernels etc. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Dieter <Die...@ha...> - 2004-02-10 12:29:14
|
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: > On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > > [ Following up to the dri-devel mailing list, we aren't really using the > > sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] > > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > I just ported the latest CVS drm-kernel code into the > > > 2.6.2 vanilla kernel. > > > > Do you have a patch for us to look at? > > Yes, I think I posted it to the SourceForge bug tracker. It's down right > now, or I'd be including a bug ID #. > > > Does the same problem occur if you just build the DRM from DRI CVS? > > It won't compile. Aside from a small number of API changes, the > Makefile.linux is *severely* broken about include directories under 2.6. I use only 2.6.x. There is No problem with DRI CVS (DRM). But some apps hang the graphics card (hard). UT2003 Citadel after some (<=3D 3) seconds. But _very_ smooth with S3TC and Roland's hardware TCL patch. Daniel any ideas? What's different compared to the "standard demo"? I've "played" it for near= ly=20 15 minutes without a hitch. TMU3? - More triangels? (The grass)? SuSE-9.0, kernel 2.6.2-0 Greetings, Dieter |
From: Roland S. <rsc...@hi...> - 2004-02-10 13:20:25
|
Dieter N=FCtzel wrote: > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: >=20 >> On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: >>=20 >>> [ Following up to the dri-devel mailing list, we aren't really >>> using the sf.net bug tracker anymore but rather the kernel and >>> XFree86 bugzillas ] >>>=20 >>> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: >>>=20 >>>> I just ported the latest CVS drm-kernel code into the 2.6.2 >>>> vanilla kernel. >>>=20 >>> Do you have a patch for us to look at? >>=20 >> Yes, I think I posted it to the SourceForge bug tracker. It's down >> right now, or I'd be including a bug ID #. >>=20 >>=20 >>> Does the same problem occur if you just build the DRM from DRI >>> CVS? >>=20 >> It won't compile. Aside from a small number of API changes, the=20 >> Makefile.linux is *severely* broken about include directories under >> 2.6. >=20 >=20 > I use only 2.6.x. There is No problem with DRI CVS (DRM). >=20 > But some apps hang the graphics card (hard). >=20 > UT2003 Citadel after some (<=3D 3) seconds. But _very_ smooth with S3TC > and Roland's hardware TCL patch. That's not good. There is nothing (both in the S3TC patch as well as in=20 the changed lighting code) which could make lockups disappear. Using=20 compressed textures shouldn't change anything (except the textures are=20 smaller so less texture swapping is needed which might mean there are=20 more free dma buffers available). The lighting changes did avoid some=20 TCL fallback with materials between begin/end (and it looks like the=20 fallback doesn't always work correctly, though I don't think it causes=20 lockups), but in the latest patch (submitted to cvs yesterday) it's back=20 in (as removing it wasn't correct and sometimes caused obvious rendering=20 errors, it still awaits a proper fix). The patch still avoids a tcl=20 fallback when using two-sided materials, but that really shouldn't have=20 caused lockups... Meaning if the lockups have disappeared in UT2003, they are likely to=20 reappear somewhere else. That said, I just tried to reproduce the lockups, but I can't even get=20 ut2003 (demo 2206) to start here, it crashes even before the nvidia logo=20 appears (seems to segfault and then be stuck waiting for a signal,=20 killall -9 will just get rid of it fine). I can only hope it's not=20 caused by the lighting changes I've commited yesterday (though I've no=20 idea how these changes could cause that) - maybe some of the=20 experimental code I've got here causes it. Roland |
From: Dieter <Die...@ha...> - 2004-02-10 22:44:35
|
Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger: > Dieter N=FCtzel wrote: > > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: > >> On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > >>> [ Following up to the dri-devel mailing list, we aren't really > >>> using the sf.net bug tracker anymore but rather the kernel and > >>> XFree86 bugzillas ] > >>> > >>> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > >>>> I just ported the latest CVS drm-kernel code into the 2.6.2 > >>>> vanilla kernel. > >>> > >>> Do you have a patch for us to look at? > >> > >> Yes, I think I posted it to the SourceForge bug tracker. It's down > >> right now, or I'd be including a bug ID #. > >> > >>> Does the same problem occur if you just build the DRM from DRI > >>> CVS? > >> > >> It won't compile. Aside from a small number of API changes, the > >> Makefile.linux is *severely* broken about include directories under > >> 2.6. > > > > I use only 2.6.x. There is No problem with DRI CVS (DRM). > > > > But some apps hang the graphics card (hard). > > > > UT2003 Citadel after some (<=3D 3) seconds. But _very_ smooth with S3TC > > and Roland's hardware TCL patch. Some additional notes. It was your code (patch) with Mesa, GLX from last week. Not with latest Mesa and GLX code (Brian, Ian). It locks in Citadel during _first_ mouse move (immediately). I could move around not play "Bombing Run" (Egypt) for about 15 minutes. My girlfriend and I watched the GREAT textures mirrors and halls...;-) Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the=20 "behavior" is the same, but some textures (the mirrors, multi textures?) ar= e=20 broken in "Bombing Run" (Egypt). > That's not good. There is nothing (both in the S3TC patch as well as in > the changed lighting code) which could make lockups disappear. Using > compressed textures shouldn't change anything (except the textures are > smaller so less texture swapping is needed which might mean there are > more free dma buffers available). The lighting changes did avoid some > TCL fallback with materials between begin/end (and it looks like the > fallback doesn't always work correctly, though I don't think it causes > lockups), but in the latest patch (submitted to cvs yesterday) it's back > in (as removing it wasn't correct and sometimes caused obvious rendering > errors, it still awaits a proper fix). The patch still avoids a tcl > fallback when using two-sided materials, but that really shouldn't have > caused lockups... Maybe the broken textures? > Meaning if the lockups have disappeared in UT2003, they are likely to > reappear somewhere else. > That said, I just tried to reproduce the lockups, but I can't even get > ut2003 (demo 2206) to start here, it crashes even before the nvidia logo > appears (seems to segfault and then be stuck waiting for a signal, > killall -9 will just get rid of it fine). Now, it sigfault immediately like yours... /opt/Mesa> ut2003_demo fcntl: Invalid argument fcntl: Invalid argument Mesa: software DXTn compression/decompression available Backtrace: [ 1] ./Core.so [0x40a0b78a] [ 2] /lib/i686/libpthread.so.0 [0x40dfd96c] [ 3] /lib/i686/libc.so.6 [0x40bc5aa8] Signal: SIGSEGV [segmentation fault] Aborting. Speicherschutzverletzung > I can only hope it's not=20 > caused by the lighting changes I've commited yesterday (though I've no > idea how these changes could cause that) - maybe some of the > experimental code I've got here causes it. It must be something like that. =2DDieter |
From: Dieter <Die...@ha...> - 2004-02-11 23:05:42
|
Am Dienstag, 10. Februar 2004 23:48 schrieb Dieter N=FCtzel: > Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger: > > Dieter N=FCtzel wrote: > > > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: > > >> On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > > >>> [ Following up to the dri-devel mailing list, we aren't really > > >>> using the sf.net bug tracker anymore but rather the kernel and > > >>> XFree86 bugzillas ] > > >>> > > >>> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > >>>> I just ported the latest CVS drm-kernel code into the 2.6.2 > > >>>> vanilla kernel. > > >>> > > >>> Do you have a patch for us to look at? > > >> > > >> Yes, I think I posted it to the SourceForge bug tracker. It's down > > >> right now, or I'd be including a bug ID #. > > >> > > >>> Does the same problem occur if you just build the DRM from DRI > > >>> CVS? > > >> > > >> It won't compile. Aside from a small number of API changes, the > > >> Makefile.linux is *severely* broken about include directories under > > >> 2.6. > > > > > > I use only 2.6.x. There is No problem with DRI CVS (DRM). > > > > > > But some apps hang the graphics card (hard). > > > > > > UT2003 Citadel after some (<=3D 3) seconds. But _very_ smooth with S3= TC > > > and Roland's hardware TCL patch. > > Some additional notes. > > It was your code (patch) with Mesa, GLX from last week. > Not with latest Mesa and GLX code (Brian, Ian). OK, update after the api_arrayelt.c fix. > It locks in Citadel during _first_ mouse move (immediately). It happens in "Capture the Flag" -> Citadel. I can move in all other demos with cursor keys _and_ mouse, except Citadel. When I move (I haven't hit the fire button) with the cursor keys all is rig= ht,=20 too. But when I got the mouse in my hand and do the first _little_ move it hangs. > I could move around not play "Bombing Run" (Egypt) "Temple of Anubis"...;-) > for about 15 minutes.=20 > My girlfriend and I watched the GREAT textures mirrors and halls...;-) > > Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the > "behavior" is the same, but some textures (the mirrors, multi textures?) > are broken in "Bombing Run" (Egypt). All textures are RIGHT after the api_arrayelt.c fix. > > That's not good. There is nothing (both in the S3TC patch as well as in > > the changed lighting code) which could make lockups disappear. Using > > compressed textures shouldn't change anything (except the textures are > > smaller so less texture swapping is needed which might mean there are > > more free dma buffers available). The lighting changes did avoid some > > TCL fallback with materials between begin/end (and it looks like the > > fallback doesn't always work correctly, though I don't think it causes > > lockups), but in the latest patch (submitted to cvs yesterday) it's back > > in (as removing it wasn't correct and sometimes caused obvious rendering > > errors, it still awaits a proper fix). The patch still avoids a tcl > > fallback when using two-sided materials, but that really shouldn't have > > caused lockups... > > Maybe the broken textures? See above. > > Meaning if the lockups have disappeared in UT2003, they are likely to > > reappear somewhere else. > > That said, I just tried to reproduce the lockups, but I can't even get > > ut2003 (demo 2206) to start here, it crashes even before the nvidia logo > > appears (seems to segfault and then be stuck waiting for a signal, > > killall -9 will just get rid of it fine). > > Now, it sigfault immediately like yours... All fixed, except the hang. > > I can only hope it's not > > caused by the lighting changes I've commited yesterday (though I've no > > idea how these changes could cause that) - maybe some of the > > experimental code I've got here causes it. No ;-) Only "problem" is some slowdown in the big halls and "outside" of "Temple = of =20 Anubis". Any comments, Andreas? TMU36 missing? Any updates? Cheers, Dieter |
From: Hod M. <ho...@wu...> - 2004-02-10 16:46:56
|
On Tue, 2004-02-10 at 10:17, Michel D=E4nzer wrote: > On Tue, 2004-02-10 at 08:45, Email Archive wrote: > > On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > > > [ Following up to the dri-devel mailing list, we aren't really using = the > > > sf.net bug tracker anymore but rather the kernel and XFree86 bugzilla= s ] > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > >=20 > > > > I just ported the latest CVS drm-kernel code into the > > > > 2.6.2 vanilla kernel.=20 > > >=20 > > > Do you have a patch for us to look at? > >=20 > > Yes, I think I posted it to the SourceForge bug tracker. It's down righ= t > > now, or I'd be including a bug ID #. >=20 > You mean the one in the subject? :) Riiiight... that's what I get for staying up so late ;) >=20 > I've looked at the patch briefly. First of all, I find unified diffs > much easier to read than context diffs. Then, I don't understand what > exactly the patch was made against. Can hardly be against the 2.6.2 > kernel, and at least the AGP related changes have been in DRI CVS for a > while... >=20 It was against a checkout of drm-kernel, and then manually copy the .c and .h files into the 2.6.2 tree. >=20 > > > Does the same problem occur if you just build the DRM from DRI CVS? > >=20 > > It won't compile. Aside from a small number of API changes, the > > Makefile.linux is *severely* broken about include directories under 2.6= . >=20 > Works perfectly here... Do you have current DRI CVS from > freedesktop.org? If so, please post the errors. from freedesktop.org? not from sourceforge anymore? :pserver:ano...@cv...:/cvsroot/gatos >=20 >=20 > > > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some ot= hers=20 > > > > lock the X server up hard, such as tuxracer and BillardGL. > > >=20 > > > Are you using the 3D driver built from DRI and Mesa CVS, or an older > > > version? > >=20 > > I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos > > package and a manual install from the latest ati.2 cvs sources. >=20 > No lockups with tuxracer or BillardGL running the DRM from current DRI > CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want > to try a newer 3D driver. The one that ships with the kernel won't fly due to version number - if memory serves it did before installing ati.2, but seeing how the machine (with its AIW Radeon) serves as my living room entertainment center, having A/V capability trumped 3D.=20 ati.2 CVSROOT: :pserver:ano...@cv...:/cvsroot/gatos >=20 It's beginning to look like my entire problem might be having missed a move of the CVS source hosting. Let me see what turns up... if that is the case, I'd suggest modifying the Makefiles on the sf.net copy to cause an error message if anyone tries compiling them. While we're on the subject, what's the status of integration with the XFree 4.4 betas? Would I be better off going that way? OK, I just checked out the new xc tree... seems to be some confusion going on between it and the documentation about having the Mesa tree. Hrm? Thanks, - Hod McWuff |
From: Michel <mi...@da...> - 2004-02-10 17:24:12
|
On Tue, 2004-02-10 at 17:46, Hod McWuff wrote: > On Tue, 2004-02-10 at 10:17, Michel Dänzer wrote: > > On Tue, 2004-02-10 at 08:45, Email Archive wrote: > > > On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: > > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > > [...] I don't understand what exactly the patch was made against. [...] > > It was against a checkout of drm-kernel, [...] I was going to ask "what's drm-kernel?", but it cleared up below... > > > > Does the same problem occur if you just build the DRM from DRI CVS? > > > > > > It won't compile. Aside from a small number of API changes, the > > > Makefile.linux is *severely* broken about include directories under 2.6. > > > > Works perfectly here... Do you have current DRI CVS from > > freedesktop.org? If so, please post the errors. > > from freedesktop.org? not from sourceforge anymore? > :pserver:ano...@cv...:/cvsroot/gatos ^^^^^ ^^^^^ gatos != dri DRI CVS has moved to freedesktop.org. > > > > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others > > > > > lock the X server up hard, such as tuxracer and BillardGL. > > > > > > > > Are you using the 3D driver built from DRI and Mesa CVS, or an older > > > > version? > > > > > > I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos > > > package and a manual install from the latest ati.2 cvs sources. > > > > No lockups with tuxracer or BillardGL running the DRM from current DRI > > CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want > > to try a newer 3D driver. > > The one that ships with the kernel won't fly due to version number - if > memory serves it did before installing ati.2, but seeing how the machine > (with its AIW Radeon) serves as my living room entertainment center, > having A/V capability trumped 3D. The Radeon DRM and 3D drivers from the GATOS project are incompatible to those from the DRI project. Unfortunately, GATOS didn't reflect this incompatibility correctly in their DRM version, otherwise the wrong 3D driver would refuse to run instead of locking up the machine. Fortunately, the root cause of the incompatibility has been removed in DRI CVS, GATOS just needs to adapt to that. > It's beginning to look like my entire problem might be having missed a > move of the CVS source hosting. You simply seem to have missed that GATOS and DRI are different projects. :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Hod M. <ho...@wu...> - 2004-02-10 17:27:42
|
Now I've changed the version number in the xc/bleh kernel module. I'm not getting hard server locks anymore, but now *all* GL apps show an empty black window that never changes. Something is definitely still funky. I'm guessing this has something to do with the ati.2 module I've got installed. Is a manual code merge between the ati.2-compatible old version and the new cvs trunk required? (follow up to:) OK, I managed to compile just the kernel portion from what I hope is the new CVS tree (:pserver:ano...@dr...:/cvs/dri) I get this in the X server output, which is also about what I expect to see from the ones in the kernel: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.10.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. On Tue, 2004-02-10 at 11:46, Hod McWuff wrote: > On Tue, 2004-02-10 at 10:17, Michel D=E4nzer wrote: > > On Tue, 2004-02-10 at 08:45, Email Archive wrote: > > > On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote: > > > > [ Following up to the dri-devel mailing list, we aren't really usin= g the > > > > sf.net bug tracker anymore but rather the kernel and XFree86 bugzil= las ] > > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > > > >=20 > > > > > I just ported the latest CVS drm-kernel code into the > > > > > 2.6.2 vanilla kernel.=20 > > > >=20 > > > > Do you have a patch for us to look at? > > >=20 > > > Yes, I think I posted it to the SourceForge bug tracker. It's down ri= ght > > > now, or I'd be including a bug ID #. > >=20 > > You mean the one in the subject? :) >=20 > Riiiight... that's what I get for staying up so late ;) >=20 > >=20 > > I've looked at the patch briefly. First of all, I find unified diffs > > much easier to read than context diffs. Then, I don't understand what > > exactly the patch was made against. Can hardly be against the 2.6.2 > > kernel, and at least the AGP related changes have been in DRI CVS for a > > while... > >=20 >=20 > It was against a checkout of drm-kernel, and then manually copy the .c > and .h files into the 2.6.2 tree. >=20 > >=20 > > > > Does the same problem occur if you just build the DRM from DRI CVS? > > >=20 > > > It won't compile. Aside from a small number of API changes, the > > > Makefile.linux is *severely* broken about include directories under 2= .6. > >=20 > > Works perfectly here... Do you have current DRI CVS from > > freedesktop.org? If so, please post the errors. >=20 > from freedesktop.org? not from sourceforge anymore? > :pserver:ano...@cv...:/cvsroot/gatos >=20 >=20 > >=20 > >=20 > > > > > Many apps work fine - xscreensaver, prboom, SpectrumGL, but some = others=20 > > > > > lock the X server up hard, such as tuxracer and BillardGL. > > > >=20 > > > > Are you using the 3D driver built from DRI and Mesa CVS, or an olde= r > > > > version? > > >=20 > > > I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gato= s > > > package and a manual install from the latest ati.2 cvs sources. > >=20 > > No lockups with tuxracer or BillardGL running the DRM from current DRI > > CVS on 2.6.2 (nor the one that ships with the kernel) here. You may wan= t > > to try a newer 3D driver. >=20 > The one that ships with the kernel won't fly due to version number - if > memory serves it did before installing ati.2, but seeing how the machine > (with its AIW Radeon) serves as my living room entertainment center, > having A/V capability trumped 3D.=20 >=20 > ati.2 CVSROOT: > :pserver:ano...@cv...:/cvsroot/gatos >=20 > >=20 >=20 > It's beginning to look like my entire problem might be having missed a > move of the CVS source hosting. Let me see what turns up... if that is > the case, I'd suggest modifying the Makefiles on the sf.net copy to > cause an error message if anyone tries compiling them. >=20 > While we're on the subject, what's the status of integration with the > XFree 4.4 betas? Would I be better off going that way? >=20 > OK, I just checked out the new xc tree... seems to be some confusion > going on between it and the documentation about having the Mesa tree. > Hrm? >=20 > Thanks, > - Hod McWuff >=20 |
From: Hod M. <ho...@wu...> - 2004-02-10 17:33:47
|
> The Radeon DRM and 3D drivers from the GATOS project are incompatible to > those from the DRI project. Unfortunately, GATOS didn't reflect this > incompatibility correctly in their DRM version, otherwise the wrong 3D > driver would refuse to run instead of locking up the machine. > Fortunately, the root cause of the incompatibility has been removed in > DRI CVS, GATOS just needs to adapt to that. OK, well I haven't seen a whole lot of activity from the Gatos folks in quite a while... what's that incompatibility you speak of? I might try my hand at removing it. Obviously I'd rather just have to merge the kernel modules, but if I have to dig into the XFree side then so be it... AIW Radeon can't properly be said to be supported until Gatos and DRI are playing nice together again. > > It's beginning to look like my entire problem might be having missed a > > move of the CVS source hosting. > You simply seem to have missed that GATOS and DRI are different > projects. :) Right... which seems like one hell of a thinko to me... *thwaps self* --=20 Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Michel <mi...@da...> - 2004-02-10 22:29:47
|
On Tue, 2004-02-10 at 18:33, Hod McWuff wrote: > > > Fortunately, the root cause of the incompatibility has been removed in > > DRI CVS, GATOS just needs to adapt to that. > > OK, well I haven't seen a whole lot of activity from the Gatos folks in > quite a while... what's that incompatibility you speak of? I might try my > hand at removing it. The locations of the framebuffer and GART apertures (MC_{FB,AGP}_LOCATION registers) used to be hardcoded to different places in the card's address space. Look at RADEONSetFBLocation() in radeon_driver.c, GATOS needs to do mostly the same, possibly with some modifications (I don't know if video capturing requires direct rendering to be enabled, for example). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |