Re: radeon tiling again...
Alex Deucher wrote: 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? 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 :-(. I can't see why it would segfault and can't debug it, since as always when Xorg crashes in initialization, I don't have any display left... Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
On Mon, 24 Jan 2005 22:24:54 +0100, Roland Scheidegger [EMAIL PROTECTED] wrote: Alex Deucher wrote: 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? 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 :-(. I can't see why it would segfault and can't debug it, since as always when Xorg crashes in initialization, I don't have any display left... Roland what about calling adjustframe() again after DRI initialization? Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 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 tiling again...
Michel Dnzer wrote: 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? No, mostly because for mergedfb some magic is needed to get the right coordinates. Alex Deucher wrote: what about calling adjustframe() again after DRI initialization? Well, that's apparently the problem: calling it before DRI initialization won't work, and calling it after DRI initialization causes a segfault for some reason... I think it might be not be hard to figure out why with a remote debugger. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
On Mon, 24 Jan 2005 22:59:46 +0100, Roland Scheidegger [EMAIL PROTECTED] wrote: Michel Dänzer wrote: 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? No, mostly because for mergedfb some magic is needed to get the right coordinates. actually RADEONAdjustFrame() should handle mergedfb fine. RADEONAdjustFrame() will then call RADEONAdjustFrameMerged() Alex Deucher wrote: what about calling adjustframe() again after DRI initialization? Well, that's apparently the problem: calling it before DRI initialization won't work, and calling it after DRI initialization causes a segfault for some reason... I think it might be not be hard to figure out why with a remote debugger. what about two calls? one after and one before? Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
Alex Deucher wrote: actually RADEONAdjustFrame() should handle mergedfb fine. RADEONAdjustFrame() will then call RADEONAdjustFrameMerged() You're right I mixed that up with DoAdjustFrame. I can't see though why this shouldn't work just the same as pScrn-AdjustFrame (I don't see any code which would set that AdjustFrame function to something else). Alex Deucher wrote: what about calling adjustframe() again after DRI initialization? Well, that's apparently the problem: calling it before DRI initialization won't work, and calling it after DRI initialization causes a segfault for some reason... I think it might be not be hard to figure out why with a remote debugger. what about two calls? one after and one before? Yes, tried that. No joy. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
Michel Dnzer wrote: On Mon, 2005-01-24 at 23:42 +0100, Roland Scheidegger wrote: Alex Deucher wrote: actually RADEONAdjustFrame() should handle mergedfb fine. RADEONAdjustFrame() will then call RADEONAdjustFrameMerged() You're right I mixed that up with DoAdjustFrame. I can't see though why this shouldn't work just the same as pScrn-AdjustFrame (I don't see any code which would set that AdjustFrame function to something else). I know of at least one other AdjustFrame() wrapper, for Xv. Maybe that's causing trouble at the time you try calling the screen function. If all you want is to make sure the SAREA fields are well-defined, calling the driver function directly might make more sense anyway. Ok found out what's going on. The comment is right in radeon_accel.c, for a different function, but that's the reason. /* FIXME: pScrn-pScreen has not been initialized when this is first * called from RADEONSelectBuffer via RADEONDRICPInit. We could use * the screen index from pScrn, which is initialized, and then get * the screen from screenInfo.screens[index], but that is a hack. */ dma.context = DRIGetContext(pScrn-pScreen); So, pScrn-pScreen is always NULL in RADEONScreenInit (it will get initilialized right after that). So DRIGetSAREAPrivate segfaults. So does the stuff in RADEONAdjustFrame. Is there a particular reason why it's a bad idea to just use screenInfo.screens[index], other than it's a hack and ugly? Could bad things happen? I've tried that (only in DoAdjustFrame, calling AdjustFrameMerged directly) and this works (not only does it not segfault, but it actually finally fixes this stupid bug!) Is there some better method to fix this? I guess even pScrn-pScreen could be hacked up, it will get overwritten right after that anyway... As far as I can see, there is no other function which will get called after ScreenInit, which could be used to call AdjustFrame from there instead. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
Roland Scheidegger wrote: Michel Dnzer wrote: Also, I only now noticed this comment in the DDX diff: Well, the comment is new in this patch (and so is the code for depth moves, the older patches just have a remember for later comment, forgot to mention) /* The Radeon has depth tiling on all the time. Rely on surface regs to + * translate the addresses (will fail if allowColorTiling is 0). */ So depth moves will be broken when tiling is disabled? Not that they're important... The old code ONLY ever worked for original radeons (r100, possibly rv200) - it could never have worked for rv100, r200, rv250, igps. Additionally, the old code actually had an error which not only made it (reasonable guess) 33% slower, but never copy the stencil buffer. Yet nobody (afaik) ever complained about that. I just figured it's not worth the hassle of doing lots of if this card, this feature do that code which is never used anyway, and only supporting it if tiling is enabled made the code much simpler. You're right though it might not be a very good idea to support depth moves corretly only sometimes. Guess it would in fact be better to not support them at all, Keith seemed to be perfectly happy with that solution. Will remove them. Yes, I'm happy to see it removed. I don't think anyone uses it and as you point out it's pretty rotted. Keith --- 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...
Michel Dnzer wrote: On Sun, 2005-01-23 at 02:48 +0100, Roland Scheidegger wrote: You're right though it might not be a very good idea to support depth moves corretly only sometimes. Guess it would in fact be better to not support them at all, Keith seemed to be perfectly happy with that solution. Will remove them. That, or at least don't allow enabling them if tiling is disabled. Maybe they would be useful if done by the engine instead of the CPU? I think really the radeon hardware is heavily tilted towards private depth buffers, maybe the effort would be better spent in that direction. Another two-way handshake required, but if we get comfortable with that idea, it should be fairly easy to get working. Keith --- 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...
Am Freitag, 21. Januar 2005 21:03 schrieb Roland Scheidegger:
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.
Hello Roland,
do I need libGL.so.x.x from Mesa CVS, too?
I get sigfault in swrast with version 9 (linux-dri-x86, r200_dri.so) and some
VTK apps. After I'm finally up and running X.org CVS ontop of SuSE 9.0 my
viewport problems with VTK (window resize) are solved.
GREAT work!
quake3-smp ~190 fps (640x480 window on 1280x1024x24/32)
Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
#0 0x40b7b484 in _swrast_use_read_buffer (ctx=0x80ae9b0) at s_buffers.c:274
274swrast-CurrentBufferBit = ctx-Pixel._ReadSrcMask;
(gdb) list
269 _swrast_use_read_buffer( GLcontext *ctx )
270 {
271SWcontext *swrast = SWRAST_CONTEXT(ctx);
272
273/* Do this so the software-emulated alpha plane span functions
work!*/
274swrast-CurrentBufferBit = ctx-Pixel._ReadSrcMask;
275/* Tell the device driver where to read/write spans */
276swrast-Driver.SetBuffer(ctx, ctx-ReadBuffer,
swrast-CurrentBufferBit);
277 }
278
(gdb) info registers
eax0x0 0
ecx0x0 0
edx0x80ae9b0134932912
ebx0x809cdc0134860224
esp0xbfffe2e0 0xbfffe2e0
ebp0xbfffe2f8 0xbfffe2f8
esi0x80ae9b0134932912
edi0x0 0
eip0x40b7b484 0x40b7b484
eflags 0x10282 66178
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) bt
#0 0x40b7b484 in _swrast_use_read_buffer (ctx=0x80ae9b0) at s_buffers.c:274
#1 0x40b836ba in _swrast_CopyConvolutionFilter2D (ctx=0x80ae9b0,
target=34336, internalFormat=0, x=134932912, y=-1073748672,
width=134932912, height=-1073748744) at s_imaging.c:120
#2 0x40aefa68 in alloc_shared_state (ctx=0x80ae9b0) at context.c:853
#3 0x40af02f2 in _mesa_initialize_context (ctx=0x80ae9b0, visual=0x809b3b8,
share_list=0x0, driverFunctions=0xbfffe540, driverContext=0x80a92e8)
at context.c:1452
#4 0x40af0447 in _mesa_create_context (visual=0x809b3b8, share_list=0x0,
driverFunctions=0xbfffe540, driverContext=0x80a92e8) at context.c:1532
#5 0x41a50ae1 in r200CreateContext (glVisual=0x809b3b8,
driContextPriv=0x809cda0, sharedContextPrivate=0x0) at r200_context.c:291
#6 0x41a500ce in driCreateNewContext (dpy=0x808cbb8, modes=0x809b3b8,
render_type=0, sharedPrivate=0x0, pctx=0x809e3a4)
at ../common/dri_util.c:1061
#7 0x40a6ec6d in DriverCreateContextWrapper (psc=0x809afb8, dpy=0x808cbb8,
vis=0x809dc90, shared=0x0, ctx=0x809e3a4, modes=0x809b3b8, render_type=0)
at glxcmds.c:137
#8 0x40a6f15f in CreateContext (dpy=0x808cbb8, vis=0x809dc90, fbconfig=0x0,
shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0)
at glxcmds.c:463
#9 0x40a6f3b9 in glXCreateContext (dpy=0x808cbb8, vis=0x809dc90,
shareList=0x0, allowDirect=1) at glxcmds.c:541
#10 0x4027f723 in vtkXOpenGLRenderWindow::WindowInitialize() ()
from ./libvtkRendering.so
#11 0x4027fb89 in vtkXOpenGLRenderWindow::Initialize() ()
from ./libvtkRendering.so
#12 0x40280180 in vtkXOpenGLRenderWindow::Start() () from ./libvtkRendering.so
#13 0x40263960 in vtkXRenderWindowInteractor::Initialize() ()
from ./libvtkRendering.so
#14 0x40088b33 in vtkParallelRenderManager::StartInteractor() ()
from ./libvtkParallel.so
#15 0x08049aac in process(vtkMultiProcessController*, void*) ()
#16 0x400c32d3 in vtkThreadedController::Start(int) ()
from ./libvtkParallel.so
#17 0x400c310e in vtkThreadedController::vtkThreadedControllerStart(void*) ()
from ./libvtkParallel.so
#18 0x412b8bd8 in vtkMultiThreader::SingleMethodExecute() ()
from ./libvtkCommon.so
#19 0x400c34a1 in vtkThreadedController::SingleMethodExecute() ()
from ./libvtkParallel.so
#20 0x08049b91 in main ()
-Dieter
---
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
Re: radeon tiling again...
Michel Dnzer wrote: On Sun, 2005-01-23 at 02:48 +0100, Roland Scheidegger wrote: You're right though it might not be a very good idea to support depth moves corretly only sometimes. Guess it would in fact be better to not support them at all, Keith seemed to be perfectly happy with that solution. Will remove them. That, or at least don't allow enabling them if tiling is disabled. Maybe they would be useful if done by the engine instead of the CPU? I've thought about that, but I see no way how to do that. A blit would certainly be a _lot_ faster, but the radeon blitter can't tile/untile the depth pattern, only the color pattern. Or, if it could do it, at least I don't know how... Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
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. Both viewports end up at zero as usual. Nice work!!! Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 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
Re: radeon tiling again...
On Sun, 23 Jan 2005 19:58:29 -0500, Michel Dänzer [EMAIL PROTECTED] wrote: 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? yes. I doesn't work with various attempts I made 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? Nope, my radeon box is still on 2.4. pageflipping used to work fine (at least when crtc1 was at a lower offset) when I was using the DRI tree, but ever since we started using the Xorg tree, pageflipping stopped working. I can confirm that lots of other users also have this behavior; perhaps something weird about the sarea handling in xorg vs. the DRI tree? I plan to ugrade my radeon box to a 2.6 distro in the next few days so I'll test again then. Alex -- 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: 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 20:42 -0500, Alex Deucher wrote:
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?
Nope, my radeon box is still on 2.4. pageflipping used to work fine
(at least when crtc1 was at a lower offset) when I was using the DRI
tree, but ever since we started using the Xorg tree, pageflipping
stopped working. I can confirm that lots of other users also have
this behavior; perhaps something weird about the sarea handling in
xorg vs. the DRI tree?
Possible I guess, but the fact that page flipping works at all means
that the pf{AllowPageFlip,CurrentPage} fields of the driver private
SAREA work as expected, so it's odd that the immediately following
crtc2_base (and the generic SAREA frame coordinate origin fields)
wouldn't work. *shrug*
--
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 Fri, 2005-01-21 at 21:03 +0100, Roland Scheidegger 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). I think we concluded on IRC that radeon_surfaces_release() should also be called from radeon_do_release() in case the X server doesn't clean up its surfaces? Also, I only now noticed this comment in the DDX diff: /* The Radeon has depth tiling on all the time. Rely on surface regs to + * translate the addresses (will fail if allowColorTiling is 0). */ So depth moves will be broken when tiling is disabled? Not that they're important... Otherwise, it looks good to go to me, good work guys! I hope my comments haven't been only nitpicking. Mergedfb + pageflip fix is now separate (attached), you need to apply this before the tiling ddx patch. It is untested however. FWIW, it makes sense 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 tiling again...
Michel Dnzer wrote: 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). I think we concluded on IRC that radeon_surfaces_release() should also be called from radeon_do_release() in case the X server doesn't clean up its surfaces? Hmm, I think I've missed part of that discussion. Or maybe didn't pick up the conclusion... Will do that. Also, I only now noticed this comment in the DDX diff: Well, the comment is new in this patch (and so is the code for depth moves, the older patches just have a remember for later comment, forgot to mention) /* The Radeon has depth tiling on all the time. Rely on surface regs to + * translate the addresses (will fail if allowColorTiling is 0). */ So depth moves will be broken when tiling is disabled? Not that they're important... The old code ONLY ever worked for original radeons (r100, possibly rv200) - it could never have worked for rv100, r200, rv250, igps. Additionally, the old code actually had an error which not only made it (reasonable guess) 33% slower, but never copy the stencil buffer. Yet nobody (afaik) ever complained about that. I just figured it's not worth the hassle of doing lots of if this card, this feature do that code which is never used anyway, and only supporting it if tiling is enabled made the code much simpler. You're right though it might not be a very good idea to support depth moves corretly only sometimes. Guess it would in fact be better to not support them at all, Keith seemed to be perfectly happy with that solution. Will remove them. Otherwise, it looks good to go to me, good work guys! I hope my comments haven't been only nitpicking. I certainly appreciate any feedback which potentially saves me from major headaches later... And if I didn't want any feedback, I'd probably wouldn't have posted it to the list(s) multiple times ;-). So thanks for looking at it and pointing out the issues. Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon tiling again...
On Sun, 2005-01-23 at 02:48 +0100, Roland Scheidegger wrote: You're right though it might not be a very good idea to support depth moves corretly only sometimes. Guess it would in fact be better to not support them at all, Keith seemed to be perfectly happy with that solution. Will remove them. That, or at least don't allow enabling them if tiling is disabled. Maybe they would be useful if done by the engine instead of the CPU? -- 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
radeon tiling again...
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
Index: radeon_dri.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.11
diff -u -r1.11 radeon_dri.c
--- radeon_dri.c17 Dec 2004 16:50:36 - 1.11
+++ radeon_dri.c21 Jan 2005 19:02:17 -
@@ -1328,6 +1282,9 @@
RADEON_MAX_DRAWABLES
? SAREA_MAX_DRAWABLES
: RADEON_MAX_DRAWABLES);
+/* kill DRIAdjustFrame. We adjust sarea frame info ourselves to work
+ correctly with pageflip + mergedfb/color tiling */
+pDRIInfo-wrap.AdjustFrame = NULL;
#ifdef PER_CONTEXT_SAREA
/* This is only here for testing per-context SAREAs. When used, the
Index: radeon_driver.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.36
diff -u -r1.36 radeon_driver.c
--- radeon_driver.c 13 Jan 2005 17:35:49 - 1.36
+++ radeon_driver.c 21 Jan 2005 19:02:25 -
@@ -74,6 +74,7 @@
#define _XF86DRI_SERVER_
#include radeon_dri.h
#include radeon_sarea.h
+#include sarea.h
#endif
#include fb.h
@@ -7510,6 +7855,7 @@
intreg, Base;
#ifdef XF86DRI
RADEONSAREAPrivPtr pSAREAPriv;
+XF86DRISAREAPtr pSAREA;
#endif
if (info-showCache y) {
@@ -7543,12 +7919,21 @@
#ifdef XF86DRI
if (info-directRenderingEnabled) {
-
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
+ /* can't get at sarea in a semi-sane way? */
+ pSAREA = (void *)((char*)pSAREAPriv - sizeof(XF86DRISAREARec));
if (clone || info-IsSecondary) {
pSAREAPriv-crtc2_base = Base;
}
+ else {
+ pSAREA-frame.x = (Base / info-CurrentLayout.pixel_bytes)
+ % info-CurrentLayout.displayWidth;
+ pSAREA-frame.y = (Base / info-CurrentLayout.pixel_bytes)
+ / info-CurrentLayout.displayWidth;
+ pSAREA-frame.width = pScrn-frameX1 - x + 1;
+ pSAREA-frame.height = pScrn-frameY1 - y + 1;
+ }
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
