Re: radeon/r200 color tiling ddx / drm questions
On Fri, 2005-01-07 at 04:10 +0100, Roland Scheidegger wrote: > > The dri and drm seem fairly straightforward, though I'm not sure the way > I handled communication between especially drm and ddx is how it's meant > to be. dri got a bit unlucky, as ddx can't know at startup if it will be > able to handle color tiling, so old dri together with new drm and new > ddx will not work (correctly) (if you have enabled color tiling). You might be able to solve this with a two-way handshake between the 3D driver and the DDX, similar to how it's done with the DRM already. With that, the DDX could recognize clients that can deal with tiling and prevent others from using direct rendering. > 1) the biggest problem is XAA's handling of graphic memory. It treats > everything as a single big chunk of linear framebuffer. Actually, it treats it as a rectangle of the same width as the virtual width of the screen. The tiling should really be uniform over that whole rectangle. A problem with that is that the hardware cursor does and the back and depth buffers and textures may overlap with it. > 2) I was unable to make render work with the changed x coordinates > trick, needed to support coordinates beyond 2048. I think it should be > possible that this works? Maybe the calculation of the colour offset has to take the tiling into account? > 3) When switching from/to a resolution without tiling support, If tiling doesn't work with all resolutions, shouldn't those resolutions be discarded in the first place if tiling is enabled? > everything on screen will be really wrong and needs to be redrawn. I > guess it's somehow possible to mark everything as dirty or something > like that? Just externally calling "xrender" doesn't sound like a good > solution... Maybe you could walk the window tree and generate expose events or something like that, but that would be rather ugly. > 5) I'm not sure how exactly fbdev (the UseFBDev option) works, but I'm > pretty confident it won't work at all with color tiling, and I've no > idea how you'd fix that, [...] It's true that radeonfb doesn't enable tiling when it sets a mode, and there's no way that I know of to tell it to do it even if it could. The only (hackish) way I can see would be to make sure the relevant registers are correct after calling into fbdevHW for setting the mode, but for now I'd just disable tiling if fbdev is enabled. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
On Wed, 2005-01-05 at 09:27 -0500, Alex Deucher wrote: > Ok, so last night I think I figured out why pageflipping was borked > with mergedfb. Unfortunately the fix requires changes to the drm and > sarea. I'm wondering what the best way to do this is and maintain > compatability. When crtc1 is at offset 0 pageflipping should work > with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the > backbuffer offset was being added to the base address after the > crtc2_base info was updated in the sarea. That's an easy fix. For what? radeon_cp_dispatch_flip() adds the offset before writing the CRTC(2)_OFFSET registers? > For situations where crtc2 is at offset 0 and crtc1 is at a higher offset, > changes to the drm and sarea are required. I think the easiest > solution would be to add a crtc1_base to the sarea and update that in > RadeonDoAdjustframe() just like crtc2_base. The problem is that in > the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of > crtc1 is calculated from the sarea frame info which could be crtc1 or > crtc2 depending on their orientation. It should really be calcluated > in RadeonDoAdjustframe() just like crtc2 base. Why don't you make sure the frame info is set the way the DRM expects it instead? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
On Mon, 10 Jan 2005, Keith Conger wrote: Hi, Here ya go: 0xff03 Also as of this morning the cvs HEAD's driver no longer displays the gears for me. This is probably because I left the pipeline using agp buffer upload of vertices instead of immediate one. Try editint r300_render.c, r300_run_render function to make sure it calls r300_run_immediate_render and not *vb* version. Also, could you try putting the following fragment in r300_render.c r300_run_immediate_render (and/or *vb* counterpart): reg_start(0x2140, 0); e32(2); (Also try 0 and 1). If this has any effect, try changing r300_state.c, r300ResetHwState, from line r300->hw.unk2140.cmd[1] = 0x; to r300->hw.unk2140.cmd[1] = #ifdef MESA_BIG_ENDIAN R200_VC_32BIT_SWAP; #else R200_VC_NO_SWAP; #endif (R200 is not a mistake - these constants are not defined (yet ?) for R300). thank you ! Vladimir Dergachev Keith On Mon, 2005-01-10 at 09:44 -0500, Vladimir Dergachev wrote: On Mon, 10 Jan 2005, Keith Conger wrote: Hi, Sorry this took so long. r300_driver prints -16580608 as fbLocation. As for X I can't seem to get it to print it, I'll keep working on this though. Could you change the format to 0x%08x (instead of %d) ? This way it will be printed as hex, easier to read. thank you ! Vladimir Dergachev Thanks, Keith On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: This is especially puzzling since your computer does not lockup, as what should surely happen if there were endianness problems all over the place. Could you check what is the value of fbLocation ? (in Xserver and the driver). Not sure exactly how to do this but will gladly if you you give me a hint. :) Probably the easiest way is to grep for it in the driver source, find a place that is executed and add fprintf(stderr, ...) . The texture code uses it (r300_state.c), so you could put fprintf there and run lesson06 or anything else that uses textures. best Vladimir Dergachev Thanks! -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300-commit] r300_driver/r300 r300_render.c,1.29,1.30
On Mon, 10 Jan 2005, Nicolai Haehnle wrote: On Monday 10 January 2005 04:42, Vladimir Dergachev wrote: Update of /cvsroot/r300/r300_driver/r300 In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1824 Modified Files: r300_render.c Log Message: For some reason we need r300Flush when using textures. Perhaps the problem is with BITBLT_MULTI call ? I haven't looked at how texturing is implemented yet, but are the GPU caches flushed after the texture upload and before the rendering? I think r300Flush() does this implicitly. Good point, I have not paid any attention to caches. However, r300Flush works around a lockup which occurs if it is not present. I would normally expect that not touching the cache would simply mean we paint the wrong thing. Of course, it might be that cache management is simply broken on r300 and later cards. thank you ! Vladimir Dergachev cu, Nicolai --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
With applying byte swapping to get_short & get_int in r300_demo i successfully run all the demo except the --vb-triangles, --eb-triangles & --idx-triangles where i see nothing guess this is related to cp engine that need some byte swapping no ? Or does that Keith successfully running glxgears (even if they are drawn in wrong place) means that the vertex or elements buffer work properly on ppc ? It might be that these have different byteswapping for the data in AGP memory. I imagine if vertex data got byteswapped the wrong way you would see nothing as the coordinates would be outside of the viewport or triangles be too small to draw (in which case you will see only one point on the screen) best Vladimir Dergachev Dammm G5 are beautifull but they give some work :) best, Jerome Glisse --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300-commit] r300_driver/r300 r300_render.c,1.29,1.30
On Monday 10 January 2005 04:42, Vladimir Dergachev wrote: > Update of /cvsroot/r300/r300_driver/r300 > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1824 > > Modified Files: > r300_render.c > Log Message: > For some reason we need r300Flush when using textures. Perhaps the problem is > with BITBLT_MULTI call ? I haven't looked at how texturing is implemented yet, but are the GPU caches flushed after the texture upload and before the rendering? I think r300Flush() does this implicitly. cu, Nicolai pgptrCrP3wsKB.pgp Description: PGP signature
Re: [r300] Latest r300_driver on PPC
Hi, Here ya go: 0xff03 Also as of this morning the cvs HEAD's driver no longer displays the gears for me. Keith On Mon, 2005-01-10 at 09:44 -0500, Vladimir Dergachev wrote: > > On Mon, 10 Jan 2005, Keith Conger wrote: > > > Hi, > > > > Sorry this took so long. r300_driver prints -16580608 as fbLocation. As > > for X I can't seem to get it to print it, I'll keep working on this > > though. > > Could you change the format to 0x%08x (instead of %d) ? This way it will > be printed as hex, easier to read. > > thank you ! > > Vladimir Dergachev > > > > > Thanks, > > Keith > > On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: > >>> > > This is especially puzzling since your computer does not lockup, > as what should surely happen if there were endianness problems all > over the place. > > Could you check what is the value of fbLocation ? (in Xserver and > the driver). > >>> > >>> Not sure exactly how to do this but will gladly if you you give me a > >>> hint. :) > >> > >> Probably the easiest way is to grep for it in the driver source, find a > >> place that is executed and add fprintf(stderr, ...) . > >> > >> The texture code uses it (r300_state.c), so you could put fprintf there > >> and run lesson06 or anything else that uses textures. > >> > >> best > >> > >> Vladimir Dergachev > >> > >>> > >>> Thanks! > >>> > >>> -- > >>> > >>> Keith Conger > >>> [EMAIL PROTECTED] > >>> http://pimpstation.org > >>> > > -- > > > > Keith Conger > > [EMAIL PROTECTED] > > http://pimpstation.org > > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
Vladimir Dergachev wrote: On Mon, 10 Jan 2005, Keith Conger wrote: Hi, Sorry this took so long. r300_driver prints -16580608 as fbLocation. As for X I can't seem to get it to print it, I'll keep working on this though. Could you change the format to 0x%08x (instead of %d) ? This way it will be printed as hex, easier to read. I played with this value and i got no lockup when i do some swapping : aabbccdd become bbaaccdd I do this in radeon_screen.c where the FBLOCATION register is read. By the way ccdd are no revealent here because they are 0. I i got no lockup (with glxgears or one of my gl applications) i still see nothing (in fact the window is fill with some random pattern or memory garbage) and the fps drop to very low value (65fps with glxgears where i get 200 & more in software and expect 1000 & more with hardware :)) I also looked at the radeon driver in the Xorg tree and i notice that there seems to be byte swapping for MMIO register access. But when i try to do so for r300 dri i lockup the computer. To see for byte swapping in xorg look at /xc/programs/Xserver/hw/xfree86/common/compiler.h There is the definition for MMIO_IN32 & MMIO_IN16 MMIO_OUT32 & MMIO_OUT16. If we are on ppc architecture thus macro are defined with byte swapping unless PPC_MMIO_IS_BE is defined. But all definition of MMIO are dependant of too much things...So i am not sure which version is used. I guess i have to make some print to test this... So do you think there is somethings related with byte swapping MMIO ? With applying byte swapping to get_short & get_int in r300_demo i successfully run all the demo except the --vb-triangles, --eb-triangles & --idx-triangles where i see nothing guess this is related to cp engine that need some byte swapping no ? Or does that Keith successfully running glxgears (even if they are drawn in wrong place) means that the vertex or elements buffer work properly on ppc ? Dammm G5 are beautifull but they give some work :) best, Jerome Glisse --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
On Mon, 10 Jan 2005, Keith Conger wrote: Hi, Sorry this took so long. r300_driver prints -16580608 as fbLocation. As for X I can't seem to get it to print it, I'll keep working on this though. Could you change the format to 0x%08x (instead of %d) ? This way it will be printed as hex, easier to read. thank you ! Vladimir Dergachev Thanks, Keith On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: This is especially puzzling since your computer does not lockup, as what should surely happen if there were endianness problems all over the place. Could you check what is the value of fbLocation ? (in Xserver and the driver). Not sure exactly how to do this but will gladly if you you give me a hint. :) Probably the easiest way is to grep for it in the driver source, find a place that is executed and add fprintf(stderr, ...) . The texture code uses it (r300_state.c), so you could put fprintf there and run lesson06 or anything else that uses textures. best Vladimir Dergachev Thanks! -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
Hi, Sorry this took so long. r300_driver prints -16580608 as fbLocation. As for X I can't seem to get it to print it, I'll keep working on this though. Thanks, Keith On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: > > > >> > >> This is especially puzzling since your computer does not lockup, > >> as what should surely happen if there were endianness problems all > >> over the place. > >> > >> Could you check what is the value of fbLocation ? (in Xserver and > >> the driver). > > > > Not sure exactly how to do this but will gladly if you you give me a > > hint. :) > > Probably the easiest way is to grep for it in the driver source, find a > place that is executed and add fprintf(stderr, ...) . > > The texture code uses it (r300_state.c), so you could put fprintf there > and run lesson06 or anything else that uses textures. > > best > > Vladimir Dergachev > > > > > Thanks! > > > > -- > > > > Keith Conger > > [EMAIL PROTECTED] > > http://pimpstation.org > > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 & PPC
Jerome Glisse wrote: I think it's related to r300 driver because i get something with the r300 demo. I get the depth buffer with r300 demo but not the color one. I think this is due to radeon base address or to the R300_RB3D_COLOROFFSET0 setup, moreover there is a need for some endian swapping with get_int & get_short. So with r300 demo i see what i think is the depth buffer (something similar to what i got on x86, yellow buffer ...) and have not lock. With r300 driver glxinfo show strange things & glxgears hard lock the computer. I get more things with r300_demo add send a patch (for endian swapping). You could get a screenshot here to see what i got : http://dj.planet-d.net/Capture-PPC.png Which is the normal (as long i remember well what i got on x86 :)) Vladimir you where talking about fbLocation, you think that r300 driver lock may come from this ? What i found strange is that the window seems to clear well but that drawing anything will lock. I will do a sample gl program to see if only doing glclearbuffer is not locking. More over Keith who got the driver working on g4 seems to have the gears drawing in wrong place but clearbuffer in the correct place, isn't he ? Thus shouldn't this be linked with the viewport ? or something else ? By the way there is no swapping like on r200 ? rmesa->hw.cst.cmd[CST_SE_VAP_CNTL_STATUS] = #ifdef MESA_BIG_ENDIAN R200_VC_32BIT_SWAP; #else R200_VC_NO_SWAP; #endif r200_state_init.c i keep on looking to that... best, Jerome Glisse --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 & PPC
Hi, Finally i find my bug in AGP but r300 still not work. You will see below revelant part of my xorg log. I think it's related to r300 driver because i get something with the r300 demo. I get the depth buffer with r300 demo but not the color one. I think this is due to radeon base address or to the R300_RB3D_COLOROFFSET0 setup, moreover there is a need for some endian swapping with get_int & get_short. So with r300 demo i see what i think is the depth buffer (something similar to what i got on x86, yellow buffer ...) and have not lock. With r300 driver glxinfo show strange things & glxgears hard lock the computer. Anyway i wanted to known if anyone get an idea of the reasons behind the fail of r300 driver on PPC ? Any idea could help :) best, Jerome Glisse xdriinf o pluton:/home/jerome/dev/r300_demo#xdriinfo Screen 0: r300 pluton:/home/jerome/dev/r300_demo# - Xorg.0.log (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 000x9000 - 0x9000 (0x1) MX[B] [1] 000xa000 - 0xafff (0x1000) MX[B] [2] -100x - 0x (0x1) MX[B] [3] -100x - 0x (0x1) MX[B] [4] -100x8060 - 0x80601fff (0x2000) MX[B] [5] -100x8040 - 0x805f (0x20) MX[B] [6] -100x8020 - 0x80200fff (0x1000) MX[B] [7] -100x80204000 - 0x80207fff (0x4000) MX[B] [8] -100x8010 - 0x801000ff (0x100) MX[B] [9] -100x80101000 - 0x80101fff (0x1000) MX[B] [10] -100x80102000 - 0x80102fff (0x1000) MX[B] [11] -100x8008 - 0x80080fff (0x1000) MX[B] [12] -100x80081000 - 0x80081fff (0x1000) MX[B] [13] -100x8000 - 0x8007 (0x8) MX[B] [14] -100xf100 - 0xf101 (0x2) MX[B](B) [15] -100x9000 - 0x9000 (0x1) MX[B](B) [16] -100xa000 - 0xafff (0x1000) MX[B](B) [17] -100x80104000 - 0x80105fff (0x2000) MX[B] [18] 000x000a - 0x000a (0x1) MS[B](OprU) [19] 000x000b - 0x000b7fff (0x8000) MS[B](OprU) [20] 000x000b8000 - 0x000b (0x8000) MS[B](OprU) [21] 000x0400 - 0x04ff (0x100) IX[B] [22] -100x00ff - 0x00ff (0x1) IX[B] [23] -100x - 0x (0x1) IX[B] [24] -100x0400 - 0x04ff (0x100) IX[B](B) [25] 000x03b0 - 0x03bb (0xc) IS[B](OprU) [26] 000x03c0 - 0x03df (0x20) IS[B](OprU) (WW) RADEON(0): Enabling DRM support *** Direct rendering support is highly experimental for Radeon 9500 *** and newer cards. In fact, the only thing you could probably use *** it for is better 2d acceleration. The 3d mesa driver is not *** provided in this tree. A very experimental (and incomplete) *** version is available from http://r300.sourceforge.net *** This message has been last modified on 12/12/04. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: Searching for BusID pci::f0:10.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 5, (OK) drmOpenByBusid: drmOpenMinor returns 5 drmOpenByBusid: drmGetBusid reports pci::f0:10.0 (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci::f0:10.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe2264000 (II) RADEON(0): [drm] mapped SAREA 0xe2264000 to 0x380c7000 (II) RADEON(0): [drm] framebuffer handle = 0xa000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000269 [AGP 0x106b/0x0059; Card 0x1002/0x4152] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0x (II) RADEON(0): [agp] Ring mapped at 0x380c9000 (II) RADEON(0): [agp] ring read ptr handle = 0x00101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x381ca000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0x00102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x381cb000 (II) RADEON(0): [agp] GART texture map handle = 0x00302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x383cb000 (II) RADEON(0): [drm] register handle = 0x9000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1408,8191) (II) RADEON(0): Reserved area from (0,1050) to (1408,1052) (II
