Re: FB model basic issues (WAS: radeon, apertures & memory mapping)
On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote: > If radeonfb will allocate the buffer for the second head from the top of > the memory users would basically have to guess it's location. matroxfb > simply cuts the memory in two pieces and allocates the buffers from the > start of each piece. I don't really like that approach. Adding a simple > byte_offset field to fb_var_screeninfo would solve the problem quite > nicely but I don't know if such API changes are acceptable at this stage. And we don't know if all HW would support it anyway. > > > 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. > > Indeed. The main issue hwoever, is access arbitration. I'd appreciate your DirectFB point of view on these things. Ben. --- 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_ide95&alloc_id396&op=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 00:30 -0500, Jon Smirl wrote: > I agree that X has to be fixed to work cooperatively in this environment. > The alternative is to just leave X alone and make all of this work for XGL. > The user would then choose which environment they want to run. > > I'm leaning toward just leaving X alone and spending the resources on > making XGL work. After all XGL is a complete X replacement. > > If you want to run existing X load an old fbdev driver. We can keep both > fbdev drivers in the kernel until it is clear if XGL is going mainstream. > > One thing that does need to get fixed is mesa support for non-accelerated > fbdev drivers but mesa can add all of the appropriate locking. No, that isn't realistic. I want a smooth transition, and XGL won't be the only player in the field anyway. > > I think that Jon's dream of having totally independant heads that can > > run 2 separate applications is a long way away and we have sort-of to > > tie /dev/fb's together, though I don't know how to acheive that in > > practice, unless we switch to a new API that can enforce it. The current > > fbdev API cannot. > > This is definitely something to works towards. There is a lot of > application for this in schools, libraries, internet cafe, etc. There > are several companies selling variations on this. > > I don't expect an immediate solution but I want to make sure the > redesign allows it to be built. Yes. But I think that we should basically consider that anybody openng /dev/fb also "locks out" write access to the other heads. That is, the other head can be opened, but nothing done (mmap etc... on it) unless both opener's have done the right ioctl telling us they know how to do arbitration or that kind of thing. No ? The fbdev API needs a mirror of the vga arbitration API. The later is for use only by applications directly tapping vga legacy stuff. But something using fbdev also need a lock/unlock API to enclose any hardware access, at the very least. And when you think about it, what you end up needing is ... the DRM lock. So there might be some need to have fbdev be capable of taking the DRM lock now. Unless that's done, I'll have to impose severe restrictions on accesses to radeonfb's second head. > Can we put in our own fault handler for the mmap, trap the directfb > accesses and do the proper locking? Gack. First that's "lazy locking" and something I'd like to avoid, but if directfb API doesn't provide any other option ... then, it also requires regulary un-mapping them back from the process using directfb or the stuff will remain locked forever, and unmapping things behind a process back isn't cool (some interesting locking issues). Overall rather complicated and inefficient performance wise. And part of that infrastructure already exist, somewhat, in the DRM ... If a directFB client uses a /dev/fb, I think it should own both heads. We simply can't do anything else. And we might even still need arbitration because of the VGA stuff in case the card we are using has legacy decoding enabled _anyway_. So Ben. --- 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_id=6595&alloc_id=14396&op=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 Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote: > 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. But that will not be true with dual head unless I put the second framebuffer into some fixed location in memory, thus making life more difficult for the allocator. > 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. I'll try, I'm near by bandwidth limit already though. > > 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? Read the rest of the email. > > > 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. I meant DRM. That is some arbitration & locking. There is simply _NO_ way we can have something that works with both independant multiple heads and direct banging of the framebuffer without arbitration. There is no magic here. It _can_ be made to work in _some_ cases using the separate swappers, but that won't help if one of the heads try to do accel Ben. --- 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_ide95&alloc_id396&op=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 Mon, Mar 14, 2005 at 11:59:37PM -0500, Michel Dänzer wrote: > 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. DirectFB assumes all memory outside var.yres_virtual * fix.line_length is preserved. A totally valid assumption in my opinion. It allocates all offscreen memory starting from the top of the memory so overlaps with fbdev are as rare as possible. Currently it doesn't handle multi head except for Matrox G400/G450/G550 TV-out but that is handled without fbdev so no API limitations get in the way. 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. If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. > > 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. Indeed. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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_ide95&alloc_id396&op=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, 15 Mar 2005 09:37:53 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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. 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. I can agree that all video memory for that head can be booted. But just because one head changes mode we shouldn't boot the objects for the other head. You wouldn't want the two user case of one user changing modes making the other user's display blink. > > We can't also block all evolutions just because we have to support a > broken model. 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. > > _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, so that > means I have some flexibility. The second head will probably" move on > mode switches since I intend to allocate it at the top of the accessible > aperture as described by Jon. I agree that X has to be fixed to work cooperatively in this environment. The alternative is to just leave X alone and make all of this work for XGL. The user would then choose which environment they want to run. I'm leaning toward just leaving X alone and spending the resources on making XGL work. After all XGL is a complete X replacement. If you want to run existing X load an old fbdev driver. We can keep both fbdev drivers in the kernel until it is clear if XGL is going mainstream. One thing that does need to get fixed is mesa support for non-accelerated fbdev drivers but mesa can add all of the appropriate locking. > > All of that just keep uncovering more and more issues with our current > fbdev model though. From discussions we had so far, it uncovers the > problem of arbitration. That is, can we simply afford having a process > mmap /dev/fb and blast things to it without any arbitration like we do > today ? > > If the answer is yes, then we are in deep trouble for lots of reason: > > - VGA Arbitration might require us to flip/flop MEM/IO enable bits > - Swapper control as explained earlier unless I can "reserve" a swapper >for each head, that is manage to have one aperture per head > - Engine discipline. What if the client on head 0 (like current X) uses >the engine ? Even if the one on head 1 doesn't, simple framebuffer >accesses can be enough to lock up the card. > - etc > > I think that Jon's dream of having totally independant heads that can > run 2 separate applications is a long way away and we have sort-of to > tie /dev/fb's together, though I don't know how to acheive that in > practice, unless we switch to a new API that can enforce it. The current > fbdev API cannot. This is definitely something to works towards. There is a lot of application for this in schools, libraries, internet cafe, etc. There are several companies selling variations on this. I don't expect an immediate solution but I want to make sure the redesign allows it to be built. > > DRI can do such things afaik (manage several contexts etc...), at least > provides the infrastructure for it. But until all clients are DRI > clients, we have a problem. That means that any direct fb client has to > take over the entire card. All heads. There is simply no choice, and > that doesn't even help with the VGA arbitration issue which still > require explicit lock/unlock around accesses. > > I'm open to suggestions... Can we put in our own fault handler for the mmap, trap the directfb accesses and do the proper locking? > > Ben. > > ___ > xorg mailing list > [EMAIL PROTECTED] > http://lists.freedesktop.org/mailman/listinfo/xorg > -- Jon Smirl [EMAIL PROTECTED] --- 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_id=6595&alloc_id=14396&op=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 Mon, 14 Mar 2005 23:59:37 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote: > 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 working on adding secondary head support on radeonfb. Where does the second buffer go when fbdev is running standalone? > > > 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. If fbdev is running standalone and two heads are active, there has to be some very primitive buffer management going on. This may be as simple as fb0 starts at 0, and fb1 is at the end of CONFIG_APER_SIZE. When DRM loads it can install hooks to a more sophisticated memory manager. > > 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. help me out with the relevant attribute/value pairs for modes > > > 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. There is a 300K OpenGL-ES to framebuffer implementation on sourceforge that someone might get working in this model. There is also a big difference between sharing the system with XGL and an app writen to use fbdev versus supporting an embedded system where only the fbdev app is running. > > -- > Earthling Michel Dänzer | Debian (powerpc), X and DRI developer > Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer > ___ > xorg mailing list > [EMAIL PROTECTED] > http://lists.freedesktop.org/mailman/listinfo/xorg > -- Jon Smirl [EMAIL PROTECTED] --- 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_ide95&alloc_id396&op=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 DÃnzer | 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote: Michel DÃnzer wrote: 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. Well, I thought I'd also point out that this solves the lockups I was experiecing with the r300 driver, too :-) Really ? And you can move cursor freely on r300 without lockups ? This would mean that on r300 this fix is not needed, but rv350 locks up without it. best Vladimir Dergachev Adam --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
[[[ I am also cross posting to xorg mailing list. The e-mail below discusses a RADEONWaitForIdleMMIO() call I put in radeon_mergedfb.c before OUTREGP() calls in cursor functions. The call was needed as OUTREGP() calls INREG() implicitly. However, it turns out that this call breaks on SMP systems with DRI enabled. ]]] On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dänzer wrote: 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. This is probably the easiest. I am unlikely to find time to work on this until the following weekend (have a conference during this one), so I am proposing to comment out the WaitForIdle call in X.org CVS, with appropriate comment and put the fix in later. Of course, if someone beats me to it, I would not complain :) Adam - thank you for patient testing :)) best Vladimir Dergachev * Read/write the registers via MM_INDEX/MM_DATA instead of directly. I'm curious if either of this helps. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: [Announce] New DRIconf version 0.2.3
Felix Kühling wrote: Hi all, I just uploaded a new DRIconf version (0.2.3), which features better support for floating-point ranges like the brilinear option proposed by Roland Scheidegger. There are also a few bug fixes and usability improvements as well as updates and additions to the README file. The new slider widget for the float range works very nice. I do get some crash when exiting the app: TypeError: main_quit() takes no arguments (1 given) But it's not bothering me too much :-). This version is for gtk2. I'm not too keen on keeping the gtk1.2 branch up-to-date. Does anyone still use it? Not currently, I used to use it on SuSE 8.1 though (even the gtk1.2 version was a major pain to install, and I couldn't get the gtk 2 version to work ever, I tried to install some libraries but never succeeded). Not sure if there are many people around which would use bleeding edge drivers on such old distros. --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Michel DÃnzer wrote: 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. Well, I thought I'd also point out that this solves the lockups I was experiecing with the r300 driver, too :-) Adam --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with DRM in latest 2.6-bk
On Tue, 2005-03-15 at 10:53 +1100, Benjamin Herrenschmidt wrote: [snip] > You are using radeonfb ? if yes, try without and let me know. > Just using the basic vga console. > Ben. Andrew --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: use NULL instead of 0
(resend) Fix sparse NULL/0 warning: drivers/char/drm/radeon_state.c:1845:15: warning: Using plain integer as NULL pointer Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= drivers/char/drm/radeon_state.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/char/drm/radeon_state.c~radeon_null ./drivers/char/drm/radeon_state.c --- ./drivers/char/drm/radeon_state.c~radeon_null 2005-02-15 13:48:45.094497640 -0800 +++ ./drivers/char/drm/radeon_state.c 2005-02-15 20:32:14.109168000 -0800 @@ -1842,7 +1842,7 @@ static int free_surface(DRMFILE filp, dr dev_priv->surfaces[s->surface_index].refcount--; if (dev_priv->surfaces[s->surface_index].refcount == 0) dev_priv->surfaces[s->surface_index].flags = 0; - s->filp = 0; + s->filp = NULL; radeon_apply_surface_regs(s->surface_index, dev_priv); return 0; } --- --- 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_id=6595&alloc_id=14396&op=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 DÃnzer | 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_ide95&alloc_id396&op=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
Michel DÃnzer wrote: 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. I don't think it is, very small textures (mipmaps) will have image width of only 32 bytes, not 64 (for 32bit, 2x2 and 1x2 mips). With micro tiling enabled, that is. Maybe it would be simpler to just use the same pitch for source and destination, and simply explicitly remove the tile bits. Roland --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with DRM in latest 2.6-bk
On Mon, 2005-03-14 at 20:49 +, Andrew Clayton wrote: > On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote: > > > Have you tried the most recent kernel? There were some changes to the > > AGP code that caused it to oops for me. Linus took my patch to fix > > that this last weekend. > > > > 2.6.11-bk10 is a slight improvement. > > When X starts the screen goes blank and stays blank... however the > keyboard remains active, though I can't do much, i.e crtl+alt+F1 doesn't > give me a console, but crtl+alt+delete does cleanly reboot the machine. You are using radeonfb ? if yes, try without and let me know. Ben. --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Vladimir Dergachev wrote: On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dïnzer wrote: On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote: Michel DÃnzer 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? It does make sense to me, an easy way to check is to disable merged framebuffer mode in X. If it works fine without merged framebuffer than this is an issue. I am unsure of how to fix it though, as the call *is* needed, we should not be reading from registers with engine busy. Well, I gave it a shot by commenting out that call, per Michel's instructions. SMP + USB + MergedFB + framebuffer, and everything is working fine. I realize that the call is needed, but maybe we should leave it out till it does less damage than it fixes :-) Adam --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote: Michel DÃnzer 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? It does make sense to me, an easy way to check is to disable merged framebuffer mode in X. If it works fine without merged framebuffer than this is an issue. I am unsure of how to fix it though, as the call *is* needed, we should not be reading from registers with engine busy. best Vladimir Dergachev -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
FB model basic issues (WAS: radeon, apertures & memory mapping)
> 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. 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. 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. _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, so that means I have some flexibility. The second head will probably" move on mode switches since I intend to allocate it at the top of the accessible aperture as described by Jon. All of that just keep uncovering more and more issues with our current fbdev model though. From discussions we had so far, it uncovers the problem of arbitration. That is, can we simply afford having a process mmap /dev/fb and blast things to it without any arbitration like we do today ? If the answer is yes, then we are in deep trouble for lots of reason: - VGA Arbitration might require us to flip/flop MEM/IO enable bits - Swapper control as explained earlier unless I can "reserve" a swapper for each head, that is manage to have one aperture per head - Engine discipline. What if the client on head 0 (like current X) uses the engine ? Even if the one on head 1 doesn't, simple framebuffer accesses can be enough to lock up the card. - etc I think that Jon's dream of having totally independant heads that can run 2 separate applications is a long way away and we have sort-of to tie /dev/fb's together, though I don't know how to acheive that in practice, unless we switch to a new API that can enforce it. The current fbdev API cannot. DRI can do such things afaik (manage several contexts etc...), at least provides the infrastructure for it. But until all clients are DRI clients, we have a problem. That means that any direct fb client has to take over the entire card. All heads. There is simply no choice, and that doesn't even help with the VGA arbitration issue which still require explicit lock/unlock around accesses. I'm open to suggestions... Ben. --- 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_id=6595&alloc_id=14396&op=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 DÃnzer wrote: > > On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote: > > > On Sun, 2005-03-13 at 23:28 -0500, Michel DÃnzer 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 DÃnzer | 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_ide95&alloc_id396&op=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 Mon, 2005-03-14 at 17:30 +0100, Soeren Sandmann wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > In an ideal world ... However, since we are planning to move the memory > > manager to the kernel, that would mean a kernel access (syscall, ioctl, > > whatever...) twice per access to AGP memory. Not realistic. > > Could the user space driver batch many such accesses together and use > a lock_many()/unlock_many() API? We may have to use a lock/unlock API anyway due to interaction with the VGA arbiter in fact. If for some reason, the card can't completely disable decoding of VGA and IO space, it needs to bracket any access to the framebuffer with something. That is unuseable for things like MOL though. We are giving the framebuffer to some foreign OS in an emulation shell that doesn't know how to do but blit directly at any time. Oh well, I need to think a bit more about those sceniario. Ben. --- 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_id=6595&alloc_id=14396&op=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 11:20 -0500, Michel Dänzer wrote: > On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote: > > On Sun, 2005-03-13 at 23:28 -0500, Michel Dänzer 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. Ben. --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon, apertures & memory mapping
> > Ok so the problem is byte swapping. Looking at atyfb for example it uses > the "big-endian" aperture on big-endian systems and selects the byte > swapping method according to the bit depth. If that really means that all > host access to the aperture gets byte swapped then I don't see how the > current situation can work correctly for DirectFB. Offscreen surfaces can > use any bit depth and so their bytes could be swapped incorrectly. Makes > me wish I had a PPC box alongside the x86 one. Possibly yes. In X, when blitting to an overlay surface, we save/clear/restore the swapper indeed. I would really like to keep the swappers independant though. Take things like MOL (MacOnLinux). I maps the framebuffer and passes it to MacOS, which expects proper swapping and doesn't (for a basic non-accelerated framebuffer, which is what MOL implements) provide an easy way to set/restore the swapper. Also, doing so would require arbitration between clients using both heads, while 2 independant swappers mean that even if the client wants to temporarily disable it (for uploading an offscreen surface for example), it has it's own swapper and won't conflict with whoever is using the other framebuffer. That means some knowledge about those swappers of course. Note that almost all fbdev's on big endian platforms have some kind of swapping mecanism on accesses, so that's something you'll have to deal with anyway. Ben. --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon, apertures & memory mapping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ville Syrjälä wrote: > Makes me wish I had a PPC box alongside the x86 one. You might like to try http://pearpc.sourceforge.net/. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCNgGnXVaO67S1rtsRAuQ+AKCSkimy2poypyjls7ihX2bgtU6CygCfZJWy aV1iW/PU2lKhe9MleB5+WyE= =wEq+ -END PGP SIGNATURE- --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with DRM in latest 2.6-bk
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote: > Have you tried the most recent kernel? There were some changes to the > AGP code that caused it to oops for me. Linus took my patch to fix > that this last weekend. > 2.6.11-bk10 is a slight improvement. When X starts the screen goes blank and stays blank... however the keyboard remains active, though I can't do much, i.e crtl+alt+F1 doesn't give me a console, but crtl+alt+delete does cleanly reboot the machine. > Paul. > Cheers, Andrew --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2702] r200 driver does not support brilinear texture filtering
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2702 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 12:28 --- (In reply to comment #6) > It's just a nuisance, lots of "if this version, enable that" code. IMHO. You have to check for every feature anyway, it doesn't really matter if they are associated with different minor versions, does it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4337] New: ATI Rage 128: messed up X
http://bugme.osdl.org/show_bug.cgi?id=4337 Summary: ATI Rage 128: messed up X Kernel Version: from at least 2.6.11-bk8 to bk10 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: Debian Sarge (testing) Hardware Environment: i686 (P3) Software Environment: i686 GNU/Linux Problem Description: When X should start, the screen is randomly colored with some kind of grid in bottom 2/3 (top 1/3 black). The cursor is visible and can be moved. Sometimes some parts of eg kdm are painted (eg one button or one edit filed). Its hard to change to console. After that some lines like the following appear in the XFree log: (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025 (EE) R128(0): Idle timed out, resetting engine... And some logs of message: kernel: Linux agpgart interface v0.101 (c) Dave Jones < the version was 0.100 before kernel: agpgart: Detected VIA Apollo Pro 133 chipset ***kernel: agpgart: Maximum main memory to use for agp memory: 203M***< does not appear (but normally does 2.6.11) kernel: agpgart: AGP aperture is 64M @ 0xe000 kernel: [drm] Initialized drm 1.0.0 20040925 kernel: [drm] Initialized r128 2.5.0 20030725 on minor 0: ATI Technologies Inc Rage 128 RF/SG AGP kernel: agpgart: Found an AGP 1.0 compliant device at :00:00.0. kernel: agpgart: Putting AGP V2 device at :00:00.0 into 1x mode kernel: agpgart: Putting AGP V2 device at :01:00.0 into 1x mode I know that the bk are for testing, but this problem now exists for at least 3 of them... If any further information is needed, please tell it... Steps to reproduce: Dont exactly know. I use a ATI Rage 128 with its modules compiled in kernel and a via agp-chip... --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2702] r200 driver does not support brilinear texture filtering
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2702 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 09:42 --- (In reply to comment #5) > What's the problem with bumping the DRM minor version frequently, anyway? There's not really a problem. It will get assigned to a int, so there should be plenty of numbers left :-). It's just a nuisance, lots of "if this version, enable that" code. IMHO. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Michel DÃnzer wrote: On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote: Michel DÃnzer 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? I can't actually try anything till I get home :-) Give me a few hours, and I'll let you know. Adam --- 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_ide95&alloc_id396&op=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 DÃnzer 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 DÃnzer | 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Michel DÃnzer 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? Adam --- 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_ide95&alloc_id396&op=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 Mon, Mar 14, 2005 at 05:30:04PM +0100, Soeren Sandmann wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > In an ideal world ... However, since we are planning to move the memory > > manager to the kernel, that would mean a kernel access (syscall, ioctl, > > whatever...) twice per access to AGP memory. Not realistic. > > Could the user space driver batch many such accesses together and use > a lock_many()/unlock_many() API? Natrually it should try to do as much as possible during the lock()/unlock() sequence. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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_ide95&alloc_id396&op=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
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > In an ideal world ... However, since we are planning to move the memory > manager to the kernel, that would mean a kernel access (syscall, ioctl, > whatever...) twice per access to AGP memory. Not realistic. Could the user space driver batch many such accesses together and use a lock_many()/unlock_many() API? Søren --- 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_ide95&alloc_id396&op=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 DÃnzer 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 DÃnzer | 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_ide95&alloc_id396&op=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 DÃnzer | 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with DRM in latest 2.6-bk
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote: > Andrew Clayton writes: > > > 2.6.11-bk2 OK > > 2.6.11-bk3 Lockup > > Have you tried the most recent kernel? There were some changes to the It was still broken with -bk9. > AGP code that caused it to oops for me. Linus took my patch to fix > that this last weekend. > I'll try -bk10 later today. > Paul. > Cheers, Andrew --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon, apertures & memory mapping
On Sun, Mar 13, 2005 at 11:04:59PM +1100, Benjamin Herrenschmidt wrote: > > > > I must be missing something something obvious because I don't quite > > understand what major drawbacks there are with the non-overlapping mode. > > As I see it you get at least the same amount of CPU accessible memory as > > you get in the overlapping mode. > > Yes, you do, but that means that if the apertures are configured such > that the entire VRAM fits in a single aperture, then you just can't use > the second aperture at all. Which means you can't have separate swapper > setting for both apertures, and thus, can't let two independant > processes access the video memory with different bit depth, at least on > big endian machines unless you do trickery, and play with the swapper > before each access. Ok so the problem is byte swapping. Looking at atyfb for example it uses the "big-endian" aperture on big-endian systems and selects the byte swapping method according to the bit depth. If that really means that all host access to the aperture gets byte swapped then I don't see how the current situation can work correctly for DirectFB. Offscreen surfaces can use any bit depth and so their bytes could be swapped incorrectly. Makes me wish I had a PPC box alongside the x86 one. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Vladimir Dergachev wrote: On Mon, 14 Mar 2005, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Alright... So drm from both February 14th and January 1st are locking up as well... Which is odd since I never had any of these problem till this weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps this isn't directly related to the drm. Oh, I've also flashed my BIOS to the latest from the motherboard manufacturer.. Thought it was worth a shot, but it didn't help. One more piece - I have framebuffer (radeon) enabled in my kernel, do you ? Enabled in the kernel, but disabled on the kernel command line. What happens when you enable it ? I don't know, but I'll give it a shot... Things I want to try when I get home: Xorg CVS + framebuffer + SMP Xorg 6.8.1 + SMP (both with and without the framebuffer) Let me know if there's anything else I should add to the list. Adam --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Alright... So drm from both February 14th and January 1st are locking up as well... Which is odd since I never had any of these problem till this weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps this isn't directly related to the drm. Oh, I've also flashed my BIOS to the latest from the motherboard manufacturer.. Thought it was worth a shot, but it didn't help. One more piece - I have framebuffer (radeon) enabled in my kernel, do you ? Enabled in the kernel, but disabled on the kernel command line. What happens when you enable it ? best Vladimir Dergachev --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
Vladimir Dergachev wrote: Alright... So drm from both February 14th and January 1st are locking up as well... Which is odd since I never had any of these problem till this weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps this isn't directly related to the drm. Oh, I've also flashed my BIOS to the latest from the motherboard manufacturer.. Thought it was worth a shot, but it didn't help. One more piece - I have framebuffer (radeon) enabled in my kernel, do you ? Enabled in the kernel, but disabled on the kernel command line. Here's the results of my testing: 2.6.11 with both the kernel drm and the cvs drm trees from January 1st, February 14th, and this weekend: lockups. 2.6.11.3 with both the kernel drm and this weekends drm: lockups. 2.6.10 with both the kernel drm and this weekends drm: lockups. This one really confuses me as I used 2.6.10 for months without problems. Some lockups come with kernel panics (about IRQ 16 getting disabled) that get logged to the serial port. Some just get the radeon_cp_reset and radeon_cp_start errors. Some lockups are just X locking up (and I can still login on at the serial console or over ssh), others are the entire machine. If I try to reboot my machine after X locks up, my machine will lockup before the reboot is complete. neverputt will consistently lockup (I'd say about 50/50 just X/the whole machine), almost immediately. glxgears will sometimes lockup. glxgears usually runs fine till I move the mouse... The mouse will stutter. If I'm fast enough, and the glxgears window hasn't lost focus, I can quit it and everything returns to normal... I still get the radeon_cp_reset and _start errors, but the machine and X won't lockup. With 2.6.11 and the most recent drm, I was able to play q3a for about 10 minutes... I was getting 30-40 fps, and never experienced a lockup. IRQ 16 is shared with the usb controller. However, even disabling the usb controller in the BIOS doesn't solve the problem. The kernel panic (when it happens/gets logged) is different if the controller is disabled, but the lockups still happen. The *only* lead that I currently have is that building a UP kernel (in both 2.6.11.3 and 2.6.10) gets it working again (with this weekends cvs drm). I haven't had a whole lot of time to test, but neverputt played for about 10 minutes, and moving the mouse when running glxgears doesn't cause any problems. Of course, I'd rather not lose a processor just to get this working :-) Does anyone have any ideas? I have no explanation for why an SMP kernel worked on 2.6.10 for months and has suddenly stopped working upon reinstallation of Debian Unless... In the process of reinstalling, I upgraded Xorg to the latest in CVS. When I get home tonight, I'll revert to 6.8.1 and see how that goes. Adam --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Sunday 13 March 2005 23:46, Adam K Kirchhoff wrote: > Adam K Kirchhoff wrote: > > I really am confused. This was all working (with my 9200) prior to > > reinstalling Debian on my system on Friday. Thankfully it still works > > (with drm 1.15.0) on my FreeBSD installation. Not really sure if that > > tells you anything. > > > Alright... So drm from both February 14th and January 1st are locking > up as well... Which is odd since I never had any of these problem till > this weekend. I'll start rolling back changes to the Mesa dri > driver... Perhaps this isn't directly related to the drm. > > Oh, I've also flashed my BIOS to the latest from the motherboard > manufacturer.. Thought it was worth a shot, but it didn't help. If rolling back the dri driver doesn't help, what about the DDX or even the kernel? cu, Nicolai > Adam pgpIA7614xZrz.pgp Description: PGP signature
Re: Problem with DRM in latest 2.6-bk
On Sun, 13 Mar 2005, Adam K Kirchhoff wrote: While it's possible, it seems unlikely. I did recently upgrade from 2.6.10 to 2.6.11 (about a week before reinstalling Debian)... However, my lockups only ever happen with running a 3D client, not just X. *However,* I've been playing with different kernel options. I went from an SMP kernel to a UP kernel, and no more lockups. I played neverputt for about 10 minutes where, previously, I'd get lockups almost immediately. I'm gonna try an SMP kernel again, just to confirm that I'm still getting lockups. I'll then trying downgrading to 2.6.10 (SMP) to see what happens. Hmm... The latest ivtv-project modules (v0.3.x, cx25840 module) had this problem as well (with lockups that is). Their problem was aggressive stack usage in combination with 4k-stacks turned on. Setting it to 8k-stacks "solved" the problem (well the problem was still there but it took longer until lockup). Could this be related? Just guessing... Best regards Peter K --- 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_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
