[Dri-devel] Preliminary changes for AGP texture region (mach64)
I've commited some preliminary changes necessary for AGP texturing to the mach64-0-0-4-branch. The changes are only in the DDX and Mesa portions of the driver, no drm changes yet. I've added necessary fields to the structures in mach64_dri.h (DDX), using r128 as a model. I've disabled the ring buffer stuff, but added it to the header as a starting point. I haven't really thought about what that should look like for mach64 yet. I haven't changed any existing fields that were being used (though we might want to consider some name changes to avoid confusion and sync up with other drivers, e.g. bufferSize should probably be bufferMapSize in ATIDRIServerInfoRec). The texture region is now mapped in AGPInit and should show up in the X log and /proc/dri, but is not used yet and the AGP register initialization is still disabled. About all this does right now is add the AGP mode info to the renderer string, but the infrastructure needed for the DDX and Mesa driver are there now. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ATI Radeon (R100?), Radeon 8500 (R200?)
Hi there, I've only a few questions : 1.) @Radeon: I'm using mdk 8.2 which comes with XFree86 4.2.0, kernel 2.4.18, is there any difference with the driver (except TL) in the CVS ?. CannonSmash crashes whole X, Tux in TuxRacer isn't rendered correctly, Tulpas crashes during startup. 8-- part of XFree log --- (II) Module radeon: vendor=The XFree86 Project compiled for 4.2.0, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.5 8 2.) Radeon 8500: Is there a plan to support this card ? I know 2D is supported, but 3D ? If no, why ?, if yes, when ? 3.) where I can help ? Currently I'm reading through DRI documentation, archictecture. My qualifications which may helpful are .) long time C developer, not only user apps, also programming graphical LCD Panels in microcontroller apps, currently I prefer object oriented approaches (c++), some knowledge about Direct 3D programming, little knowledge about OpenGL and Java3D model. regards odiX ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Nightly snapshots from tcl-0-0-branch available
Nightly snapshots of tcl-0-0-branch are now also available from http://dri.sourceforge.net/snapshots/bleeding-edge/ with the name radeon-tcl-* . Now is really very easy to build any other branch. All the scripts I use are available in http://dri.sourceforge.net/snapshots/scripts/. Here is a brief description of what they do: - bldall.sh: shell script to be called from cron which builds and copies the snapshots to the DRI website. - bldall_mefriss1.sh: same as above, but to be run in my workstation; it builds the branchs which the compiler farm isn't able to. - cvsbld.sh: shell script that chekout the CVS, builds it, and then make a set of binary snapshots from it - dripkg.sh: shell script to package a binary driver; although the core is the same as Alan's script, it suffered a lot of reorganizations to handle seperate source and build trees, non-interactivity, partial drivers, and some more misc stuff. - install.sh: shell script to be run by the user; basically Alan's original script plus the ability to install/uninstall partial drivers (i.e., without the device independent libraries) - upload.sh download.sh: shell scripts to upload and download all these scripts to and from the SF shell, to use from the compiler farm and my workstation - purge-snapshots.sh: shell script to purge all binary snapshots older than 7 days from the DRI website; also run from cron - dri-xfree86.sed: sed script to patch the host.def config file to avoid dependencie of a existing XFree86 in the system José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Extras package
On 2002.04.19 19:16 Frank Worsley wrote: Hi, I'm getting repeated emails from people asking for an extras package. Anybody want to volunteer to make one? All it needs to contain is an updated X server binary and a shell script that installs the binary and does suid root on it. - Frank I can add a script to build such a thing when the snapshots are being made. But what's the purpose of such a extras package? Excluding the driver modules the X server in the DRI CVS isn't changed except when is a new X release. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon (R100?), Radeon 8500 (R200?)
Manfred, On 2002.04.20 09:52 Manfred Odenstein wrote: Hi there, I've only a few questions : 1.) @Radeon: I'm using mdk 8.2 which comes with XFree86 4.2.0, kernel 2.4.18, is there any difference with the driver (except TL) in the CVS ?. ... The CVS trunk includes Mesa 4.x, which has several improvements over the 3.4.x versions, and most probably several bugfixes. You can test it by going at http://dri.sourceforge.net/snapshots/ . The TL is currently being done in a separate branch, tcl-0-0-branch. You can test it by downloading it from ftp://ftp.tungstengraphics.com/dri/ or from http://dri.sourceforge.net/snapshots/bleeding-edge (the later are experimental nighly snapshots). 2.) Radeon 8500: Is there a plan to support this card ? I know 2D is supported, but 3D ? If no, why ?, if yes, when ? This is a FAQ which was answered here some time ago (check http://dri.sourceforge.net/doc/faq/hardware.html#RADEON-8500 ) but nothing really new happened since then, so I don't know in what foot things stand... (My impression is that actually very few people have this card, as all await for some support before aquiring it!) 3.) where I can help ? Currently I'm reading through DRI documentation, archictecture. My qualifications which may helpful are .) long time C developer, not only user apps, also programming graphical LCD Panels in microcontroller apps, currently I prefer object oriented approaches (c++), some knowledge about Direct 3D programming, little knowledge about OpenGL and Java3D model. All help is welcome. You seem to be interested on Radeon. Keith Whitwell is the one working more closely to it, on the scope of a Tungsten Graphics project. Michael Fitzpatrick also has been working on it. My understanding is that Radeon is one of the most advanced driver, although there are certain hardware features not yet supported (such as TL) and is haunted by some nastymisterious bugs. My advice is to follow this list, assist the weekly IRC meeting, read the FAQ (http://dri.sourceforge.net/doc/faq/) and when you feel ready it will be more clear wherehow you would like to help. (Probably hunting down those bugs would be a nice start...) regards odiX Regards, José Fonseca PS: I'm just a guy that joined recentely the DRI development and that is passing along the information that has received so far. My interests are on the Mach64 chipset. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Extras package
The idea was that people who don't have XFree86 4.1 or later can just use the Extras package to upgrade their X server, instead of upgrading all of X. This worked pretty well in the past for people who had version problems with the X server being too old for the binary package. - Frank On Sat, 2002-04-20 at 02:13, José Fonseca wrote: On 2002.04.19 19:16 Frank Worsley wrote: Hi, I'm getting repeated emails from people asking for an extras package. Anybody want to volunteer to make one? All it needs to contain is an updated X server binary and a shell script that installs the binary and does suid root on it. - Frank I can add a script to build such a thing when the snapshots are being made. But what's the purpose of such a extras package? Excluding the driver modules the X server in the DRI CVS isn't changed except when is a new X release. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: agp texture region info added to drm
Jose, I added the remaining bits to copy the agp texture region info to the drm. It's not used, but the information is there in case we need it later. I hope you don't mind, but I took the liberty of converting your drm emit_state functions to use the DMA* macros, which ensures that enough fifo entries are present before doing the state reg. writes, so we avoid potential lockups. BTW, I haven't noticed any texture problems, even after disabling the UploadHWStateLocked in mach64_ioctl.c:FlushVerticesLocked (this is redundant if the kernel is emitting state). Were you seeing the problem with UploadHWStateLocked enabled? I tried UT with UploadHWStateLocked enabled and without the DMA* macros, and with UploadHWStateLocked disabled and _with_ the DMA* macros. Both of those combinations worked fine. I haven't tried with UploadHWStateLocked disabled and without the DMA* macros yet, though. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: agp texture region info added to drm
On 2002.04.20 21:21 Leif Delgass wrote: Jose, I added the remaining bits to copy the agp texture region info to the drm. It's not used, but the information is there in case we need it later. I hope you don't mind, but I took the liberty of converting your drm emit_state functions to use the DMA* macros, which ensures that enough fifo entries are present before doing the state reg. writes, so we avoid I don't mind at all. In fact I also did the same here, and I was about to check when I received your email, and things started to work again! *ufh* potential lockups. BTW, I haven't noticed any texture problems, even after disabling the UploadHWStateLocked in mach64_ioctl.c:FlushVerticesLocked (this is redundant if the kernel is emitting state). Were you seeing the problem with UploadHWStateLocked enabled? I tried UT with UploadHWStateLocked enabled and without the DMA* macros, and with UploadHWStateLocked disabled and _with_ the DMA* macros. Both of those combinations worked fine. I haven't tried with UploadHWStateLocked disabled and without the DMA* macros yet, though. Yep. that seems to be the problem... -- Leif Delgass http://www.retinalburn.net Now I'll merge your changes with some code cleanups I did here. The question is what do next? These are some things that we could do: - check the FIFO when PseudoDMAing (as in Utah) - Texture Uploads through the DRM (blits) - DMA buffer aging (even though we don't have DMA we gonna need this I suppose ) - AGP texturing (this can be done without DMA, can't it?) - optimize the DMA buffer construction in the primitive drawings I think there are more. What do you think we (each one) should focus next? José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: agp texture region info added to drm
On Sat, 20 Apr 2002, José Fonseca wrote: On 2002.04.20 21:21 Leif Delgass wrote: Jose, I added the remaining bits to copy the agp texture region info to the drm. It's not used, but the information is there in case we need it later. I hope you don't mind, but I took the liberty of converting your drm emit_state functions to use the DMA* macros, which ensures that enough fifo entries are present before doing the state reg. writes, so we avoid I don't mind at all. In fact I also did the same here, and I was about to check when I received your email, and things started to work again! *ufh* potential lockups. BTW, I haven't noticed any texture problems, even after disabling the UploadHWStateLocked in mach64_ioctl.c:FlushVerticesLocked (this is redundant if the kernel is emitting state). Were you seeing the problem with UploadHWStateLocked enabled? I tried UT with UploadHWStateLocked enabled and without the DMA* macros, and with UploadHWStateLocked disabled and _with_ the DMA* macros. Both of those combinations worked fine. I haven't tried with UploadHWStateLocked disabled and without the DMA* macros yet, though. Yep. that seems to be the problem... -- Leif Delgass http://www.retinalburn.net Now I'll merge your changes with some code cleanups I did here. The question is what do next? These are some things that we could do: - check the FIFO when PseudoDMAing (as in Utah) - Texture Uploads through the DRM (blits) - DMA buffer aging (even though we don't have DMA we gonna need this I suppose ) - AGP texturing (this can be done without DMA, can't it?) - optimize the DMA buffer construction in the primitive drawings I think there are more. What do you think we (each one) should focus next? José Fonseca Well, I think it would be good to combine the first and last option. A few small changes will enable checking the FIFO (which I see as a high priority), and handling sequential register writes in a flush function for pseudo-DMA. For sequential writes, we need to detect where these occur in a buffer and then increment the register address with each write, like the utah-glx pseudo-DMA flush. I think we need this in place before we start to work on new ioctls. These changes will allow streamlining the vertex buffers. Then I think we should think about how to handle the descriptor tables. I'd like to stablilize the structures, so we have everthing we'll need there. I'm not too familiar with how the buffer aging works, I'll have to look at that. I think we could put off texture blits for a while. I was thinking that it might be easiest to start off the DMA testing on swaps, clears and state, and then move on to the vertex buffers, etc. I can continue looking at the AGP texturing, and I think you're right that almost everthing is in place for that already now. I believe we can do this without blits, by just copying textures into the AGP region. What are your thoughts? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: agp texture region info added to drm
On 2002.04.20 22:41 Leif Delgass wrote: On Sat, 20 Apr 2002, José Fonseca wrote: ... The question is what do next? These are some things that we could do: - check the FIFO when PseudoDMAing (as in Utah) - Texture Uploads through the DRM (blits) - DMA buffer aging (even though we don't have DMA we gonna need this I suppose ) - AGP texturing (this can be done without DMA, can't it?) - optimize the DMA buffer construction in the primitive drawings I think there are more. What do you think we (each one) should focus next? José Fonseca Well, I think it would be good to combine the first and last option. A few small changes will enable checking the FIFO (which I see as a high priority), and handling sequential register writes in a flush function I agree with the FIFO thing. for pseudo-DMA. For sequential writes, we need to detect where these occur in a buffer and then increment the register address with each write, like the utah-glx pseudo-DMA flush. I think we need this in place before we start I thought that my code already handled this, but I saw a bug from your description. (I'm going to commit a fix for it now). to work on new ioctls. These changes will allow streamlining the vertex buffers. Then I think we should think about how to handle the descriptor tables. I'd like to stablilize the structures, so we have everthing we'll I agree in that we should stabilize eveything to smooth the DMA integration. need there. I'm not too familiar with how the buffer aging works, I'll have to look at that. I think we could put off texture blits for a while. I was thinking that it might be easiest to start off the DMA testing on swaps, clears and state, and then move on to the vertex buffers, etc. I can continue looking at the AGP texturing, and I think you're right that almost everthing is in place for that already now. I believe we can do this without blits, by just copying textures into the AGP region. What are your thoughts? We pretty much agree. We must prepare the DMA work the best we can. Now is just a matter of not doing duplicate work. A good thing is that we have very different timezones, but nevertheless we should pick different subject. So, Leif, pick what're keen on and I'll pick other thing. -- Leif Delgass http://www.retinalburn.net José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking; was: Helping on Mach64
On Thu, 18 Apr 2002 23:37:20 -0400 (EDT) Leif Delgass [EMAIL PROTECTED] wrote: I can provide some background on this, since I played around with the locks back when Manuel was working on this. First off, it'll probably be most productive to work on this on the new branch, when all the register programming and DMA will be in the DRM. However, a good start could be made by investigating and hacking on the current branch too. OK, I checked the mach64-0-0-4-branch out tonight and compiled it. It runs surprisingly usable. The only big difference to mach64-0-0-3 which I noticed is that all the CPU load is in the kernel now :) There are locks in place in aticonsole.c for vt/mode switches (xc/programs/Xserver/hw/xfree86/drivers/ati) and in atimach64.c for the XAA functions. The disabled code to initialize 2D acceleration is in ATIMach64AccelInit() in atimach64.c. I guess the first thing to do is to make sure that the locks are in the right place, and that the 2D driver's state is restored correctly. Currently, if a GL context is active, a vt or mode switch will cause a lockup on returning to the X server (ATIEnterVT and ATISwitchMode). Also dragging a window or other XAA Ok, I checked aticonsole.c. The existing locks seem to be in the right places. If I understand the problem correctly I will have to make sure that the hardware is in 2d state when the X-server has the lock. This means that it has to check whether it had the lock before. Only if not it will have to restore 2d state. This mechanism could look similar to LOCK_HARDWARE and mach64GetLock in mach64_lock.[ch]. accelerated actions will cause a lockup. These lockups will likely require a reboot, but you may be a able to kill the X server remotely if you're lucky. :) I can say from experience that debugging this can be frustrating and time-consuming. While r128 and radeon driver code can be a useful reference, it's important to realize that they have command engines that are quite different from mach64. As I mentioned before, I don't have another machine to do this. But maybe I can build a simple input device which is not used by X to trigger a background process to kill the X-server. At any rate, if anyone is interested in helping out and has the time -- read Jose's developer FAQ, have a look at the code, post questions and results to the list, and try to drop in on the Monday IRC meetings when you get the chance. Any help you can provide would be greatly appreciated. -- Leif Delgass http://www.retinalburn.net Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! msg04076/pgp0.pgp Description: PGP signature
