Re: Kernel / user interface for new memory manager
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: Alan Cox wrote: The log design presents numerous opportunities for rogue processes to do bad things. At some level, that's inherent in the nature of direct rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. I still think 'we may not succeed 100%, at least in the short term' is a bad excuse for not trying, but that seems to be mostly me. Its critical that the kernel knows what memory on the video space is being used for command queue and protects it. From the description of the SiS turboqueue I suspect you may be able to root a sis video box that way but without full docs I can't tell. Protecting a statically assigned command queue is one thing (something similar to what's currently done on radeon would be sufficient), protecting dynamically allocated video memory is another. If the DRM operated on memory objects instead of with offsets directly, it should be trivial: It only has to check that the caller has permission to access the memory objects involved. Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that. May I ask why we can't, assuming this is done via EXA callbacks into the DDX driver that use the shared memory manager? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there
On Thu, 2005-08-18 at 14:19 -0500, Alan Grimes wrote: I installed the latest CVS DRM source a few days ago. (the kernel modules), and it is still broken! =( Maybe if someone could point me in the general vicinity of the culprit, I could take a whack at it myself... [EMAIL PROTECTED] ~/Croquet0.3 $ squeak DRM_RADEON_TEXTURE: return = -11 offset=0xea60e000 image width=1024 height=512 blit width=1024 height=2048 data=0x6e656200 I already explained the problem to you: For some reason, on your system, errno doesn't seem to contain EAGAIN even though the ioctl call returns -EAGAIN. Does the attached patch work for you? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer Index: src/mesa/drivers/dri/r200/r200_texmem.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texmem.c,v retrieving revision 1.11 diff -p -u -r1.11 r200_texmem.c --- src/mesa/drivers/dri/r200/r200_texmem.c 10 Feb 2005 22:36:06 - 1.11 +++ src/mesa/drivers/dri/r200/r200_texmem.c 19 Aug 2005 15:41:10 - @@ -427,7 +427,7 @@ static void uploadSubImage( r200ContextP fprintf(stderr, DRM_RADEON_TEXTURE: again!\n); usleep(1); } - } while ( ret errno == EAGAIN ); + } while ( ret ( ret == -EAGAIN || errno == EAGAIN ) ); UNLOCK_HARDWARE( rmesa );
Re: Xegl on old hardware?
On Sun, 2005-08-14 at 13:50 -0400, Adam Jackson wrote: On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture ARB_texture_env_combine Some kind of render-to-texture functionality (preferably framebuffer objects) will probably be crucial, at least for compositing. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Update on R200/Squeak/croquet crash
On Fri, 2005-08-05 at 23:09 -0500, Alan Grimes wrote: I don't know exactly where these errors are coming from (UNIX IS EVIL) No, it's not. In contrast to another widespread OS, it does give you a lot of useful information: but here they are: [EMAIL PROTECTED] ~/Croquet0.3 $ squeak DRM_RADEON_TEXTURE: return = -11 offset=0xec40 image width=2048 height=256 blit width=1024 height=2048 data=0x6d9b9200 The RADEON_TEXTURE ioctl of the DRM failed. There should be some accompanying kernel output. This is a bug either in the r200 DRI driver or in the DRM. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Update on R200/Squeak/croquet crash
On Fri, 2005-08-05 at 23:09 -0500, Alan Grimes wrote: DRM_RADEON_TEXTURE: return = -11 Actually, -11 is -EAGAIN, so the r200 driver should just call the ioctl again. So this definitely looks like a bug in the r200 driver. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to know the packets you have submitted have been consumed by the GPU
On Thu, 2005-08-04 at 07:25 -0700, Prashanth Hegde wrote: I am using Radeon 9000 series graphics card. I have this problem. I use indirect buffering for submiiting packets to the GPU. Once I tell hardware that I have placed the packet at some location, I need to wait till it has finished processing it. How do I know that the GPU has consumed all the packets?. I can think of the following at this point: 1. After submission poll CP status till it becomes idle 2. Monitor the read/write pointers 3. Update a location in memory( AGP aperture) via scratch registers. This can be the last packet in the submitted data. That's how the radeon DRM does it, see RADEON_DISPATCH_AGE() and radeon_freelist_get(). Note that it currently indeed has the card write the scratch register contents back to AGP memory, but that's unreliable with some AGP bridges. It would be better to write to PCI memory instead. Fixing that would be a nice little project for someone who wants to get their hands dirty with the DRM. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote: On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote: ioctls where removing the root check introduces privelege escalation for users with read access to the DRM device (at least): - DRM_R128_INDIRECT - DRM_RADEON_INDIRECT How do we secure these? By requiring root. But I didn't review all the ioctls, so these might not be all of the root-requiring ioctls that continue to need it. I thought we built a command verifier to check things like this. These ioctls are designed for privileged clients like the current DDX drivers and thus unchecked. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On Wed, 2005-08-03 at 15:14 -0400, Jon Smirl wrote: On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: These are the indirect ioctls, which allow the X Server to submit a buffer of any commands it wants. You could probably build a (or extend the current) verifier for the all the things the X Server has done through that ioctl, but that hasn't been done. So there is probably a general security hole here if I can convice the Xserver to use the buffer addresses I want. That would require a security hole in the X server. The attacker is root already in that case. Who uses these? The current DDX drivers. They aren't used in the mesa tree. So why did you change their requiring root? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote: On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: They aren't used in the mesa tree. So why did you change their requiring root? The version of Xegl I am making does not run as root. [...] I know. You missed my question: Why do you change the behaviour of code that doesn't affect what you're trying to achieve? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon driver stops C3 if DRI is enabled
On Tue, 2005-07-26 at 11:07 -0700, Lorenzo Colitti wrote: Using the radeon driver from recent X.org CVS (on Linux 2.6.11.10), Are you implying that the issue didn't occur with older versions of X and/or the kernel? my CPU never enters C3 while under X. This causes me to lose about 30 minutes of battery life. This is due to the radeon driver causing bus master activity: if I switch to a text console C3 starts getting used again, and if drm.ko is not available when X starts (or if dri is disabled [1]), the CPU enters C3 under X too. Is there something that can be done to fix this? Not sure; bus mastering is used for sending commands to the GPU when the DRI is enabled (I wouldn't exactly call that 'pointless'...), but that shouldn't be going on all the time, unless e.g. a client that rarely (but regularly) redraws parts of its windows is enough to prevent the CPU from entering C3? Either way, it would be very useful if you could somehow determine exactly what the guilty bus mastering cycles do. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Tue, 2005-07-12 at 13:06 +0200, Sander Sweers wrote: Well xscreensaver is horrible to do any tests with, I never get above the 25 fps :( Which hack(s) are you trying, and are you passing -delay 0? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is AGP apeture at zero on x86 okay?
On Sat, 2005-07-09 at 11:08 +0100, Dave Airlie wrote: On my x86 laptop I get Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 915GM Chipset. agpgart: AGP aperture is 256M @ 0x0 This machine doesn't have an AGP card, just a PCI Express ATI Radeon X300.. However when the DRM loads it attempts to setup an mtrr at 0, which of course clashes with the mtrr for my RAM I guess with a PCIe card, it shouldn't set up an MTRR for the AGP aperture in the first place? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)
On Tue, 2005-07-05 at 17:47 +0100, Hamish Marson wrote: Tino Keitel wrote: On Mon, Jul 04, 2005 at 18:15:36 -0700, Nguyen The Toan wrote: There's a lot of flickering with OpenGL screensavers that came with KDE. Did I miss something? or the OpenGL screensavers is not supported yet ? I had the same here on my Radeon 9600. It did not happen with the same screensaver started from xscreensaver. I get the same. (Thinkpad r50p, FireGL-T2 == rv350) Is it possible that the GL code/KDE is setting EnablePageFlip locally for the screensaver? No, this is a known bug in the KDE screensaver code. Search the list archives if you want to know more. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote: On Sun, 26 Jun 2005 23:48:11 -0400 Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: Disagree also about axing the comment - its useful to know why something is being done. Wait, the comment says TODO: Remove this; we can't afford to let userspace control something that locks up the graphics card so easily. We're not removing the code being referred to, as far as I've heard, and we can't afford is contradictory to what we have agreed on for DRI policy (drivers can't escalate privelege, but can hang the machine). When did this 'agreement' occur? I can't remember agreeing to that. That we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: Disagree also about axing the comment - its useful to know why something is being done. Wait, the comment says TODO: Remove this; we can't afford to let userspace control something that locks up the graphics card so easily. We're not removing the code being referred to, as far as I've heard, and we can't afford is contradictory to what we have agreed on for DRI policy (drivers can't escalate privelege, but can hang the machine). When did this 'agreement' occur? I can't remember agreeing to that. That we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On Wed, 2005-06-22 at 00:46 +0100, Dave Airlie wrote: At the moment I'm having similiar issues with Radeon XvMC it initially will require root as I'm not sure how to submit the command streams outside of indirect buffers which are a root only thing... Can't it be done the same way as for 3D commands, using specialized ioctls? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM IRQ handling
On Wed, 2005-06-08 at 00:01 -0400, Jon Smirl wrote: On 6/7/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2005-06-07 at 15:48 -0400, Jon Smirl wrote: Am I right in this interpretation? First I need to get the bus/device/func of the card, then I need to tell this to the driver (which must already know this info). I then get back the IRQ number, which I then pass back to the driver (which already know this) and tell it to turn interrupts on. While we are at it, why the hell did we split up the PCI ID in bus,dev,fn like that ? We really want either a single structure containing the PCI ID to be passed around or a C string. The current scheme can't be made to work properly with PCI domains. There is no need to fix the call parameters, the calls themselves aren't really needed. User space shouldn't need to pass the PCI slot id back into a driver it already has a handle for. The driver should know this info without being told. These call messes are a result of fbdev and DRM not being linked. This prevents DRM from using the kernel PCI ID mechanism for binding to hardware. We can't add PCI ID binding to DRM since that prevents fbdev from loading. The only solution is to link fbdev and DRM. I don't think framebuffer devices were a consideration (let alone a factor either way) at all back in the days when this code was written... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
On Sat, 2005-05-28 at 20:07 +1000, Nik wrote: The folks at JOGL indicated the problem could be due to JOGL making extensive of threads. Does that sound like a good plasce to start the investigation, or would you suggest I just start tracing back from the exception? That's usually a good idea indeed. Beware that you should run gdb via ssh from a different machine as otherwise you'll lose control if execution stops while the hardware lock is held. -- 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 Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm_stub.c
On Fri, 2005-05-27 at 19:02 +0100, Alan Hourihane wrote:
Why does the mga_drv.c set DRIVER_REQUIRE_AGP when it doesn't 'require' it
if there's a PCI Matrox card ?
Couldn't we do
if (drm_device_is_agp(dev) || DRIVER_REQUIRE_AGP)
dev-agp = drm_agp_init(dev);
and remove DRIVER_REQUIRE_AGP from mga_drv.c ?
Oops, try again...
if (drm_device_is_agp(dev) || drm_core_check_feature(dev,
DRIVER_REQUIRE_AGP))
dev-agp = drm_agp_init(dev);
if (dev-agp == NULL)) {
DRM_ERROR(Cannot initialize the agpgart module.\n);
retcode = -EINVAL;
goto error_out_unreg;
}
Shouldn't it be:
if (drm_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
if (drm_core_check_feature(dev, DRIVER_REQUIRE_AGP))
{
if (dev-agp == NULL)) {
DRM_ERROR(Cannot initialize the agpgart module.\n);
retcode = -EINVAL;
goto error_out_unreg;
}
}
--
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 Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 2048x2048 texture corruption
On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: Hi, One more for good messure. 2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest is random data from memory. Not being familiar with the r300 code, I can only guess, but it sounds like the r300 driver still always uses a 1-byte format for texture uploads and hits the size limit of the 2D engine. This was changed for the other Radeon drivers when support for texture tiling was added. -- 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 Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] overflow(?) with ut2004 demo
On Tue, 2005-05-24 at 23:26 +0200, Rune Petersen wrote: Michel Dnzer wrote: On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote: Hi, When experimenting with UT2004 demo I get: DRM_RADEON_TEXTURE: return = -22 offset=0x04823000 image width=32 height=1024 blit width=1024 height=128 data=0xa6246200 It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. radeon_cp_dispatch_texture() also returns EINVAL in a number of other cases. Is there anything apropos in the kernel output? you are right (I managed to look at the wrong log). [drm:radeon_cp_dispatch_texture] *ERROR* Invalid destination offset So, possibly stating the obvious, there's basically two possibilities: Either the 3D driver indeed uses an invalid offset, or the DRM doesn't check correctly. Please provide some more information about your setup, in particular the exact versions of all the components (X, DDX driver, DRM, 3D driver, kernel, ...) and at least the log file of the X server. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote: I am thinking that there might be a bug where CP engine does something funny when the ring buffer is completely full. Maybe we need to keep a small chunk of space open so that start and end pointers are different. WPTR == RPTR means the ring is empty, if you mean that. The DRM handles that though, unless you made r300 specific changes to the ring handling. (I don't think that RBBM_STATUS would indicate the CP being busy in that case, anyway) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote: It is equally likely that the lockup is caused by, say, alignment or wraparound issues of the ring buffer. Note that fglrx always submits commands in indirect buffers, which are stored linearly in physical memory. We, on the other hand, always submit commands into the ring buffer, which is not linear (because it wraps around). Also, fglrx likes to emit NOPs into the command stream sometimes, though I haven't been able to find an exact pattern in those NOPs. We never emit NOPs (or do we?). So the fact is: We just don't know whether alignment/wraparound can cause trouble. The emission of NOPs by fglrx is IMO significant evidence that there *are* issues in this area, at least on some chipsets, but it could just be some weird artifact of the fglrx codebase. The NOPs in the ring buffer are there for alignment/performance reasons, they shouldn't affect lockups either way. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Wed, 2005-05-25 at 15:06 -0400, Vladimir Dergachev wrote: On Wed, 25 May 2005, Michel [ISO-8859-1] Dnzer wrote: On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote: I am thinking that there might be a bug where CP engine does something funny when the ring buffer is completely full. Maybe we need to keep a small chunk of space open so that start and end pointers are different. WPTR == RPTR means the ring is empty, if you mean that. The DRM handles that though, unless you made r300 specific changes to the ring handling. (I don't think that RBBM_STATUS would indicate the CP being busy in that case, anyway) No there are no R300 specific modifications as far as I know. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? You mean that you think you've written a complete (set of) command(s), but the CP interprets it differently? That would be possible I think, but again, do you emit any r300 specific commands to the ring? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Wed, 2005-05-25 at 16:11 -0400, Vladimir Dergachev wrote: WPTR == RPTR means the ring is empty, if you mean that. The DRM handles that though, unless you made r300 specific changes to the ring handling. (I don't think that RBBM_STATUS would indicate the CP being busy in that case, anyway) No there are no R300 specific modifications as far as I know. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? You mean that you think you've written a complete (set of) command(s), but the CP interprets it differently? That would be possible I think, but again, do you emit any r300 specific commands to the ring? What do you mean by r300 specific ? Anything that isn't used for pre-R300 chips as well, as those don't seem to suffer from the same kind of lockups. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] overflow(?) with ut2004 demo
On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote: Hi, When experimenting with UT2004 demo I get: DRM_RADEON_TEXTURE: return = -22 offset=0x04823000 image width=32 height=1024 blit width=1024 height=128 data=0xa6246200 It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. radeon_cp_dispatch_texture() also returns EINVAL in a number of other cases. Is there anything apropos in the kernel output? -- 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 Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Mon, 2005-05-23 at 10:10 +0300, Aapo Tahkola wrote: On Sun, 22 May 2005 21:00:19 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: I setup a x86 with radeon 9800 pro or xt, trying to find why it locks. I see little improvement with option no silken mouse can you test and tell me if it dones anythings for you (X -nosilk). Try attached patch against radeon_cursor.c if you can. I doubt that actually fixes it because swcursor should of done that... CURSOR_SWAPPING_START() already syncs the engine in current X.Org HEAD, and wait for idle is useless to harmful in the cursor position functions, at least with silken mouse. So the only thing that could make a difference is the wait for idle before showing or hiding the cursor (which BTW is superfluous in the LoadCursorImage functions, the X server explicitly hides the cursor before and shows it again after those). -- 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 Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Sun, 2005-05-22 at 21:00 +0200, Jerome Glisse wrote: I setup a x86 with radeon 9800 pro or xt, trying to find why it locks. I see little improvement with option no silken mouse can you test and tell me if it dones anythings for you (X -nosilk). My thought on this lockups is that it's similar to the one r200 users report, X taking 100% of CPU waiting for something. I saw a mail from Felix about a lock holding issue will try to dig in mail archive. Those are common symptoms of a lockup. The same symptoms aren't necessarily due to the same cause though. Anyone have any idea on that ? Could it be the mouse code in xorg ? Or is it in r300_mesa or drm ? Most likely IMO. -- 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 Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote: 1) When I move a window over a 3D rendering window the contents jumps to the top left hand part of the display. If I move the output (say the glxgears) window to the top left I see the output centred at the screen edge, otherwise the window is blank. When the window moved around the output correctly appears in the window. I haven't seen this, but it sounds like it might be related to today's ABI-backwards-compatibility-breaking change to the X.org libdri module. If you have that, make sure everything was rebuilt correctly according to it. 4) UseFBDev results in the following error and failed initialisation: (EE) RADEON(0): FBIOPUT_VSCREENINFO: Invalid argument Either you aren't running radeonfb, or it probably doesn't like the mode. In the latter case, maybe there's something interesting in the kernel output. -- 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 Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRM GART mapping bogosity
On Tue, 2005-05-03 at 15:24 +1000, Benjamin Herrenschmidt wrote: The radeon DRM has some interesting bug that paul and I discovered to cause all sort of problems like crashing the machine on suspend/resume (go figure ...) etc... dev_priv-gart_vm_start = dev_priv-fb_location + RADEON_READ( RADEON_CONFIG_APER_SIZE ); The aim of this code is to setup the card memory map so that the GART sits just after the framebuffer. However, CONFIG_APER_SIZE is _not_ a good indication of the framebuffer size. Indeed, I apologize for this 'bogosity'. Seemed like a good idea at the time... CONFIG_APER_SIZE is only the size of the visible aperture on the PCI bus. Some setups (like some Macs for example) can use the dual split aperture mecanism, in which case CONFIG_APER_SIZE is only half of the VRAM. I can imagine cards overloaded with memory to have more vram that is directly accessible from PCI in other circumstances too (though the split aperture case is a real world scenario we encountered on paul's laptop at least). Yeah, cards with 256 MB of VRAM or more only have a 128 MB PCI aperture. So this fix might also help with the issues people have with such cards. In practice, you are setting up the card's memory map, so CONFIG_APER_SIZE should be totally irrelevant anyway since it only affects the PCI window to the vram. What is relevant here is CONFIG_MEMSIZE I would say... dev_priv-gart_vm_start = dev_priv-fb_location + RADEON_READ( RADEON_CONFIG_MEMSIZE ); If we want to be totally paranoid, we may want to use the max of CONFIG_MEMSIZE and CONFIG_APER_SIZE (to avoid leaving part of the GART mapped though the PCI aperture. Makes sense. Note that with huge VRAM sizes appearing, we also want to make sure that wheverver we put it won't overlap the 32 bits space since CONFIG_MEM_SIZE can be huge nowadays... and if it does, put the GART just _before_ the framebuffer instead. Again, this is all cards space, not bus view, so that shouldn't matter where we put these things. Another constraint is that the GART doesn't overlap with the bus address range of system RAM. -- 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: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRM GART mapping bogosity
On Tue, 2005-05-03 at 10:09 +0200, Jerome Glisse wrote: On 5/3/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Ok, I'm cross posting here because X.org is doing it wrong too. On R300, for some reason I don't fully understand, it just goes back to the old way of putting the FB at 0 I think that should be fixed as well, BTW. (though it does properly use CONFIG_MEMSIZE to set the size part of MC_FB_LOCATION), but for non R300, it does try to put the framebuffer at the same address as the BAR ... and then tries to use CONFIG_APER_SIZE for the size part of MC_FB_LOCATION, which is incorrect. The result is that on !r300, it won't crash since X.Org and DRI won't create an overlapping mapping, but they won't be able to use all of VRAM of some cards where CONFIG_APER_SIZE CONFIG_MEM_SIZE, and on r300, it will possibly create overlapping mappings and will cause all sorts of troubles if you get the above case. Has i still doesn't understand the big pictures of video drivers, i was wondering if this could have an impact on bytes swapping on r300. Thus the problem of bit blit we have on r300 X driver. I don't think so but as i don't well understand all this... No, the big endian hostdata blit issues with R300 class cards are strictly between the CP and the hostdata registers (as hostdata blits work as expected with MMIO) and not related to the framebuffer or the GART. -- 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: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRM GART mapping bogosity
On Wed, 2005-05-04 at 00:39 +1000, Benjamin Herrenschmidt wrote: Note that with huge VRAM sizes appearing, we also want to make sure that wheverver we put it won't overlap the 32 bits space since CONFIG_MEM_SIZE can be huge nowadays... and if it does, put the GART just _before_ the framebuffer instead. Again, this is all cards space, not bus view, so that shouldn't matter where we put these things. Another constraint is that the GART doesn't overlap with the bus address range of system RAM. Do we still care about that ? Do we ever do DMA from the card to system RAM outside of the AGP context ? Yes, e.g. for video capture (hence it's doubly surprising that the framebuffer location would be hardcoded to 0 for r300 ;). We should also use non-GART for the ring read pointer and scratch register writeback. I think a good strategy is to try to put the AGP aperture after the video RAM, and if that doesn't fit, just before. That would keep us high enough in most cases to avoid system RAM, but we can't guarantee 100% here. If a conflict can't be avoided, we could fail gracefully upfront (suggesting to make the GART aperture smaller, ...) instead of risking subtle breakage? -- 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: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRM GART mapping bogosity
On Wed, 2005-05-04 at 11:41 +1000, Benjamin Herrenschmidt wrote: Ok, here's a new patch that I'll send to Linus if you (Michel) acks it. I use CONFIG_MEMSIZE, I don't try to max out with CONFIG_APER_SIZE since I beleive we just don't care, and that avoids putting pressure on the GART location on configs that have a large aperture size. If the GART doesn't fit, I move it to below the framebuffer and print a warning. This is fine with me (what's the tag line for that again? :). The only thing is, that patch relies on CONFIG_MEMSIZE beeing a power of 2 I suppose... Is that always true ? It is for all the Radeons I know of, but maybe Hui knows of exceptions. -- 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: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200SE hangs
On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor wrote: On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dnzer wrote: Did you post the problems you encountered? Yes, on Mon, 14 Feb 2005. You were one of the recipients :)) There was a thread 'OpenGL apps causes frequent system locks' on dri-devel. I mean the problems compiling older snapshots. Define 'a simple X restart'. Do you mean running Descent 3 right after restarting the X server? Issued startx, exited X. Issued startx again, started D3, played for a while. But it doesn't happen if you only start the X server once? I wrote my step-by-step test in one of the mails I sent to this thread. I don't see that in your other post to *this* thread. Do you mean the thread you started months ago? Nowadays I have to switch to the microwave gun and fire some dozen waves to crash X. It's 100% reproducible, so I offered my help to create gdb backtraces, but one of the DRI developers (Michael Daenzer, if I remember correctly) pointed out that gdb backtraces won't help diagnosing GPU lockups. Yeah, but maybe he was thinking of DRM debugging output or something. That can be useful, but is still tedious to wade through in the best case. Nice to see that you refer to yourself in 3rd person :)) No, I was referring to the part of the post that started this thread that I quoted just above what you quoted here. If I can help with backtraces/ debug info, don't hesitate, tell me, what kind of information are you interested in! If you can reproduce the problem with DRM debugging output enabled, send the output, e.g. But don't put your hopes too high, this is highly non-trivial stuff. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Radeon 9800 Pro lockups
On Thu, 2005-04-14 at 13:36 -0400, Jonathan Bastien-Filiatrault wrote: I have tried the experimental r300 driver with my Radeon 9800 Pro. The rendering speed and accuracy are simply amazing. Unfortunately, I am getting random lockups about every five minutes. The Xorg process takes 100% CPU and I have to reboot to get the graphics card in a usable state. The OS besides that seems to be unnafected. If I move the mouse, it locks up in a matter of seconds. Could anyone give me pointers/test cases to help debug this ? It seems that fixing this lockup would be the last little step to have working free software drivers for the ATI Radeon line. Can you try if reverting revision 1.6 of radeon_cursor.c in X.org CVS makes a difference? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Wed, 2005-03-16 at 15:35 -0500, Vladimir Dergachev wrote: On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dnzer wrote: Disclaimer: I don't pretend to understand 100% how all this stuff works either, but I think my understanding has improved a little recently. :) Michel, I think we are misunderstanding each other. I am not talking about synchronization of drawing operations, I am talking about hardware limitations. So am I. I am quite certain, that, at least on mach64 hardware, an attempt to access framebuffer by CPU while the GUI engine is active will result in a hard lockup. If this was true with Radeons, you'd get a lockup every time the hardware cursor shape changes. I guess the memory controller has improved... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjl wrote: I don't see the current system slowly evolving into some superb future system with an in kernel memory manager. The current APIs just have too many limitations. I think the memory manager must be the foundation of everything and after it's in place the fbdev API should be able to use it. The only change to simple fbdev apps would be that they can't get access to any offscreen memory as they do now. Something like DirectFB would need to change to accomodate the new system but I don't see that as a problem. I agree on this. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. Either way, this is hardware specific, so it will probably have to be handled by the hardware driver(s) somehow. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 2005-03-17 at 10:28 +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 16:00 -0500, Michel Dnzer wrote: On Wed, 2005-03-16 at 21:51 +0200, Ville Syrjl wrote: One thing just popped to my head though. If in the future we are going to allow graphics cards to render to system memory, using the swapper will no longer work. I don't see any other solution that having the CPU perform the byte swapping. Sane hardware should have a way to deal with this as well. Either way, this is hardware specific, so it will probably have to be handled by the hardware driver(s) somehow. Of course, and radeonfb is what if not a hardware driver ? Who said it was anything else? Is radeonfb gonna handle the offscreen surfaces though? My point was that the hardware driver(s) should be involved in the decision on what format/byte order/... should be used for a surface, instead of just hardcoding fixed formats and having the CPU do possibly unnecessary byte swapping. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote: So can we be sure that one can do arbitrary INREG() on Radeons without fear of lockup ? I think so, in general. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 12:30 +0100, Roland Scheidegger wrote: Ville Syrjl wrote: I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. I'm not sure I agree here, as it's not always true. For instance, the radeon has some restrictions whether it can use tiling or not with a certain mode (interlace/double scan) thus you need to redraw everything anyway (which is exactly why I implemented a driver workaround to repaint everything when that happens - in fact the workaround also gets rid of the offscreen contents, which is not necessary, but was much easier to implement, since I couldn't find an easy way to invalidate the framebuffer). What's the big deal with repainting everything? It's not like you would do 100 mode changes per second so it would be performance-critical... It's ugly, but that's not the point. The point is that all deployed versions of X (and even current X.org CVS head still, in fact) make this assumption. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] New DRIconf version 0.2.3
On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote: I added to the Installation instructions: Packages are available for Linux distributions utilizing RPM package management in the Download section. We currently do not have Debian packages available. If you are interested in the role of Debian package manager for this project please send an e-mail to the dri-devel mailing list. Actually, I've had driconf 0.2.2 packages at deb http://people.debian.org/~daenzer/dri-trunk-sid/./ for over a year, but anybody is welcome to pick that up. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D driver returned no fbconfigs, InitDriver failed
On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote: I just installed the latest snapshot of the radeon DRI driver from http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2. Installation went without problems, but direct rendering is disabled. output of 'dmesg': [drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies Inc RV250 5c61 [Radeon Mobility 9200 M9+] You need an r200 snapshot for that card. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote: On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: This would mean that on r300 this fix is not needed, but rv350 locks up without it. In that case perhaps it makes sense to only wait for idle on rv3xx. I don't know if it makes sense to break one setup to fix another. Certainly not, but I don't think the wait for idle makes sense in the first place. There is no rule that you have to wait for idle before reading a register, and the fglrx driver doesn't do anything like that. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Wed, 2005-03-16 at 10:33 +1100, Benjamin Herrenschmidt wrote: Now, I agree that cutting the vram in half, and reserving both halves to the offscreen needs to each head may help avoiding mode switch on one head busting things used by whoever works on the second head, but I'm not sure that fits the DRM needs very well.. It probably doesn't, but it seems to me like that's all that can be done with the current fbdev API. On Wed, 2005-03-16 at 12:51 +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjl wrote: There's also the case with Matrox Millennium I/II cards. They must place the visible frame buffer so that no line crosses the boundary of memory banks. [...] That still doesn't require any changes on mode switches as long as the pitch stays the same, does it? So it alls end up to - mode switch has to bust memory layout, [...] Why? All that a mode switch changes is how the current screen surface is scanned out. It shouldn't have any implicit effect on memory allocation or even contents. [...] For that to work, it also requires proper arbitration though, so we may end up again limit that functionality to clients using the DRM for artbitration and lock everything when some guy like DirectFB enters the picture. I was thinking about something like that as well, may be the only way to preserve the current fbdev API and offer something more sophisticated. and because it seems that directFB has only been tested on little endian machines (damn them !) and thus doesn't understand the problem with swapper on framebuffer access). Actually people do use it on big-endian systems but since neither the mach64, ati128 or radeon drivers play with the swapper settings I can only assume that they haven't been tested very extensively. You are wrong here, all of those 3 drivers do play with the swapper setting, [...] I think he was referring to the DirectFB drivers. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D driver returned no fbconfigs, InitDriver failed
On Wed, 2005-03-16 at 00:17 +0100, Richard Stellingwerff wrote: Anyway, the driver works, but it's VERY unstable for me. If you're using MergedFB (which includes clone mode), see the current thread '[r200] Lockups...'. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Disclaimer: I don't pretend to understand 100% how all this stuff works either, but I think my understanding has improved a little recently. :) On Tue, 2005-03-15 at 20:07 -0500, Vladimir Dergachev wrote: On Tue, 15 Mar 2005, Vladimir Dergachev wrote: My understanding was that for MMIO-only access: * Check that FIFO is not full before writing This one is obvious (for FIFO'd registers). :) * Check that GUI engine is idle before accessing framebuffer Technically you'd only have to make sure that the engine isn't operating on the same 'area' as the CPU I think, but waiting for idle is usually a good way to be on the safe side here. * Check that FIFO is empty before reading a register Forgot the forth one: some registers bypass the FIFO, so WaitForIdle for them is not necessary. The FIFO doesn't apply to reads. It only applies to some register writes, basically the ones where queueing makes sense, i.e. mostly to acceleration related registers. I have yet to see a 'wait for idle' rule for register access anywhere. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote: glxgears usually runs fine till I move the mouse... The mouse will stutter. I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir added to RADEONChooseCursorCRTC() on February 18th. I think this function will be called asynchronously, so the hardware lock isn't held, and another client can keep the engine busy long enough for RADEONWaitForIdleMMIO() to time out, in which case it will try to reset the chip, still without the lock, which would explain the kernel messages about radeon_cp_reset. This is also more likely to happen with SMP, so I think it matches your observations pretty well. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon, apertures memory mapping
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote: On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote: On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote: And finally, I want to blank the screen (using the accel engine) before setting the new mode, so that we come out clean of the mode setting (without ugly artifact), and I will probably clean both fb's (simpler). That would break X with UseFBDev. How so ? X assumes that the framebuffer (as in video RAM) contents are preserved on mode switches. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote: Michel Dnzer wrote: On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote: glxgears usually runs fine till I move the mouse... The mouse will stutter. I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir added to RADEONChooseCursorCRTC() on February 18th. I think this function will be called asynchronously, so the hardware lock isn't held, and another client can keep the engine busy long enough for RADEONWaitForIdleMMIO() to time out, in which case it will try to reset the chip, still without the lock, which would explain the kernel messages about radeon_cp_reset. This is also more likely to happen with SMP, so I think it matches your observations pretty well. :) Woohoo. We have a likely culprit. Vladimir, does that make sense to you? Well, have you tried removing the call? Does it fix your problems? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon, apertures memory mapping
On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote: On Mon, 2005-03-14 at 11:20 -0500, Michel Dnzer wrote: On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote: On Sun, 2005-03-13 at 23:28 -0500, Michel Dnzer wrote: On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote: And finally, I want to blank the screen (using the accel engine) before setting the new mode, so that we come out clean of the mode setting (without ugly artifact), and I will probably clean both fb's (simpler). That would break X with UseFBDev. How so ? X assumes that the framebuffer (as in video RAM) contents are preserved on mode switches. Which I consider bogus :) Oh well... does it do a lot of other crappy assumptions like that ? What if I just can't allocate it and decide to put it elsewhere in vram ? (unlikely with my current scheme but possible). X needs to be fixed. Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote: I am unsure of how to fix it though, as the call *is* needed, we should not be reading from registers with engine busy. Something may be needed, but probably not a wait for idle (which may never succeed on an SMP system). Other things you could try: * Keep track of the hardware state in the driver, so you don't have to read the registers all the time. * Read/write the registers via MM_INDEX/MM_DATA instead of directly. I'm curious if either of this helps. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote: Be that as it may, it remains a fact that such a change would break existing installations... I think that mode setting and memory allocation should be separated. X will always reserve enough video RAM for the largest resolution it uses for the screen contents. But X has no control on where fbdev will allocate memory. My understanding is that so far, the fbdev API has pretty much implied that any mode scans out the beginning of the memory accessed via the framebuffer device, unless the panning ioctl is used. IIRC at least DirectFB makes basically the same assumptions as X there. We are thinking with the new model in mind, and so far, a mode setting is under control of the framebuffer. Content of video memory (framebuffer, textures, overlay, whatever) simply cannot be considered as preserved accross mode switches. We can't also block all evolutions just because we have to support a broken model. I'm not suggesting that, but I do think that tying together mode switching and memory allocation would be a big mistake. The EGL API for this is currently being discussed on the dri-egl list (http://lists.freedesktop.org/mailman/listinfo/dri-egl), you may want to join in there. We'll need to find a way to deal with that. An idea would be for me to do the clearing only when I come from a different bit depth or from text mode. That is, what i want to avoid, is those artifacts caused by incorrect bit depth content. A strict mode change isn't an issue in this case. That would solve my immediate problem. Sounds good. _BUT_ in the long run, X will have to be smarter. Current UseFBDev or X fbdev can't support dual head properly on top of fbdev anyway, Agreed for UseFBDev, but what's the problem with fbdev? But until all clients are DRI clients, we have a problem. Keep in mind that basically the only driver-independent API exposed by the DRI is OpenGL, so I'm afraid it's unlikely that all fbdev applications will take that route. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: radeon, apertures memory mapping
On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote: And finally, I want to blank the screen (using the accel engine) before setting the new mode, so that we come out clean of the mode setting (without ugly artifact), and I will probably clean both fb's (simpler). That would break X with UseFBDev. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Sat, 2005-03-12 at 14:30 -0500, Adam K Kirchhoff wrote: When trying neverputt: [drm] Loading R200 Microcode [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner da0fcd80 d2809b80 Weird, does this only happen when running a 3D client, or also without? irq 16: nobody cared! [c0135a1a] __report_bad_irq+0x2a/0xa0 [c0135380] handle_IRQ_event+0x30/0x70 [c0135b20] note_interrupt+0x70/0xb0 [c01354f3] __do_IRQ+0x133/0x140 [c0104d09] do_IRQ+0x19/0x30 [c010320e] common_interrupt+0x1a/0x20 [c01006d3] default_idle+0x23/0x30 [c010077f] cpu_idle+0x5f/0x70 [c03e89b8] start_kernel+0x188/0x1d0 [c03e8390] unknown_bootoption+0x0/0x1e0 handlers: [f8966c00] (usb_hcd_irq+0x0/0x70 [usbcore]) [f8966c00] (usb_hcd_irq+0x0/0x70 [usbcore]) [f8bcd220] (radeon_driver_irq_handler+0x0/0xc0 [radeon]) Disabling IRQ #16 IRQ 16 happens to be the irq being used by the radeon driver, of course :-) [ [EMAIL PROTECTED] - ~ ]: cat /proc/interrupts [...] 16: 28908 0 0 0 IO-APIC-level uhci_hcd, uhci_hcd, [EMAIL PROTECTED]::01:00.0 Was it always shared with the USB controller? Can you try changing that? Mind you, the hardware hasn't changed from before, when I had the 9200 in this machine... In fact, even after reinstalling debian, I did have the 9200 working, but (stupidly) with the drm source from the r300_driver tree. It worked, no lockups, but huge texture problems... Sounds like there could be problems with Paul's texture upload changes. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Sat, 2005-03-12 at 23:52 +0100, Jerome Glisse wrote: Sounds like there could be problems with Paul's texture upload changes. Paul patch doesn't make its way to 2.6.11 ? Because Adam says he gots the same prob with 2.6.11 right ? You removed the context this was referring to: [...] I did have the 9200 working, but (stupidly) with the drm source from the r300_driver tree. It worked, no lockups, but huge texture problems... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM texture dispatch using BITBLT_MULTI
On Fri, 2005-03-11 at 23:02 +1100, Paul Mackerras wrote: Michel Dnzer writes: The difference is that for a hostdata blit, the CP writes the data to the hostdata registers synchronously, whereas with your change, the 2D engine will fetch the data asynchronously. What do you think of this patch? I have added a wait command after the blit, which I believe should make the CP wait until the blit is done before writing the buffer age scratch register. Yes, that looks good. I also made it set the source pitch based on the image width. If the image width is less than 64, we have a problem if the image height is more than 1 (if the height is 1 the pitch doesn't matter). I made it return an EINVAL error in that case. I didn't see that case ever occurring, at least with the r300 driver. Looks good to me as well, if this error gets triggered by the other drivers, we can always deal with that. I'll defer to Roland for whether this is fine for texture tiling though. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM texture dispatch using BITBLT_MULTI
[ Please don't top-post ] On Wed, 2005-03-09 at 10:38 +0100, Jerome Glisse wrote: I don't think this will change anything for x86 setup. Yeah, the real question is whether it breaks pre-R300 chips on big endian machines, but it looks fine to me. Moreover could this change also affect way X do bitblit with xrender acceleration ? No, as I explained to you before, the X driver has to deal with different byte orders because the X server doesn't provide the data in little endian. On Wed, 9 Mar 2005 11:24:02 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I started looking into the issue of how we handle various texture formats on R300 on big-endian machines. It became evident that textures were getting byte-swapped on their way to the framebuffer. Yep, the comment the patch removes explains this. :) We can cope with the byte-swap for textures with 4 bytes/texel, but not for textures with 2 or 1 byte/texel. So instead of using a HOSTDATA_BLT in radeon_cp_dispatch_texture, I changed it to use a BITBLT_MULTI. I still copy the texture into gart memory, but instead of using an indirect buffer I just put the blit command into the ring buffer. Nice. It might also be interesting to experiment with copying the texture data into the ring itself instead of into indirect buffers (and use type 3 NOP packets to have the CP skip it), if someone feels so inclined. This avoids the byte swap that the CP does and gets the texture to the framebuffer without being byte-swapped. It should be just as fast this way as with the HOSTDATA_BLT. Yeah, it might actually be slightly faster. :) + OUT_RING((texpitch 22) | (offset 10)); + OUT_RING((texpitch 22) | (tex-offset 10)); Are source and destination pitch always the same? + OUT_RING(0); + OUT_RING((image-x 16) | image-y); + OUT_RING((image-width 16) | height); + ADVANCE_RING(); + radeon_cp_discard_buffer(dev, buf); I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer might get reused before the blit is complete. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM texture dispatch using BITBLT_MULTI
On Thu, 2005-03-10 at 09:10 +1100, Paul Mackerras wrote:
Michel Dnzer writes:
Nice. It might also be interesting to experiment with copying the
texture data into the ring itself instead of into indirect buffers (and
use type 3 NOP packets to have the CP skip it), if someone feels so
inclined.
Just to avoid the overhead of allocating an indirect buffer?
Yes.
I think that could be worthwhile for smaller textures,
Not only; with large textures, you might avoid having to wait for an
indirect buffer to become available, the ring size might have to be
increased for that though.
although for smaller textures it would probably be just as fast, and a
lot simpler, to write the texture directly to the framebuffer.
Possibly, but that has the disadvantage of not being synchronized with
the GPU.
I assumed that the indirect buffer would be at least 1kB-aligned
(indirect buffers seem to be page-aligned, from what I could see in
the code that creates them). This means that I didn't have to worry
about losing bits when shifting buf-offset right 10 bits. We
wouldn't have that guarantee if we were putting the texture in the
ring buffer, which might make calculation of suitable x and y values
interesting. :)
The data can be aligned in the ring as well, but that's indeed an issue.
I'm really not sure this would be worth it though, hence my choice of
words: 'might be interesting to experiment'... :)
+ OUT_RING((texpitch 22) | (offset 10));
+ OUT_RING((texpitch 22) | (tex-offset 10));
Are source and destination pitch always the same?
I found it quite hard to understand what was going on with tex-width,
tex-height and tex-pitch vs. image-width and image-height, since
they seem to be used inconsistently. It turns out that in fact
tex-pitch isn't actually the pitch of the texture image - it can be a
power of two multiple of the actual texture pitch.
I think tex-pitch is the value that will be written to the texture
pitch register. My (limited) understanding of the other fields is
tex-{width,height}: texture width/height
image-width: source data pitch
image-height: source data height
By the time the data gets to the indirect buffer it is laid out as we
want it in the framebuffer, though, [...]
Really? The texture pitch in the framebuffer is always a multiple of 1024
bytes AFAIK (I might be way off though :), so that would be a royal waste
of bandwidth in some cases.
I agree this is pretty confusing though, clues appreciated. :)
+ OUT_RING(0);
+ OUT_RING((image-x 16) | image-y);
+ OUT_RING((image-width 16) | height);
+ ADVANCE_RING();
+
radeon_cp_discard_buffer(dev, buf);
I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer
might get reused before the blit is complete.
Well, radeon_cp_dispatch_indirect doesn't seem to wait for the blit to
complete either, so I was just following what the old code did.
The difference is that for a hostdata blit, the CP writes the data to
the hostdata registers synchronously, whereas with your change, the 2D
engine will fetch the data asynchronously.
I must admit I don't yet understand how indirect buffers get recycled.
The DRM keeps track of a monotonously increasing 'buffer age'. When an
indirect buffer gets discarded, the DRM increments the buffer age and
associates the discarded buffer with the incremented age. It emits
commands for executing the indirect buffer to the ring buffer, followed
by a write to a reserved scratch register. The DRM knows it can reuse
indirect buffers whose associated age is smaller than or equal to the
age in that register.
Now with hostdata blits, this doesn't require special treatment, because
the scratch register is only written to after the CP is done feeding the
data to the hostdata registers. But with your change, the scratch
register will be written immediately after the 2D engine starts fetching
the data from the indirect buffer. There might still only be conflicts
rarely if ever in practice, but it's probably better not to take any
chances. :)
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'texdown' - 'b' sigfault back trace
On Wed, 2005-02-16 at 21:16 +0100, Dieter Ntzel wrote:
#0 _tnl_build_vertices (ctx=0x8060928, start=0, end=0, newinputs=0)
at tnl/t_vertex.c:1379
1379 a[j].inputstride = vptr-stride;
(gdb) list
1374 const GLuint count = vtx-attr_count;
1375 GLuint j;
1376
1377 for (j = 0; j count; j++) {
1378 GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
1379 a[j].inputstride = vptr-stride;
1380 a[j].inputptr = ((GLubyte *)vptr-data) + start *
vptr-stride;
1381 a[j].emit = a[j].insert[vptr-size - 1];
1382 }
I see a similar crash in gliv. Looks like it could be more cases of
'software fallbacks are broken'.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200]Problems with HW TCL in Tuxracer and PPRacer
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote: Michel Dnzer wrote: On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote: When using HW TCL in Tuxracer or PPRacer (that is essentially the same game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you can see that there are problems with light reflection in those places where there's ice (for example in the first stage that is full of ice pools ) . You mean the flickering? That's probably Z fighting, most likely a problem in the game itself. You should bring this up with the PPRacer project, now that there's active development there... No, this is a result of the tcl fallback used for the GL_SPHERE_MAP texgen (it is z fighting I guess). Sure, but Brian told me the application has to be prepared for and deal with this. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote: if ( (info-ChipFamily == CHIP_FAMILY_R300) || (info-ChipFamily == CHIP_FAMILY_R350) || - (info-ChipFamily == CHIP_FAMILY_RV350) ) + (info-ChipFamily == CHIP_FAMILY_RV350) || + (info-ChipFamily == CHIP_FAMILY_R420) ) drmInfo.func = DRM_RADEON_INIT_R300_CP; else if ( info-ChipFamily = CHIP_FAMILY_R200 ) Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of for every R300 family explicitly? Otherwise, it looks like the R200 microcode will be used, which is certainly wrong... Incidentally, I think the R300 check in RADEONDRIScreenInit() should be moved to the top as well, or the IGP and R200 checks will preempt it? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Fri, 2005-03-04 at 13:53 -0500, Vladimir Dergachev wrote:
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote:
if ( (info-ChipFamily == CHIP_FAMILY_R300) ||
(info-ChipFamily == CHIP_FAMILY_R350) ||
- (info-ChipFamily == CHIP_FAMILY_RV350) )
+ (info-ChipFamily == CHIP_FAMILY_RV350) ||
+ (info-ChipFamily == CHIP_FAMILY_R420) )
drmInfo.func = DRM_RADEON_INIT_R300_CP;
else
if ( info-ChipFamily = CHIP_FAMILY_R200 )
Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of
for every R300 family explicitly? Otherwise, it looks like the R200
microcode will be used, which is certainly wrong... Incidentally, I
think the R300 check in RADEONDRIScreenInit() should be moved to the top
as well, or the IGP and R200 checks will preempt it?
I was afraid that R300 microcode would not work for newer cards as my
understanding of it is somewhat limited. Do you think it would be safe to
load an older microcode to a newer card ?
No, as I said above.
Upon a closer look it appears that this part only affects the choice of
the microcode, so in a way, your suggestion would avoid loading the really
old Radeon microcode.
Yes, this code only decides between the supported microcode versions. If
there will be any chips in the future for which neither of the current
choices work, the DRI will likely have to be disabled for them anyway.
As for DRIScreenInit - I looked at the code again and its logic appears
correct to me, could you elaborate a bit where you would like the R300
check to appear ?
if (info-IsIGP) {
req_minor = 10;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R200) {
req_minor = 5;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R300) {
req_minor = 12;
req_patch = 0;
} else {
The IGP and R200 cases will match before the R300 case. The order should
be from highest to lowest required DRM version.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200]Problems with HW TCL in Tuxracer and PPRacer
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote: When using HW TCL in Tuxracer or PPRacer (that is essentially the same game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you can see that there are problems with light reflection in those places where there's ice (for example in the first stage that is full of ice pools ) . You mean the flickering? That's probably Z fighting, most likely a problem in the game itself. You should bring this up with the PPRacer project, now that there's active development there... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] DRM perturbation
On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote: I think long term though, a better solution would be to get rid of mergedfb and handle each head separately but just change the 2d/3d engines offsets depending on which head you are rendering to. then you wouldn't have to worry about the limits so much (although some of these new super hi-res LCDs would still need some work). Yep, and as a bonus you'll have to solve basically all of the issues of multi-card Xinerama. If there's a benefit to that (other than making the exotic multi-card Xinerama possible or at least easier), I'm afraid I don't see it. Fixing the remaining MergedFB issues seems much easier and more useful to me. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200] Nearly all xscreensavers GL flicker
[ Please don't follow up just to me privately ] On Thu, 2005-02-24 at 14:26 +0100, Marcello Maggioni wrote: On Wed, 23 Feb 2005 23:02:37 -0500, Michel Dnzer [EMAIL PROTECTED] wrote: On Wed, 2005-02-23 at 20:50 +0100, Marcello Maggioni wrote: I've a problem with lastest DRI (from CVS) drivers and Xscreensavers that use OpenGL. I've tried nearly all of them , from Bubble 3D to Rubik Cube all these simply flicker like hell when are executed . If you're running them manually with -root, it's probably because the root window isn't double buffered. Otherwise, does disabling colour tiling or page flipping make a difference? I run them from KDE Control Center [...] IIRC some versions of KDE are known to be buggy in this regard. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 flickering
On Fri, 2005-02-25 at 19:08 +0200, Boris Peterbarg wrote: I've noticed something weird about the flickering I get with r300. Normally any 3d program or game flicker when I run them. I tried running a windows game under the latest wine - Babylon 5: I've Found Her (http://ifh.firstones.com). The game killed wine very close to it's start, but afterwards I didn't get any flickering at all. Also, glxgears reported a frame rate of about 2750, while with flickering it was about 3400. I might be way off here, but if you have page flipping enabled, try disabling it. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200] Nearly all xscreensavers GL flicker
On Wed, 2005-02-23 at 20:50 +0100, Marcello Maggioni wrote: I've a problem with lastest DRI (from CVS) drivers and Xscreensavers that use OpenGL. I've tried nearly all of them , from Bubble 3D to Rubik Cube all these simply flicker like hell when are executed . If you're running them manually with -root, it's probably because the root window isn't double buffered. Otherwise, does disabling colour tiling or page flipping make a difference? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRI locks up XOrg 6.8.2
On Tue, 2005-02-15 at 22:36 +, Chris Rankin wrote: By the power of my serial console, here is what gdb says about my crazy celestia-1.3.2 process: Just one of many possible symptoms of a GPU lockup I'm afraid. Does commenting out Option AGPMode make a difference? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon/r200 texture swapping bits..
On Tue, 2005-02-15 at 11:47 +, Dave Airlie wrote: I'm thinking about how these could be used in Mesa drivers? would I be correct in thinking the fallbacks would mess up as the Mesa copy of the texture wouldn't be the same as what the card would be using? I'm not sure that the fallbacks in their current form ever actually read from the on-card texture memory. No the onboard memory or GART copy would be the same as the copy Mesa keeps, the only difference would be the bit in the register would mean the chip would auto-swizzle when it is reading the texture... so if I have an RGBA and set the bit the radeon will treat it like a ABGR but not actually change any copies of it.. so in terms of operations on the texture the fallback would work on a RGBA, the chip operations on ABGR Note that at least for this example, you don't need the endianness bits at all, as you can just choose the RGBA vs. ABGR hardware formats. It might also be possible to fix up the byte order during the upload blit, but I guess you may be trying to get rid of that for the GART... Way back when I was fixing the r128 driver for PPC, I bumped into problems like alignment issues with higher mipmap levels when I tried to use the texture endianness bits, in particular with 16 bit textures. That's why I figured it was easiest to always have Mesa provide texture data in little endian. I don't know if those issues still apply to your scenario or even in general though. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote: AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. Have you tried idling the engine before uploading the cursor data? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 2005-02-15 at 11:36 -0500, Vladimir Dergachev wrote: On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote: AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? It arguably should, but it doesn't AFAICT. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 2005-02-15 at 12:08 -0500, Vladimir Dergachev wrote: Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? It arguably should, but it doesn't AFAICT. That's what I thought when I encountered this last, however, both radeon and r200 drivers work fine [...] There's this thing called luck... let's rule out the obvious suspects before worrying about more complex stuck. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Mesa CVS text and texture bug
On Mon, 2005-02-14 at 20:06 +0100, Dieter Ntzel wrote: dmesg show this: agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 2x mode agpgart: Putting AGP V2 device at :01:05.0 into 2x mode glxinfo OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.3 So only AGPGART output is wrong? Rather the other way around. Usually, this means either the AGP bridge or the card don't actually support more than 2x. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon DRI locks up XOrg 6.8.2
On Mon, 2005-02-14 at 22:27 +, Chris Rankin wrote: I have a Radeon 9200 AGP card, and have manually compiled XOrg 6.8.2 for my dual P4 Xeon (with hyperthreading enabled) Linux 2.6.10 system. However, I am finding that the Xserver locks up when I run celestia 1.3.2 with hardware acceleration at full screen, 1280x1024. I have tried both the latest linux-core and linux-2.6 radeon DRI modules from CVS at dri.freedesktop.org, with similar results. (The linux-core crashed faster.) Basically, the Xserver sits and spins on one CPU and can't be killed. XOrg 6.8.1's server seems to be a lot more resilient, and so I have reverted to using it. Try removing the RADEONSetFBLocation() call in RADEONAdjustFrame(). That's a messup which I unfortunately discovered only too late for 6.8.2. http://lists.freedesktop.org/archives/xorg/2005-February/006126.html -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Snapshot build failed]
On Sun, 2005-02-13 at 18:38 +0100, Felix Khling wrote: r200_screen.c: In function `r200CreateScreen': r200_screen.c:407: error: `addr' undeclared (first use in this function) Whoops, my bad, should be fixed now. I wonder how that built for me... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote: On Sat, 2005-02-12 at 23:56 -0500, Michel Dnzer wrote: On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote: Those are still incorrect as they totally lack memory barriers... INREG() doesn't (or does it?), and it's the only one used by the 3D drivers. Hrm.. in fact, you are always writing to indirect buffers here, right ? If this is true, all you need is a barrier between the last store to it and whatever store makes the buffer visible to the chip. If you use only uncached access (like AGP GART), then only an eieio is necessary, Yes, the DRM does this, always has... but if you use PCI GART which works with a cacheable mapping in main memory, you probably need a full sync. Hasn't seemed necessary all these years. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Sat, 2005-02-12 at 13:03 +0100, Jerome Glisse wrote:
Could anyone apply this patch if it looks good.
This correct the problem many ppc user have
using the Mesa-dri cvs which does not do the
swapping for bendian.
The code came from Michel, i am only doing
the patch and the #ifdef things :)
How about something like this instead?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Index: src/mesa/drivers/dri/radeon/server/radeon_macros.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/server/radeon_macros.h,v
retrieving revision 1.2
diff -p -u -r1.2 radeon_macros.h
--- src/mesa/drivers/dri/radeon/server/radeon_macros.h 6 Aug 2003 18:11:00 - 1.2
+++ src/mesa/drivers/dri/radeon/server/radeon_macros.h 12 Feb 2005 17:40:48 -
@@ -40,28 +40,22 @@
#ifndef _RADEON_MACROS_H_
#define _RADEON_MACROS_H_
-
+#include mmio.h
# define MMIO_IN8(base, offset) \
*(volatile unsigned char *)(((unsigned char*)(base)) + (offset))
-# define MMIO_IN16(base, offset) \
- *(volatile unsigned short *)(void *)(((unsigned char*)(base)) + (offset))
# define MMIO_IN32(base, offset) \
- *(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset))
+ read_MMIO_LE32(RADEONMMIO, addr)
# define MMIO_OUT8(base, offset, val) \
*(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) = (val)
-# define MMIO_OUT16(base, offset, val) \
- *(volatile unsigned short *)(void *)(((unsigned char*)(base)) + (offset)) = (val)
# define MMIO_OUT32(base, offset, val) \
- *(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset)) = (val)
+ *(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset)) = CPU_TO_LE32(val)
/* Memory mapped register access macros */
#define INREG8(addr)MMIO_IN8(RADEONMMIO, addr)
-#define INREG16(addr) MMIO_IN16(RADEONMMIO, addr)
#define INREG(addr) MMIO_IN32(RADEONMMIO, addr)
#define OUTREG8(addr, val) MMIO_OUT8(RADEONMMIO, addr, val)
-#define OUTREG16(addr, val) MMIO_OUT16(RADEONMMIO, addr, val)
#define OUTREG(addr, val) MMIO_OUT32(RADEONMMIO, addr, val)
#define ADDRREG(addr) ((volatile GLuint *)(pointer)(RADEONMMIO + (addr)))
Index: src/mesa/drivers/dri/common/mmio.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/mmio.h,v
retrieving revision 1.2
diff -p -u -r1.2 mmio.h
--- src/mesa/drivers/dri/common/mmio.h 14 Dec 2004 09:11:52 - 1.2
+++ src/mesa/drivers/dri/common/mmio.h 12 Feb 2005 17:40:48 -
@@ -38,12 +38,11 @@
static __inline__ u_int32_t
read_MMIO_LE32( volatile void * base, unsigned long offset )
{
- volatile void * p = ((volatile char *) base) + offset;
u_int32_t val;
-
+
__asm__ __volatile__( lwbrx %0, %1, %2 ; eieio
: =r (val)
- : b (base), r (offset), m (p) );
+ : b (base), r (offset) );
return val;
}
Re: r300 on a powerbook (ppc)
On Sat, 2005-02-12 at 21:00 +0100, Jerome Glisse wrote: Yes as a hack we could redefine this. Please, let's get a proper fix into Mesa instead. Have you tried my cleaned up patch? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote: Those are still incorrect as they totally lack memory barriers... INREG() doesn't (or does it?), and it's the only one used by the 3D drivers. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
On Wed, 2005-02-09 at 02:32 -0500, Vladimir Dergachev wrote: On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote: Could someone with knowledge of r200_dri explain how vertex buffer uploads are put into framebuffer memory on r200? AFAIK they aren't, the only data the radeon and r200 drivers upload to the framebuffer is textures. I was mistaken then. So the sizes that Xserver prints during startup is the result of partitioning of AGP memory ? Not sure which ones you mean exactly, but the answer is probably yes anyway. :) Is there are a reason why this could not have been allocated dynamically as needed ? I guess the lack of an appropriate memory manager is a reason... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] R200 viewport artifact
On Tue, 2005-02-08 at 16:57 +0500, Alexander E. Patrakov wrote: On Sat Nov 27 22:47:59 2004 UTC, there was a big commit into Mesa CVS by brianp, with the following comment: Remove _mesa_ResizeBuffersMESA() call from _mesa_set_viewport(). Now, the driver's Viewport routine should call _mesa_ResizeBuffersMESA() if necessary. The r200 driver fails to do that. Thls leads e.g. to the buildings outside the bottom-left 800x600 rectangle disappearing in bzflag, and screenshots showing only that rectangle. The fix (stolen from the radeon directory) is attached, please apply. Good catch! I've seen the issue with bzflag 2.0 but wouldn't have guessed it was something like this... Committed, I wonder if this applies to the stable branch as well? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL apps causes frequent system locks
On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote: Is there any way I can help to track down the problem(s)? My machine doesn't have network connection, so I can use only scripts which run in the background. With expect and gdb maybe it is possible to get at least a backtrace from my non-local-interactive machine. Unfortunately, a backtrace is usually useless for a lockup because all it will show you is the X server and/or the client(s) waiting for the GPU to become idle, which it never does because it's locked up. The problem is finding out what caused it to lock up, and that can be very hard and time consuming. That being said, I too have noticed slightly decreased stability with r200 recently. As this seems to have snuck in gradually, binary searches to try and isolate the CVS changes causing problems might be a good strategy. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote: Could someone with knowledge of r200_dri explain how vertex buffer uploads are put into framebuffer memory on r200? AFAIK they aren't, the only data the radeon and r200 drivers upload to the framebuffer is textures. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to turn on direct rendering on Savage MX?
On Tue, 2005-02-08 at 00:12 +0500, Dimitry Naldayev wrote: Michel Dnzer [EMAIL PROTECTED] writes: On Sun, 2005-02-06 at 19:32 +0500, Dimitry Naldayev wrote: Michel Dnzer [EMAIL PROTECTED] writes: I am about the X server and drm module --- what happens when we do vt switch? How this event dispatched? what parts of code I need to look to understand this? RADEONLeaveVT() in radeon_driver.c. 2) what differences between vt switch and context switch from hardware/drm point of view? None, really. Without this patch (and even with it if there are clients using the DRM), the X server simply holds the hardware lock while switched away to prevent clients from touching the hardware. No, I am not about this. X server holds hardware lock becouse drm not ready to share hardware between different X sessions... but why? Because there's only one hardware lock per device. See my logic: first case: 1) we have window and render OpenGL inside it. DRM manage OpenGL data to hardware... 2) now we HIDE the window by other window. Are the OpenGL data will go to hardware? No, becouse the OpenGL window hiden... Second case: 1) we have window and render OpenGL inside it. DRM manage OpenGL data to hardware... 2) now we do vt switch... What differences between first and second cases? The first case can still touch the hardware, it just can't render to the window. why X server need to hold lock on hardware? As I said above: To prevent clients from touching the hardware. Why DRM cannot manage second case as it manage first one? The DRM doesn't manage either case, the X server and the clients do. What we need to add to DRM for this? Something like several per-screen hardware locks, for example. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texturing performance local/gart on r100
On Tue, 2005-02-08 at 02:30 +, Dave Airlie wrote: I fully support the idea of enabling gart texturing on the r200 driver. If the old client texturing code can be kept around as an X config option, so much the better, but it shouldn't stand in the way of gart texturing given the data above. I think this is all in the client side of the driver if I'm not mistaken, the DDX and DRM look the same to me.. so we could probably do it using a driconf option... But what if you mix clients with different configuration? That's why it has to be an X server option I think. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to turn on direct rendering on Savage MX?
On Sun, 2005-02-06 at 19:32 +0500, Dimitry Naldayev wrote: Michel Dnzer [EMAIL PROTECTED] writes: FWIW, the infamous radeon DRI reinit patch is at http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff look like it is realy not best way do things right... so couple of questions: 1) what happens when we do vt switch? You mean with this patch? If there are no clients using the DRM, the DRI is de-initialized and re-initialized again on return to the X server. 2) what differences between vt switch and context switch from hardware/drm point of view? None, really. Without this patch (and even with it if there are clients using the DRM), the X server simply holds the hardware lock while switched away to prevent clients from touching the hardware. -- 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
Re: OpenGL apps causes frequent system locks
On Sun, 2005-02-06 at 19:29 +0100, Richard Stellingwerff wrote: When using OpenGL applications I get frequent X crashes as well as complete system locks. They happen totally random. My hardware is an Ati Radeon Mobility 9200 M9+. I'm using archlinux 0.7 with X.org 6.8.1 using the radeon driver. It might be a configuration error on my part, so my xorg.conf can be found at http://www.stellingwerff.com/xorg.conf for review. Does it also happen without either or all of the options in the radeon device section? -- 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
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
Re: How to turn on direct rendering on Savage MX?
On Wed, 2005-02-02 at 22:18 +0100, Felix Khling wrote: [...] only one display can use the DRM at the same time. There was a patch for the Radeon driver once that solved this problem by reinitializing the DRM on VT switches, but the Savage driver doesn't support this now. Is this patch included in CVS? You mean the radeon patch? No. I'm not sure why. Because it's a hack with a couple of limitations and issues? :) FWIW, the infamous radeon DRI reinit patch is at http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff -- 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
Re: Dying X server / Apps with linux-core.
On Mon, 2005-01-31 at 13:22 +0100, Thomas Hellstrm wrote: The thing is that I don't see this with the old drm (Running for a reasonable amount of time), but on the other hand I can't see what in drm CVS could be causing this. Could be http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg19388.html ? That thread indicates this should have been fixed though... (BTW, I think the thread also missed the point: the DRM poll() isn't 'unimplemented', it's implemented precisely the way it's supposed to be) In any case I believe this should be sorted out before linux-core makes it into the mainstream kernel. Definitely. -- 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
RE: DRI and Composite
On Fri, 2005-01-28 at 12:50 +0100, Amir Bukhari wrote: Indeed, it's our driver that disables the DRI if Composite is enabled, not the DRI in general. I expect that to stay the same until the two are properly integrated with each other (but it's not my decision to make). If some could point us to the code in the driver which disable DRI when composite is enable we could experiment with it and build for our users binaries for use with lg3d! fglrx is ATI proprietary... -- 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
Re: radeon hostdata_blt bitblt
On Thu, 2005-01-27 at 19:06 +0100, Jerome Glisse wrote: So no hope for using MULTIBLT ? I haven't looked to the source but i suppose dri do not use agp space to upload texture but a dma buffer. Yes, but that's not set in stone, so as I said, it might be a possibility for OpenGL texture uploads. Same for X ? As I said, it doesn't provide the data in the correct byte order, so unless we figure out a different way to fix it up with the GPU, the driver will have to do it with the CPU, which could just as well be done with the current method. Also, I'm not sure blits from AGP space can be used for colour expansion at all. -- 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
Re: radeon hostdata_blt bitblt
On Wed, 2005-01-26 at 13:36 -0500, Vladimir Dergachev wrote: Correction - I looked at the source and we compile the texture data as a string, so no conversion is being done. Define 'compiling as a string', but it sounds to me like it does implicitly produce the same byte order regardless of the CPU architecture. -- 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
Re: radeon hostdata_blt bitblt
On Wed, 2005-01-26 at 23:10 -0500, Vladimir Dergachev wrote: I meant that RGBA picture is represented as an unsigned char array. So byte 0 is always R, byte 1 G, and so on - irrespectively of the architecture. There is however an issue of whether conversion is being done when doing memcpy from AGP space to the framebuffer. No, the above means that the data is already always little endian in AGP space, as the GPU expects it. -- 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
Re: radeon mergedfb + pageflip fix (and some more tiling stuff again...)
On Tue, 2005-01-25 at 18:39 +0100, Roland Scheidegger wrote: The attached patch should finally fix the mergedfb + pageflip issue. It should also fix another minor problem when switching resolutions and a 3d client is active. Guess it's a bit hackish, but it works for my faked mergedfb environment at least. Also, I've again updated the radeon tiling patch (needs to be applied on top of the mergedfb_pageflip patch), dri patch is the same as before. http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri9.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm10.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx10.diff This one fixes a tiled cursor problem with not properly aligned resolutions, only enables depth moves if color tiling is enabled, and I've added the option to the man page (staring in disbelief at the macro syntax...). Looks good to me! :) -- 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
Re: radeon hostdata_blt bitblt
On Mon, 2005-01-24 at 14:24 +0100, Jerome Glisse wrote: On Sun, 23 Jan 2005 15:54:26 -0500, Michel Dnzer [EMAIL PROTECTED] wrote: On Sun, 2005-01-23 at 12:31 +0100, Jerome Glisse wrote: I was wondering what was the differences between using hostdata_blt bitblt_multi. One faster than other ? Do not use same path for reading data ? Indeed, the BITBLT_MULTI type 3 packet only allows blits within the GPU's address space, whereas hostdata blits transfer data from the CPU (the host) to the GPU. The fact that the former works correctly just means that the source data in the framebuffer already has the correct byte order. BITBLT_MULTI work if i put data in the agpgart space with cpu (memcpy) and then read it and put it in the framebuffer with bitblt_multi. This still requires that the data is copied to AGP space with the correct byte order. This might indeed work for the 3D driver (Mesa can provide little endian texture data), but not as is in the X server. RADEON_DP_GUI_MASTER_CNTL_C (0x1c84) Are you sure this is correct? At least on R200, 0x1c84 is a completely different register... I may have made an error copying the value :) at least i see a RADEON_DP_GUI_MASTER_CNTL_C in radeon_reg.h in X server. It's unused though AFAICT, I can only assume it's an error. -- 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
Re: radeon tiling again...
On Mon, 2005-01-24 at 22:24 +0100, Roland Scheidegger wrote: Alex Deucher wrote: pageflipping still doesn't work with mergedfb. Is that with Roland's separate patch for this applied as well? yes. I doesn't work with various attempts I made as well. I've done some tests too with faked mergedfb (replugging the monitor constantly is a major pita, btw), and this boils down to a simple initalization issue (at least with the mergedfb pageflip patch). Because it actually only happens the first time a 3d app is started, switching to a VT and back or scrolling in a virtual resolution fixes it and it will never appear again. I believe the problem is AdjustFrame is only called before dri initialization is finished, so directRendering is not enabled yet and thus the values in the sarea never written. However, I tried fixing that by moving (also tried copying) the pScrn-AdjustFrame(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0); to the end of RADEONScreenInit (3 lines before the end to be exact) and all I got was a SIGSEGV :-(. Have you tried calling RADEONAdjustFrame() directly instead? -- 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
Re: radeon hostdata_blt bitblt
On Sun, 2005-01-23 at 12:31 +0100, Jerome Glisse wrote: I was wondering what was the differences between using hostdata_blt bitblt_multi. One faster than other ? Do not use same path for reading data ? Indeed, the BITBLT_MULTI type 3 packet only allows blits within the GPU's address space, whereas hostdata blits transfer data from the CPU (the host) to the GPU. The fact that the former works correctly just means that the source data in the framebuffer already has the correct byte order. Other register that i am wondering about there use : RADEON_DP_MIX (0x16c8) Select source data location and ROP, both of which are mirrored in DP_GUI_MASTER_CNTL. RADEON_DP_GUI_MASTER_CNTL_C (0x1c84) Are you sure this is correct? At least on R200, 0x1c84 is a completely different register... -- 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
Re: radeon tiling again...
On Sun, 2005-01-23 at 18:33 -0500, Alex Deucher wrote: On Fri, 21 Jan 2005 21:03:06 +0100, Roland Scheidegger [EMAIL PROTECTED] wrote: Ok, new version is up here: http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm9.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx9.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri9.diff This one now uses the new surface ioctl from Stephane (included in the tiling drm patch for both core and old drm). Other than that, not much has changed. I hope this is the final version now... Mergedfb + pageflip fix is now separate (attached), you need to apply this before the tiling ddx patch. It is untested however. Roland Tested these on mergedfb and all works well. pageflipping still doesn't work with mergedfb. Is that with Roland's separate patch for this applied as well? Both viewports end up at zero as usual. That doesn't make sense, at least CRTC2 should always have worked correctly. I suspect something's wrong on your end, unless you're using the *-core DRM maybe, and this was broken there somehow? -- 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
