Re: [R300] compilation
Dear Jacob, dear everyone, once you managed to get everything in place, would you mind to write down what you did in a form like: - Get xorg cvs via # cvs command co - cd into directory xy and edit Makefile z in some way - ./configure make - Get some other cvs tree via this command: # cvs othercommand co And so on? I get the impression that everyone inclined to test r300 has to reinvent the whole procedure for himself which is a big waste of time, imho. Thank you! Fionn -- Software patents- not allowed in Europe | See whats going on: Archiving Email - patented in Europe| http://freepatents.org/ E-Shopping Baskets - patented in Europe| Become active easily: Cross-compiling - patented in Europe| http://aktiv.ffii.org/eubsa/en --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
Vladimir Dergachev wrote: there are no problems with stretching the window I've experimented and found that 2 NOPs doesn't really help. if I set full screen to be the LCDs native resolution it happens less often. I think this problem DVI-related. Until I or someone else can show the problem is with the r300 code you should leave this alone. You can try to resize the screen to check whether this problem occurs in 2d as well. (You can use xrandr or KDE resize app for that). I tried KDE and I found no problems resizing. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Undefined symbols in Mesa compile
On Thu, 03 Feb 2005 23:50:21 -0800, Jacob Gorm Hansen [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: No special tinkering is required beyound recent Xorg CVS. Will version 6.8.1.902 (from Gentoo) be recent enough? no. you need xorg from cvs HEAD. Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Undefined symbols in Mesa compile
On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote: Vladimir Dergachev wrote: No special tinkering is required beyound recent Xorg CVS. Will version 6.8.1.902 (from Gentoo) be recent enough? I don't think so - this sounds like 6.8.2-rc1 You ca check this easily by looking in /var/log/Xorg.0.log - it should say direct rendering enabled if everything is ok. best Vladimir Dergachev Jacob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
On Fri, 4 Feb 2005, Rune Petersen wrote: Vladimir Dergachev wrote: there are no problems with stretching the window I've experimented and found that 2 NOPs doesn't really help. if I set full screen to be the LCDs native resolution it happens less often. I think this problem DVI-related. Until I or someone else can show the problem is with the r300 code you should leave this alone. You can try to resize the screen to check whether this problem occurs in 2d as well. (You can use xrandr or KDE resize app for that). I tried KDE and I found no problems resizing. Next step is to try some sort of 2d DGA applications (wesnoth ? SDL ?) and see if the problem is still there. Maybe it is only DGA that is broken. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] compilation
On Fri, 4 Feb 2005, Fionn Behrens wrote: Dear Jacob, dear everyone, once you managed to get everything in place, would you mind to write down what you did in a form like: - Get xorg cvs via # cvs command co - cd into directory xy and edit Makefile z in some way - ./configure make - Get some other cvs tree via this command: # cvs othercommand co 1. Get Xorg CVS, Get Mesa CVS Get r300_driver from CVS at r300.sf.net 2. Compile drm from r300.sf.net, insmod ./drm.ko ; insmod ./radeon.ko check for no lockups 3. Compile and install Xorg CVS. Check that there are no lockups 4. insmod drm modules as above, run Xorg, check for no lockups and direct rendering enabled in /var/log/Xorg.0.log 5. Read r300_driver/README, follow instructions to patch Mesa tree and compile it 6. Create a link from /usr/X11/lib/modules/dri/r300_dri.so to Mesa/lib/r300_dri.so 7. Try sync; glxgears - check for no lockups and framerate of about 1000 best Vladimir Dergachev And so on? I get the impression that everyone inclined to test r300 has to reinvent the whole procedure for himself which is a big waste of time, imho. Thank you! Fionn -- Software patents- not allowed in Europe | See whats going on: Archiving Email - patented in Europe| http://freepatents.org/ E-Shopping Baskets - patented in Europe| Become active easily: Cross-compiling - patented in Europe| http://aktiv.ffii.org/eubsa/en --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
Vladimir Dergachev wrote: On Fri, 4 Feb 2005, Rune Petersen wrote: Vladimir Dergachev wrote: there are no problems with stretching the window I've experimented and found that 2 NOPs doesn't really help. if I set full screen to be the LCDs native resolution it happens less often. I think this problem DVI-related. Until I or someone else can show the problem is with the r300 code you should leave this alone. You can try to resize the screen to check whether this problem occurs in 2d as well. (You can use xrandr or KDE resize app for that). I tried KDE and I found no problems resizing. Next step is to try some sort of 2d DGA applications (wesnoth ? SDL ?) and see if the problem is still there. Maybe it is only DGA that is broken. window-full screen works with wesnoth. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
special cases. q3a and NeHe lessons 2-20 don't look any worse. I haven't looked at the r300 code as it's not in Mesa CVS, but I'm wondering if you've noticed that the i915 driver does a similar task of converting fixed function GL to a programable fragment shader backend? It may be a bit late in the day, but there might still be a couple of things to pick up from looking at that code. Keith maybe it makes sense to start including r300 in mesa. You guys have made a lot of progress. It doesn't have to be built by default, and the development can still happen in r300 cvs (just sync them from time to time), but it might help with the testing since snapshots would be made nightly. OTOH, it's still fairly experimental. Sorry did not reply earlier, I had to take some time to think about this. The biggest reason at the moment against including R300 driver in Mesa CVS is that the code is a mess. There are r200 files that are not being used in any way and large sections of code simply cut'n'pasted from R200 driver with pieces commented out to allow everything to compile. Once proper vertex upload code has been put in this could be cleaned up, improper code removed and the driver would be in a much better shape. This would be needed not to just get the code respectable but to get an overview which features are working, which are half done and which are lacking altogether. The second big reason is that we cannot simply include Mesa driver alone - it would have to be accompanied by changes to the DRM driver. R300 DRM driver is stabilized as far as experimental development is concerned, but it is far from perfect from security standpoint (we basically allow almost arbitrary commands as we did not know what we would need when we started). best Vladimir Dergachev Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote: maybe it makes sense to start including r300 in mesa. You guys have made a lot of progress. It doesn't have to be built by default, and the development can still happen in r300 cvs (just sync them from time to time), but it might help with the testing since snapshots would be made nightly. OTOH, it's still fairly experimental. Sorry did not reply earlier, I had to take some time to think about this. The biggest reason at the moment against including R300 driver in Mesa CVS is that the code is a mess. There are r200 files that are not being used in any way and large sections of code simply cut'n'pasted from R200 driver with pieces commented out to allow everything to compile. I would really like to see the r300 code not get its own driver. Unified drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I don't know a good way to make sure they don't diverge more than they already have. I think the current development method is working fine for now, but that the end goal should be to fold the r300 code back into r200. The second big reason is that we cannot simply include Mesa driver alone - it would have to be accompanied by changes to the DRM driver. R300 DRM driver is stabilized as far as experimental development is concerned, but it is far from perfect from security standpoint (we basically allow almost arbitrary commands as we did not know what we would need when we started). Here again, ideally this would get folded upstream too, once it's at least secure. I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. - aajx pgp26u572pp07.pgp Description: PGP signature
Re: [R300] jump_and_click retagged.
On Fri, 4 Feb 2005, Adam Jackson wrote: On Friday 04 February 2005 15:26, Vladimir Dergachev wrote: maybe it makes sense to start including r300 in mesa. You guys have made a lot of progress. It doesn't have to be built by default, and the development can still happen in r300 cvs (just sync them from time to time), but it might help with the testing since snapshots would be made nightly. OTOH, it's still fairly experimental. Sorry did not reply earlier, I had to take some time to think about this. The biggest reason at the moment against including R300 driver in Mesa CVS is that the code is a mess. There are r200 files that are not being used in any way and large sections of code simply cut'n'pasted from R200 driver with pieces commented out to allow everything to compile. I would really like to see the r300 code not get its own driver. Unified drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I don't know a good way to make sure they don't diverge more than they already have. I think the current development method is working fine for now, but that the end goal should be to fold the r300 code back into r200. The second big reason is that we cannot simply include Mesa driver alone - it would have to be accompanied by changes to the DRM driver. R300 DRM driver is stabilized as far as experimental development is concerned, but it is far from perfect from security standpoint (we basically allow almost arbitrary commands as we did not know what we would need when we started). Here again, ideally this would get folded upstream too, once it's at least secure. I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. Folding DRM driver is not difficult, in fact currently there is just one extra file with r300-specific code. As for folding R300 driver, we'll see how things turn out. It is hard for me to imagine how this folding could take place - albeit it might turn out to be not too bad. An incomplete list of issues: * shaders are different from R200 hardware * the hardware state is different with registers in different locations. So R200 code like rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] ~R200_PLANE_MASK_ENABLE; won't work as there is no RB3D_CNTL that we know of. It is really quite bad - there are numerous R300 registers with offsets above 0x4000 while the largest R200 register I see used in Mesa driver is R200_RB3D_CBLENDCNTL at offset 0x3220. * I don't think we need software TCL code to be separate - as I understand this code is in R200 driver because initial driver did not support hardware TCL. (We do not support it either, yet) So unifying would require thorough understanding of both hardware platforms and Mesa drivers in general, and will likely imply a rewrite of large portions of both drivers. On the other hand, the texture allocation code can be shared almost entirely. Vertex processing can also be shared with small effort - albeit it would be nicer to use one of the templates, if any are available for that purpose. best Vladimir Dergachev - aajx --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
On Friday 04 February 2005 21:52, Vladimir Dergachev wrote: On Fri, 4 Feb 2005, Adam Jackson wrote: Here again, ideally this would get folded upstream too, once it's at least secure. I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. Folding DRM driver is not difficult, in fact currently there is just one extra file with r300-specific code. As for folding R300 driver, we'll see how things turn out. It is hard for me to imagine how this folding could take place - albeit it might turn out to be not too bad. You know, I actually started the r300 driver with this in mind, which is why you'll still see all those r200_* files around. The thing is, I neither have the hardware to test whether it still works on R200, nor can I currently contribute much to development. It really shouldn't require a complete rewrite, just a lot of careful (and tedious) refactoring. cu, Nicolai pgphN0PekkQlU.pgp Description: PGP signature
Re: [R300] jump_and_click retagged.
Adam Jackson wrote: I would really like to see the r300 code not get its own driver. Unified drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I don't know a good way to make sure they don't diverge more than they already have. I think the current development method is working fine for now, but that the end goal should be to fold the r300 code back into r200. The second big reason is that we cannot simply include Mesa driver alone - it would have to be accompanied by changes to the DRM driver. R300 DRM driver is stabilized as far as experimental development is concerned, but it is far from perfect from security standpoint (we basically allow almost arbitrary commands as we did not know what we would need when we started). Here again, ideally this would get folded upstream too, once it's at least secure. I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. I'm not so convinced that r200 and r300 driver (and radeon, for that matter) really should be only one driver. Why is it that bad to have 3 drivers? Those chips just ARE different. Sure, the 2d parts are more or less identical and certainly should be only one driver, but that's already the case. DRM should probably be the same too, since the differences needed are pretty much limited to what packets it accepts. But I'm not exactly sure how you'd unify the dri code. While you cannot deny that the drivers indeed look very similar, there are still a lot of differences. You will inevitably end up with lots of if Radeon do that, else code (or did you have #ifdef's in mind, so you would share the same source files, but would compile it to 3 targets in the end?). So you might be able to unify them, but I'd bet it won't look pretty. Of course, it depends on how dissimilar the chips actually are. IMHO the differences between radeon and r200 are too big to make unifying worthwile, I have only looked at the r300 driver briefly but the differences to r200 seem to be quite large too. As a side note, last time I checked ATI had 3 Direct3d drivers for the chips too. They have a unified package to install, and they may (no idea) share large parts of source code, but there are 3 distinct dlls in the end. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
On Friday 04 February 2005 16:17, Roland Scheidegger wrote: Adam Jackson wrote: I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. I'm not so convinced that r200 and r300 driver (and radeon, for that matter) really should be only one driver. Why is it that bad to have 3 drivers? Those chips just ARE different. Sure, the 2d parts are more or less identical and certainly should be only one driver, but that's already the case. DRM should probably be the same too, since the differences needed are pretty much limited to what packets it accepts. But I'm not exactly sure how you'd unify the dri code. While you cannot deny that the drivers indeed look very similar, there are still a lot of differences. You will inevitably end up with lots of if Radeon do that, else code (or did you have #ifdef's in mind, so you would share the same source files, but would compile it to 3 targets in the end?). No, definitely not #ifdef hell, down that road lies madness. We have this already though, in several drivers. Savage3D and Savage4, Intel 830/855/915, Voodoo3 and Voodoo4/5 even. And I would expect that the differences in features between chips corresponds well to GL features for the most part, so they're natural boundaries for conditionals anyway. So you might be able to unify them, but I'd bet it won't look pretty. Of course, it depends on how dissimilar the chips actually are. IMHO the differences between radeon and r200 are too big to make unifying worthwile, I have only looked at the r300 driver briefly but the differences to r200 seem to be quite large too. Documentation would be a large help here of course. Have any of the r300 developers asked ATI for the 3d docs? Or even unbowdlerised r200 docs. That would help greatly in seeing whether, for example, some of the r300 registers are also present on r200 and we just don't know it, per Vladimir's example earlier in the thread. As a side note, last time I checked ATI had 3 Direct3d drivers for the chips too. They have a unified package to install, and they may (no idea) share large parts of source code, but there are 3 distinct dlls in the end. Direct3D drivers are not really an apples-to-apples comparison since they'll try to factor out as many conditionals as possible for that last 0.03fps in 3dmark. fglrx is probably a more fair comparison, and fglrx covers r200 through r400 no problem. If we assume that that's the more maintainable solution from ATI's perspective, I have trouble seeing how distinct drivers would be more maintainable for us. As an example of what the non-unified road looks like, look at the glide source. Despite successive chips being pretty much strict supersets in terms of functionality, they clone the entire tree for each chip. I suspect the effort required to keep drivers unified is worth it in the long run. - ajax pgpHAk28G5N2q.pgp Description: PGP signature
Re: [R300] jump_and_click retagged.
Adam Jackson wrote:
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
The biggest reason at the moment against including R300 driver in Mesa CVS
is that the code is a mess. There are r200 files that are not being used
in any way and large sections of code simply cut'n'pasted from R200 driver
with pieces commented out to allow everything to compile.
I would really like to see the r300 code not get its own driver. Unified
drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I
don't know a good way to make sure they don't diverge more than they already
have. I think the current development method is working fine for now, but
that the end goal should be to fold the r300 code back into r200.
I agree. I think the i915 / i830 driver provides a good model. In that
driver you have two different groups of files. On group contains the
code that is the same for both drivers and is name vendor_*.[ch]. The
other group contains the code that is specific to each chip and is named
chip_*.[ch].
Since most of the driver is driven by function pointers, the only place
that has any 'if (this_chip) { foo; } else if (that_chip) { bar; }' is,
if I'm not mistaken, in the context creation code.
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
Adam Jackson wrote: On Friday 04 February 2005 16:17, Roland Scheidegger wrote: Direct3D drivers are not really an apples-to-apples comparison since they'll try to factor out as many conditionals as possible for that last 0.03fps in 3dmark. fglrx is probably a more fair comparison, and fglrx covers r200 through r400 no problem. If we assume that that's the more maintainable solution from ATI's perspective, I have trouble seeing how distinct drivers would be more maintainable for us. As an example of what the non-unified road looks like, look at the glide source. Despite successive chips being pretty much strict supersets in terms of functionality, they clone the entire tree for each chip. I suspect the effort required to keep drivers unified is worth it in the long run. the way I see it is that there needs very good reasons for merging drivers. not just for the sake of merging. My understanding is that r200 and r300 have very different interfaces. You only improve maintainability for code shared between the drivers. So the question should be how much are the drivers alike. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
So you might be able to unify them, but I'd bet it won't look pretty. Of course, it depends on how dissimilar the chips actually are. IMHO the differences between radeon and r200 are too big to make unifying worthwile, I have only looked at the r300 driver briefly but the differences to r200 seem to be quite large too. Documentation would be a large help here of course. Have any of the r300 developers asked ATI for the 3d docs? Or even unbowdlerised r200 docs. That would help greatly in seeing whether, for example, some of the r300 registers are also present on r200 and we just don't know it, per Vladimir's example earlier in the thread. I asked ATI for 3d documentation early of summer 2004, as far as I know they have not decided yet. They did provide 2d documentation for R300 chips. As a side note, last time I checked ATI had 3 Direct3d drivers for the chips too. They have a unified package to install, and they may (no idea) share large parts of source code, but there are 3 distinct dlls in the end. Direct3D drivers are not really an apples-to-apples comparison since they'll try to factor out as many conditionals as possible for that last 0.03fps in 3dmark. fglrx is probably a more fair comparison, and fglrx covers r200 through r400 no problem. If we assume that that's the more maintainable solution from ATI's perspective, I have trouble seeing how distinct drivers would be more maintainable for us. The thing is, it could very well be that one could port R300 driver to R200 cards, but I am somewhat certain that one cannot do the opposite. And R200 driver works already, so this is clearly a task for later. On the other hand, AFAIK, the tulip driver in Linux kernel was rewritten about 7 times (please correct me), so it would be a good idea to make the attempt. There are many reasons: * benefits of unification ajax has mentioned * optimization - we are certainly not bothering with it too much * having fun reachitecturing Mesa driver * perhaps some improvements in ease of developing + perhaps some non-C code generation (I see python is being used already, perhaps some ML or Lisp fans can contribute as well) + facility for runtime generation of machine code - for example have slow switch variables which, when changed, write a goto instruction at the appropriate place. * unexpected stuff that always shows up best Vladimir Dergachev --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
On Fri, 4 Feb 2005, Nicolai Haehnle wrote: On Friday 04 February 2005 21:52, Vladimir Dergachev wrote: On Fri, 4 Feb 2005, Adam Jackson wrote: Here again, ideally this would get folded upstream too, once it's at least secure. I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress. Folding DRM driver is not difficult, in fact currently there is just one extra file with r300-specific code. As for folding R300 driver, we'll see how things turn out. It is hard for me to imagine how this folding could take place - albeit it might turn out to be not too bad. You know, I actually started the r300 driver with this in mind, which is why you'll still see all those r200_* files around. The thing is, I neither have the hardware to test whether it still works on R200, nor can I currently contribute much to development. I did not know that :) I thought you just used R200 driver to get to something that would do fallbacks. It really shouldn't require a complete rewrite, just a lot of careful (and tedious) refactoring. If anyone wants to this can be easily checked by folding in texture handling code. If this can be done cleanly so it works on both drivers things are looking up. Otherwise, there is no point in bothering. A good deal of state switching code would need different files. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
Adam Jackson wrote: I'm not so convinced that r200 and r300 driver (and radeon, for that matter) really should be only one driver. Why is it that bad to have 3 drivers? Those chips just ARE different. Sure, the 2d parts are more or less identical and certainly should be only one driver, but that's already the case. DRM should probably be the same too, since the differences needed are pretty much limited to what packets it accepts. But I'm not exactly sure how you'd unify the dri code. While you cannot deny that the drivers indeed look very similar, there are still a lot of differences. You will inevitably end up with lots of if Radeon do that, else code (or did you have #ifdef's in mind, so you would share the same source files, but would compile it to 3 targets in the end?). No, definitely not #ifdef hell, down that road lies madness. Definitely agree here :-). We have this already though, in several drivers. Savage3D and Savage4, Intel 830/855/915, Voodoo3 and Voodoo4/5 even. And I would expect that the differences in features between chips corresponds well to GL features for the most part, so they're natural boundaries for conditionals anyway. True. I think though savage3D and Savage4 are quite similar, so are Voodoo3 and Voodoo4. The intel driver is a good argument however, i830 and i915 are quite different. It still manages to share quite some files. I'm not so sure though a unified radeon/r200/r300 driver would actually share a lot of code. Some stuff is certainly identical for all of them (things like lock code, parts of cmdbuf/ioctl code, texmem, sanity, maybe vertex submission (maos_arrays), and probably other stuff as well). That's actually more than I initially thought, so maybe it would be worth it. Though if r200 and r300 are going to be unified, I'd definitely suggest that radeon gets unified too. The code which can be shared between r200 and r300 is likely going to be pretty much the same as the code which can be shared between radeon and r200, I think. In fact, if one would now unify radeon and r200 driver, this might allow the r300 driver to be more easily added a bit later. Any volunteers ;-). As a side note, last time I checked ATI had 3 Direct3d drivers for the chips too. They have a unified package to install, and they may (no idea) share large parts of source code, but there are 3 distinct dlls in the end. Direct3D drivers are not really an apples-to-apples comparison since they'll try to factor out as many conditionals as possible for that last 0.03fps in 3dmark. fglrx is probably a more fair comparison, and fglrx covers r200 through r400 no problem. If we assume that that's the more maintainable solution from ATI's perspective, I have trouble seeing how distinct drivers would be more maintainable for us. That's a good point. As an example of what the non-unified road looks like, look at the glide source. Despite successive chips being pretty much strict supersets in terms of functionality, they clone the entire tree for each chip. I suspect the effort required to keep drivers unified is worth it in the long run. I think glide is a very good example when you really should unify the code, since really pretty much all code could be shared for all chips. I would suspect r100/r200/r300 are quite a bit more different, and less of the code will be the same. But maybe you're right, and in the long run it would really be beneficiary. As Ian said, the intel driver seems to be a useful model. It shares the common code, and still nicely separates the code when the implemenentation needs to be different. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] jump_and_click retagged.
Though if r200 and r300 are going to be unified, I'd definitely suggest that radeon gets unified too. The code which can be shared between r200 and r300 is likely going to be pretty much the same as the code which can be shared between radeon and r200, I think. In fact, if one would now unify radeon and r200 driver, this might allow the r300 driver to be more easily added a bit later. Any volunteers ;-). I think about it everytime I port some fixes from r200 to radeon :-) but then I get scared to be honest it probably isn't a huge job, the radeon/r200 are quite alike, you also have the issue that ATI duplicate a lot of registers at different places, and without docs its hard to know where these are.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI lockup on SuperSavage IX/C
Aha, you have a SuperSavage. Unfortunately it seems like vertex DMA locks up these cards. Other SuperSavage users reported the same. I don't know why and I can't debug the problem because I don't have a SuperSavage to test (and neither has Alex :( ). The only way seems to be to disable vertex DMA. There is a driconf option for that named enable_vdma. It's on by default. Set it to false. I had to work around a hardware bug on Savage IX too. Take a look at drm/shared-core/savage_bci.c (function dispatch_dma_prim) for the details. Maybe you can try if the same helps on your SuperSavage? Regards, Felix Am Freitag, den 04.02.2005, 18:16 -0500 schrieb Owen Taylor: I spent some time trying to debug the lockup I'm seeing with the new vertex code and came up pretty empty. The lockup I see is that with even the simplest GL program (say progs/redbook/hello) as soon as rendering starts, the X server first eats 100% CPU and becomes pretty much entirely unresponsive ... the cursor is slowly updated in a corrupted fashion (multiple copies). During this period, the server is spending most (but not all) of the CPU time in ShadowWait(), but I see the same behavior if I turn ShadowStatus off. Then after a maybe 30 seconds the PCI bus locks and the machine becomes unresponsive. I couldn't find an obvious correlation with any particular action being executed by the GL client when I single-stepped through the execution of _mesa_Flush though the fact that it is gradual makes it hard to be certain. Assuming that I didn't screw up the build somehow (not impossible) this should be with CVS head of xorg/xc/programs/Xserver, drm and Mesa. I'm hoping that this sounds like a familiar problem, since I don't have much idea how to debug it further. Regards, Owen -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] compilation
Vladimir Dergachev wrote: 1. Get Xorg CVS, Get Mesa CVS Get r300_driver from CVS at r300.sf.net 2. Compile drm from r300.sf.net, insmod ./drm.ko ; insmod ./radeon.ko check for no lockups 3. Compile and install Xorg CVS. Check that there are no lockups 4. insmod drm modules as above, run Xorg, check for no lockups and direct rendering enabled in /var/log/Xorg.0.log 5. Read r300_driver/README, follow instructions to patch Mesa tree and compile it 6. Create a link from /usr/X11/lib/modules/dri/r300_dri.so to Mesa/lib/r300_dri.so 7. Try sync; glxgears - check for no lockups and framerate of about 1000 I am just getting the message (WW) RADEON(0): Direct Rendering not yet supported on Radeon 9500 and newer cards. My card is a Radeon 9600SE. Don't I have to tell X or Mesa to use the r300_dri.so file? Do I have to install my (partially compiled) Mesa? Jacob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Undefined symbols in Mesa compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: | On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote: | Will version 6.8.1.902 (from Gentoo) be recent enough? | | | I don't think so - this sounds like 6.8.2-rc1 Actually RC2 -- it's how the numbering scheme works. (version-1).90X is (version)RCX. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCBCF6XVaO67S1rtsRAl0iAJ9TwXlxvS4flSbIUOQQ9Q6bB0WHDACeOm9Z 8pnLBrnyUnUCVMYfZSkg8tA= =s1Hb -END PGP SIGNATURE- --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] compilation
On Fri, 4 Feb 2005, Jacob Gorm Hansen wrote: Vladimir Dergachev wrote: 1. Get Xorg CVS, Get Mesa CVS Get r300_driver from CVS at r300.sf.net 2. Compile drm from r300.sf.net, insmod ./drm.ko ; insmod ./radeon.ko check for no lockups 3. Compile and install Xorg CVS. Check that there are no lockups 4. insmod drm modules as above, run Xorg, check for no lockups and direct rendering enabled in /var/log/Xorg.0.log 5. Read r300_driver/README, follow instructions to patch Mesa tree and compile it 6. Create a link from /usr/X11/lib/modules/dri/r300_dri.so to Mesa/lib/r300_dri.so 7. Try sync; glxgears - check for no lockups and framerate of about 1000 I am just getting the message (WW) RADEON(0): Direct Rendering not yet supported on Radeon 9500 and newer cards. This means you have old Xorg code. You need to compile new one from CVS. best Vladimir Dergachev My card is a Radeon 9600SE. Don't I have to tell X or Mesa to use the r300_dri.so file? Do I have to install my (partially compiled) Mesa? Jacob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] compilation
Vladimir Dergachev wrote: I am just getting the message (WW) RADEON(0): Direct Rendering not yet supported on Radeon 9500 and newer cards. This means you have old Xorg code. You need to compile new one from CVS. Hmm, apparently the 'make install' had not nuked all of my old X11 binaries. Now it works, thanks a lot! Jacob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] compilation
On Fri, 4 Feb 2005, Jacob Gorm Hansen wrote: Vladimir Dergachev wrote: I am just getting the message (WW) RADEON(0): Direct Rendering not yet supported on Radeon 9500 and newer cards. This means you have old Xorg code. You need to compile new one from CVS. Hmm, apparently the 'make install' had not nuked all of my old X11 binaries. Now it works, thanks a lot! Whoops, I forgot about that. What happened is that Xorg has switched to using *.so loader (as opposed to one that used *.o files). The old files were left in place and the whole thing got confused. best Vladimir Dergachev Jacob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] problems with radeonfb in linux-2.6.11-rc3
On Fri, 2005-02-04 at 00:29 +, Armin Krieg wrote: I'm using a Radeon 9600XT and there are no error-messages in syslog and i hope i can give also another bug-report, although I think its a problem with the new dri-code... I'm using a cvs-snapshot of x.org and with the newer kernels 2.6.11-XXX or a cvs-snapshot of drm my screen is completely distorted, but i can see the edges of windows...so it seems to be a problem with a correct order of the horizontal lines... Sounds like it could be related to the recently added colour buffer tiling... CC'ing dri-devel, please follow up there only about this problem. Does your X server log contain 'Color tiling enabled by default'? If so, does Option ColorTiling off fix the problem? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
