Re: [Dri-devel] Multiple VTs with DRI
Jon Smirl wrote: --- Alex Deucher [EMAIL PROTECTED] wrote: As I recall, no. As it is now, only a single instance of Xfree86 can use the DRI. I think it might be possible by adapting the resume code to reinitialize state and agp on a VT switch, however, I may be wrong. Am I right in thinking that suspend/resume and VT switch should be the same piece of code with slightly different behavior? Does the suspend/resume code save all of the texture memory and AGP state? Or does it rebuild it? My first attempt at resume for the radeon resulted in the reinit hack (which Michel has since turned into a fantastic piece of work). This releases all resources at VT switch away and re-initialises them at VT switch-to. With the reinit patch, you would be able to run any number of DRI-using XFree86 instances, but texture memory and AGP state are not saved, they are simply reinitialised. The new resume code doesn't release any resources (so it doesn't allow running multiply DRI-using instances of XFree86) but it re-initialises only hardware at every VT switch. Texture memory is not saved. AGP state is reinitialised. I hope this answers your questions. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Radeon R250, Blender
On Tue, 2003-03-25 at 14:29, Dieter Nützel wrote: Am Dienstag, 18. März 2003 09:57 schrieb Keith Whitwell: Keith Whitwell wrote: Ben Atkin wrote: I just bought a Radeon 9000, for the main intention of using it on Linux. Unfortunately, I didn't take the specific chipset into account, and it appears the card doesn't have the greatest compatibility with linux. I installed XFree 4.3.0 and got DRI working on my Gentoo system. It runs plenty fast, but there is still a little sketchiness here and there, and blender crashes whenever it tries to render. I get the errors: button: 0 blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context == ctx' failed. Aborted I don't know whether this is a DRI problem or not, but does anyone have any idea what this error means, or has anyone gotten around it? It's a DRI problem. I'm told that my recent changes in CVS fix it ... Actually, can anyone confirm this. I didn't think that this was fixed, but Michel said elsewhere it was. dito I've tried the mesa-4-0-4 and trunk-branch on top of my normal XFree86 4.2.1 for SuSE 7.3. Both versions show the bug with VTK demo apps on my SMP system. VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch I feel like a broken record, but this problem _really_ disappeared for me with current DRI CVS. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Radeon R250, Blender
On Tue, 2003-03-25 at 16:26, Dieter Nützel wrote: Am Dienstag, 25. März 2003 15:58 schrieb Charl P. Botha: I feel like a broken record, but this problem _really_ disappeared for me with current DRI CVS. Somewhat more explicit, please. You run DRI CVS (trunk, like me) on 4.3.0? Sorry about that Dieter. :) Yes, I run DRI CVS on 4.3.0. I am also running with Keith's filp patches (because they killed the drmCmdBuffer: -22 nasty I was seeing with multiple context VTK applications) but I remember checking _without_ filp as well, and I could not reproduce the vtxfmt with DRI CVS. I could easily reproduce it with stock 4.3.0. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fallback in radeon_Materialfv() doesnt work
On Tue, Mar 25, 2003 at 11:26:39PM +0100, Felix Kühling wrote:
On Tue, 25 Mar 2003 20:02:24 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Gareth Hughes wrote:
Andreas Stenglein wrote:
Yes, at least the part with GL_TRIANGLE_STRIP.
In case of 0 you can just return 0, no copying is needed.
case 0: return 0; break;
You're going to do that, just in a slightly different manner:
switch (nr) {
case 0: ovf = 0; break;
case 1: ovf = 1; break;
default: ovf = 2; break;
}
This is the same as
ovf = MIN2( nr, 2 );
Nice to see in how many creative ways this can be obfuscated. ;-) So it
was just an off-by-one error in the original version, which was
ovf = MIN2( nr-1, 2 );
Hmmm, this looks very much like it could be the reason for the problems I
reported the other day: http://cpbotha.net/thingies/dri_scapula.png
That scapula consists mostly out of triangle strips. :)
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] rendering errors with current DRI CVS
Dear list, http://cpbotha.net/thingies/dri_scapula.png shows a surface-rendering of a human scapula (shoulder blade). Notice the strange extra edges that I've indicated with grotesque red arrows. http://cpbotha.net/thingies/dri_scapula_wireframe.png is a wireframe rendering of the exact same data. Notice the distinct absence of these extra edges. This is with current DRI CVS on a Radeon M7. With X 4.3.0, it renders perfectly in both cases, i.e. without the edges. I've also tried with both TCL and VTX disabled, I still get the unwanted edges. The application itself is VTK-based. Does anyone have any ideas? Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Radeon R250, Blender
On Tue, 2003-03-18 at 09:57, Keith Whitwell wrote: button: 0 blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context == ctx' failed. Aborted It's a DRI problem. I'm told that my recent changes in CVS fix it ... Actually, can anyone confirm this. I didn't think that this was fixed, but Michel said elsewhere it was. On my setup, this problem went away when I tried the DRI drivers. When I have time again, I'll make sure that applying your fix (at least what Michel thinks is your fix) to 4.3.0 kills the problem as well. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 bug
On Mon, Mar 17, 2003 at 08:34:44PM +0100, Jacek Pop?awski wrote: blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context == ctx' failed. This is fixed in current DRI CVS. In XFree86 4.3 you can work around it by setting the environment variable RADEON_NO_VTXFMT before running your application. I don't know if the real fix is small enough to backport to 4.3. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
On Wed, Mar 12, 2003 at 01:57:03PM +, Keith Whitwell wrote: OK, now that the recycle lockup has been found fixed, I don't see any problems with this patch. Has anyone got any objections to merging it to the trunk? FW(L)IW, you have my vote. As mentioned earlier, your filp work fixes all kinds of nasty problems on my setup. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Thanks again, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote: Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. If we're talking only DRI with your filp-1 changes, I actually have no outstanding threading problems! I seem to recall Dieter having a test case with multiple glxgears and an ipers that broke badly, but he will probably bring that up again. On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). Thanks again, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon_vtxfmt.c assert error
Dear lists, Does any of the DRI developers remember explicitly fixing the: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context == ctx' failed. error that is so often seen running the glthreads mesademo? I seem to remember Keith Whitwell (I *think*) saying that this was on his todo list. Whatever the case may be, I can reproduce this easily on XFree86 4.3.0 but NOT on DRI CVS. I also remember that this bug was still present in DRI CVS a month or two ago, so I'm trying to find out what/who fixed it. If anyone has more information on this, I would be most grateful. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Thu, 2003-02-27 at 16:09, Dieter Nützel wrote: Am Donnerstag, 27. Februar 2003 16:06 schrieb Dieter Nützel: Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell: OK, here's a patch, first attempt at doing this. It's not ready to commit yet, unless we start a branch for this... Things actually work pretty well, and a couple of lockups seem to have disappeared as a result. There are at least two issues: 1) Hard lockup when the X server recycles. 2) This breaks other OS's -- they'll need to play catchup, I think. Could this help? SMP system (dual Athlon) trunk, r200 with flip-1.diff and r200-flushvertices.diff (Michel). Next try: VTK/bin ./TaskParallelism r200AgeTextures 0 r200AgeTextures 1 r200AgeTextures 0 r200AgeTextures 1 TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch Dieter, I was seeing this problem VERY often with VTK multi-context apps and XFree86 4.3.0 RC2 (and before) until I upgraded last night to latest DRI CVS. That problem disappeard. My drmCmdBuffer: -22 problem also disappeared after applying Keith's filp-1.diff. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote: Charl P. Botha wrote: The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context == ctx' failed. at startup however? I haven't reproduced this. Do you see it on UP boxes, or just SMP? glthreads.c seems to work perfectly for me here... With your modified glthreads.c on my Radeon 7500 Mobility with XFree86 4.3.0 RC2 I see this very often. It doesn't happen every time; I would estimate about once in every 5 executes. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote: Charl P. Botha wrote: The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context == ctx' failed. at startup however? I haven't reproduced this. Do you see it on UP boxes, or just SMP? glthreads.c seems to work perfectly for me here... Has anyone reproduced the server-recycle hang I reported earlier? I've changed test machines don't see it any more... First things first: Keith, you rule. :) Now that we've gotten that out of the way: 1. The vtxfmt assert bug disappeared when I upgraded to latest DRI CVS. Thanks DRI people. I was running 4.3.0 RC2, with which I can still reproduce the vtxfmt assert error with Keith's modified glthreads.c. 2. When I applied your new module release method patch, the very longstanding and irritating and evil application-terminating drmCmdBuffer: -22 bug I was still seeing with my large multi-context VTK (Visualization ToolKit) application went away. I have a small wxPython/VTK example with which I can reproduce this (with every execution) on 4.3.0 RC2. If by server-recycle you mean stopping and starting X, I haven't seen any lockups with that. Thank you very much, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Mon, Feb 24, 2003 at 03:06:24PM +, Alan Hourihane wrote: On Sun, Feb 23, 2003 at 12:59:20PM -0700, Keith Whitwell wrote: OK, here's a patch, first attempt at doing this. It's not ready to commit yet, unless we start a branch for this... Things actually work pretty well, and a couple of lockups seem to have disappeared as a result. There are at least two issues: 1) Hard lockup when the X server recycles. 2) This breaks other OS's -- they'll need to play catchup, I think. otherwise, I'm interested in feedback. Looks good Keith. Maybe we can start a branch for this work. Keith, is this related to the problems I reported a day or two back with my/your modified glthreads.c example? I.e., will it also fix the crashes when deleting a single glxcontext in a multi-threaded application, i.e. not only at application exit? Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Mon, Feb 24, 2003 at 11:41:01AM -0700, Keith Whitwell wrote: Charl P. Botha wrote: Keith, is this related to the problems I reported a day or two back with my/your modified glthreads.c example? I.e., will it also fix the crashes when deleting a single glxcontext in a multi-threaded application, i.e. not only at application exit? It may do -- I didn't see problems like you describe -- my fixed version of glthreads let me close individual windows without any hiccups at all. The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context == ctx' failed. at startup however? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] reproducible VTK + DRI breakage
Dear list,
I've attached a wxPython + VTK example (just the
wxVTKRenderWindowInteractor.py slightly modified) to illustrate the
drmCmdBuffer: -22 bug that I'm actually seeing. It seems my glthreads.c
attempts were off the track.
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example. Manipulate the 3D cone in both
windows and then close the one window. Manipulating the remaining 3D cone
for a second or two should result in a drmCmdBuffer: -22 application crash.
If anyone 1. can replicate this or 2. fix it ;) I would be most grateful.
Thanks,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
A VTK RenderWindowInteractor widget for wxPython. Note that wxPython
comes with its own wxVTKRenderWindow in wxPython.lib.vtk. Try both
and see which one works better for you.
Find wxPython info at http://wxPython.org
Created by Prabhu Ramachandran, April 2002
Based on wxVTKRenderWindow.py
Please see the example at the end of this file.
Creation:
wxVTKRenderWindowInteractor(parent, ID, stereo=0, [wx keywords]):
You should create a wxPySimpleApp() or some other wx**App before
creating the window.
Behaviour:
Uses __getattr__ to make the wxVTKRenderWindowInteractor behave just
like a vtkGenericRenderWindowInteractor.
# import usual libraries
import math, os, sys
from wxPython.wx import *
import vtk
# a few configuration items, see what works best on your system
# Use wxGLCanvas as base class instead of wxWindow.
# This is sometimes necessary under wxGTK or the image is blank.
# (in wxWindows 2.3.1 and earlier, the GLCanvas had scroll bars)
try:
WX_USE_GL_CANVAS
except NameError:
if wxPlatform == '__WXMSW__':
WX_USE_GLCANVAS = 0
else:
WX_USE_GLCANVAS = 1
# Keep capturing mouse after mouse is dragged out of window
# (in wxGTK 2.3.2 there is a bug that keeps this from working,
# but it is only relevant in wxGTK if there are multiple windows)
try:
WX_USE_X_CAPTURE
except NameError:
if wxPlatform == '__WXMSW__':
WX_USE_X_CAPTURE = 1
else:
WX_USE_X_CAPTURE = 0
# end of configuration items
if WX_USE_GLCANVAS:
from wxPython.glcanvas import *
baseClass = wxGLCanvas
else:
baseClass = wxWindow
class EventTimer(wxTimer):
def __init__(self, iren):
wxTimer.__init__(self)
self.iren = iren
def Notify(self):
self.iren.TimerEvent()
class wxVTKRenderWindowInteractor(baseClass):
A wxRenderWindow for wxPython.
Use GetRenderWindow() to get the vtkRenderWindow.
Create with the keyword stereo=1 in order to
generate a stereo-capable window.
def __init__(self, parent, ID, *args, **kw):
# private attributes
self.__OldFocus = None
self.__RenderWhenDisabled = 0
# First do special handling of some keywords:
# stereo, position, size, width, height, style
stereo = 0
if kw.has_key('stereo'):
if kw['stereo']:
stereo = 1
del kw['stereo']
position = wxDefaultPosition
if kw.has_key('position'):
position = kw['position']
del kw['position']
size = wxDefaultSize
if kw.has_key('size'):
size = kw['size']
del kw['size']
if kw.has_key('width') and kw.has_key('height'):
size = (kw['width'], kw['height'])
del kw['width']
del kw['height']
# wxWANTS_CHARS says to give us e.g. TAB
# wxNO_FULL_REPAINT_ON_RESIZE cuts down resize flicker under GTK
style = wxWANTS_CHARS | wxNO_FULL_REPAINT_ON_RESIZE
if kw.has_key('style'):
style = style | kw['style']
del kw['style']
# the enclosing frame must be shown under GTK or the windows
# don't connect together properly
l = []
p = parent
while p: # make a list of all parents
l.append(p)
p = p.GetParent()
l.reverse() # sort list into descending order
for p in l:
p.Show(1)
# initialize the wxWindow
baseClass.__init__(self, parent, ID, position, size, style)
# create the RenderWindow and initialize it
self._RenderWindow = vtk.vtkRenderWindow()
try:
self._RenderWindow.SetSize(size.width, size.height)
except AttributeError:
self._RenderWindow.SetSize(size[0], size[1])
if stereo:
self._RenderWindow.StereoCapableWindowOn()
self._RenderWindow.SetStereoTypeToCrystalEyes()
self.__Created = 0
# Tell the RenderWindow to render inside the wxWindow.
if self.GetHandle():
self.__Created = 1
self._RenderWindow.SetWindowInfo(str(self.GetHandle
Re: [Dri-devel] remaining (reproducible) problems with 4.2.99.902 on Radeon M7
On Sat, Feb 22, 2003 at 12:00:03PM -0700, Keith Whitwell wrote: 3. A good old segfault: Program received signal SIGSEGV, Segmentation fault. This occurs because you have modified the X event loop to destroy a context that *IS STILL IN USE* in another thread. GL doesn't provide any guarantees about what will happen if you try to do this... Whoops, I see that now. One way to achieve something like what you want would be to make ExitFlag an array, and destroy the context at the end of draw_loop. I've attached something that does this. This doesn't solve all of your problems, though - I'm still looking at them. I was more concerned with the other two (drmCmdBuffer: -22 and the vtx assert error) in anycase, as I see them daily whilst using a VTK based application. Thanks very much for looking into this! Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
On Sat, Feb 15, 2003 at 01:32:09AM +, Alan Hourihane wrote: On Fri, Feb 14, 2003 at 04:37:31 -0500, David Dawes wrote: I meant to add that it'd be good if something along the lines of Michel Dnzer's work to allow DRI to be reinitialised at VT switch was added in after 4.3. I'm curious why it didn't made it into the DRI trunk already. Michel's is good work, there's probably no reason that it shouldn't have been committed already. But I would like to see if we can make it more generic and work for the other DRI drivers too. I'm going to nitpick, so have a look at this posting: http://sourceforge.net/mailarchive/message.php?msg_id=1874234 In short, I also consider this to be Michel's work now, but the original idea and implementation were both mine. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI error messages...
On Mon, 2003-02-03 at 11:50, Adam K Kirchhoff wrote: Do we know the causes of these error messages: drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) I don't get them often when running apps under Linux, or native FreeBSD apps under FreeBSD, but they're pretty common when running Linux apps under FreeBSD. Given that I *have* seem them when playing Q3A under Linux, I'm assuming that they're not exclusively related to running linux apps under FreeBSD. I've been seeing the drmRadeonCmdBuffer: -22 for a very long time with both DRI and XFree86 CVS. I used to be able to reproduce it by starting up multiple glxContexts in a multi-threaded app and then destroying them. I haven't checked this recently though. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] VBE calls for TV-out on Radeon M7
Dear list (and especially those with access to NDA'd ATI specs), I've been trying to get the TV-out of my Radeon M7-P (7500 Mobility) going, but to no avail. I've read all postings and googled all googlings with no ready answers. I merged the TV-out activation/querying from the GATOS development branch radeon_driver.c with atitvout (http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/) also with little success. It seems that some of the VBE calls are different between Radeon and Radeon 7500 mobility. Could someone who might have access to NDA'd ATI specs for the Radeon M7-P check the atitvout source? It's terribly simple, it makes use of LRMI to make real mode interrupt calls into VBE and the relevant file is radeon.c, so it all comes down to the setting up of a few x86 registers and calling int10. Thanks for any information, Charl ps I am subscribed to dri-devel but not to gatos-devel, so CCs would be greatly appreciated. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PROBLEM: 2.4.{19,20} fails to resume if radeon.o is loaded
On Sat, Dec 14, 2002 at 06:04:06PM -0800, [EMAIL PROTECTED] wrote: after about a dozen reboots and half a dozen fscks, I finally was able to pinpoint the reason of why my laptop (ThinkPad X22 (2662XXK)) wasn't able to resume after suspend. The DRM module 'radeon.o' somehow prevents a successful resume (but not the suspend). Only after I made that module unavailable to the modutils, my laptop now successfully completes suspend/resume cycles. http://www.google.com/search?q=dri+radeon+resume Yields: http://cpbotha.net/dri_resume.html This is applicable only if you're interested in suspending/resuming with active DRI, which it doesn't seem you are. So it's just FYI :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa/DRI version for XFree86 4.3
On Thu, Dec 12, 2002 at 11:43:03AM -0700, Brian Paul wrote: Michel Dänzer wrote: On Don, 2002-12-12 at 15:29, Martin Spott wrote: XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time constraints and stability concerns. [...] I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you chose for XFree86-4.3, I'd mostly agree, but I guess the floating point exceptions are showstoppers. It's still not clear what the cause of this is. I've heard two possibilities: 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with a command line switch. 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last month. Neither of these explain the sigfpe that Andreas Stenglein and I have been experiencing. Both of us have been building with gcc 2.95: this eliminates 1. In addition, I have confirmed that I've been running the fixed code: this eliminates 2. See (a.o.) the mail with subject: Re: [Dri-devel] Re: Radeon: lockup on state change Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon DRI resume - submission to XFree86 CVS
As discussed in the mail below, herewith a submission of the Radeon DRI suspend/resume patch for your review. I've updated it to and tested it with current XFree86 CVS. FYI, this patch enables complete suspend to/resume from disk with Radeon chipsets with active DRI (and also running 3D-accelerated and Xv clients). More information is available at http://cpbotha.net/dri_resume.html Thanks, Charl - Forwarded message from David Dawes [EMAIL PROTECTED] - From: David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Dri-devel] Radeon DRI Resume - quo vadis? X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: dri-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=dri-devel X-Original-Date: Tue, 10 Dec 2002 21:09:27 -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: X-Keywords: X-UID: 363 On Tue, Dec 10, 2002 at 01:45:09PM +0100, Charl P. Botha wrote: On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote: One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? At the moment it's called from RADEONEnterVT() in radeon_driver.c - so the code is called after every VT switch. During normal operation this doesn't cause any problems as it's idempotent. I would prefer hooking it more specifically to a power event... however, last time I checked the infrastructure for non-APM power events didn't seem to be ready. Many people are using this on ACPI-only laptops with swsusp for software suspension. If you're restoring HW state required for the correct operation of the driver, and especially if it's state that something else driving the video card might change while the X server doesn't have control over it, then it should be done from EnterVT(). As a general rule, any HW state that's set in ScreenInit() should also be set in EnterVT(). By default, XFree86 handles APM events via EnterVT/LeaveVT. It's possible for a driver to provide a separate function to handle PM events, but in most cases it shouldn't be needed. I just had another look at your patch, and I didn't see any obvious problem with the way it's structured. Send it to [EMAIL PROTECTED], and Kevin Martin can review it. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes - End forwarded message - -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ Index: drivers/ati/radeon.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h,v retrieving revision 1.32 diff -u -r1.32 radeon.h --- drivers/ati/radeon.h2002/10/31 18:06:59 1.32 +++ drivers/ati/radeon.h2002/12/12 18:45:10 @@ -566,12 +566,15 @@ extern int RADEONMinBits(int val); extern voidRADEONInitVideo(ScreenPtr pScreen); - +/* added by [EMAIL PROTECTED] so that we can call this function from + * radeon_driver.c to get xvideo working after a resume from disc/ram */ +extern voidRADEONResetVideo(ScrnInfoPtr pScrn); extern voidR300CGWorkaround(ScrnInfoPtr pScrn); #ifdef XF86DRI extern BoolRADEONDRIScreenInit(ScreenPtr pScreen); extern voidRADEONDRICloseScreen(ScreenPtr pScreen); +extern voidRADEONDRIResume(ScreenPtr pScreen); extern BoolRADEONDRIFinishScreenInit(ScreenPtr pScreen); extern drmBufPtr RADEONCPGetBuffer(ScrnInfoPtr pScrn); Index: drivers/ati/radeon_common.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h,v retrieving revision 1.1 diff -u -r1.1 radeon_common.h --- drivers/ati/radeon_common.h 2002/10/30 12:52:13 1.1 +++ drivers/ati/radeon_common.h 2002/12/12 18:45:10 @@ -70,6 +70,7 @@ #define DRM_RADEON_INIT_HEAP 0x15 #define DRM_RADEON_IRQ_EMIT 0x16 #define DRM_RADEON_IRQ_WAIT 0x17 +#define DRM_RADEON_CP_RESUME 0x18 #define DRM_RADEON_MAX_DRM_COMMAND_INDEX 0x39 Index: drivers/ati/radeon_dri.c === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v retrieving revision 1.22 diff -u -r1.22 radeon_dri.c --- drivers/ati/radeon_dri.c2002/11/25 14:04:57 1.22 +++ drivers/ati/radeon_dri.c2002/12/12 18:45:10 @@ -1559,6 +1559,86 @@ return TRUE
[Dri-devel] Re: [Swsusp] Re: new DRI resume binary snapshots and patchesavailable
On Wed, 2002-12-11 at 10:38, Juan Quintela wrote: could you told me what X version against are your dri patches? I am having a bad time (not being an XFree hacker) to merge the X part of your patch (the kernel patch was a no brainer). Basically my problem is that there is not: - ati/radeon_common.h file (and I didn't found any of the other DRM_RADEON_* diffs). - in the radeon_dri.c::RADEONDRIResume() has a call to +_ret = drmCommandNone(info-drmFD, DRM_RADEON_CP_RESUME); I am completely unable to find that command in my XFree tree :( I am using XFree86-4.2.1-11mdk. We used the gatos patch, but old ati code don't have either that function :( I have clarified the web page (http://cpbotha.net/dri_resume.html) somewhat. The patch is very specifically for DRI CVS and NOT for 4.2.x. I don't think it'll work on 4.2.1 to tell you the truth. Soon I am going to make sure that it applies cleanly on XFree86 HEAD CVS as well for possible submission into the repository. Those will be your two options then: either XFree86 DRI CVS or XFree86 HEAD CVS. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI resume erratum
Dear lists, It seems that there are some problems with the latest Radeon DRI resume binary snapshots on http://cpbotha.net/dri_resume.html - these correspond to v6 of the resume patch. There is nothing wrong with the patch, but installing the binary snapshots over an XFree86 4.2.x installation seems to cause problems with applications that use Xft/XRENDER and is thus not recommended. I have reverted the available download to pre XFree86 HEAD merge snapshots, i.e. 20021012 and these have proven to work well when installed over a 4.2.x installation. If you're experiencing trouble with 20021203 over 4.2.x, please downgrade. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon DRI Resume - quo vadis?
Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Tue, 2002-12-10 at 11:59, Felix Kühling wrote: On Tue, 10 Dec 2002 10:37:07 + Keith Whitwell [EMAIL PROTECTED] wrote: Charl P. Botha wrote: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. As far as I can tell it is a bug in gcc if you get mmx instructions in normal output. It would break the kernel. As a test I once compiled my kernel with gcc-3.2 -S and grepped for %mm. All I found was some inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems is to compile with -mno-mmx -mno-3dnow. The use of SSE for normal floating point operations is another thing, though. But according to gcc-3.2 docs -mfpmath=387 should be the default. This was built with gcc 2.95 (and there's no trace of a newer gcc on the system) so these 3.2 problems should not be an issue. I'll try and disassemble the offending instructions tonight as per Keith's advice. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
On Tue, 2002-12-10 at 13:13, Alan Hourihane wrote: I haven't looked at it in a while. Is there a link to it ? http://cpbotha.net/files/dri_resume/xfree86-dri-resume-v6.patch applies cleanly to current DRI CVS. http://cpbotha.net/dri_resume.html has some miscellaneous information. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote: One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? At the moment it's called from RADEONEnterVT() in radeon_driver.c - so the code is called after every VT switch. During normal operation this doesn't cause any problems as it's idempotent. I would prefer hooking it more specifically to a power event... however, last time I checked the infrastructure for non-APM power events didn't seem to be ready. Many people are using this on ACPI-only laptops with swsusp for software suspension. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 12:53:51PM -0800, Ian Romanick wrote: On Tue, Dec 10, 2002 at 10:31:08AM +0100, Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? My memory is a little bit fuzzy on this. Did this patch also allow users to change their DRM module and radeon_dri.so file while vt switched? That is, update drivers w/o restarting X? No. You're thinking of the DRI ReInit patches which I started with an ugly kludge and Michel Dänzer subsequently turned into a very good solution for swapping out agpgart and the radeon DRM without restarting X. As a side-advantage, it also allows suspending/resuming, at least if no DRI-clients are running. The patch I'm talking about above is much simpler however. It performs a hardware-only re-initialisation at VT entry so that suspend/resume works even with running DRI-clients and Xv applications. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Mon, Dec 09, 2002 at 09:56:50PM +0100, Andreas Stenglein wrote: (LAVA and OpenGL Spectrum Analyzer) I think any multi-threaded OpenGL-app should trigger my bug if it draws enough (more than a cube). disabling VTXFMT helps: no lockups anymore, everything works fine, but I have to disable SSE, too, otherwise I would get a sigfpe on my athlonXP1700+ FWIW, I get those SSE sigfpe's too with my Northwood P4 if I don't set MESA_NO_SSE=1. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote: Charl P. Botha wrote: On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: There's a fix for this in recent cvs: /* Mask out highest bit, which is used by AMD for 3dnow * Newer Intel have this bit set, but do not support 3dnow */ AND_L ( CONST(0X7FFF), EAX) I still could reproduce this SIGFPE with yesterday's CVS. I just did a grep though all the .c and .h files in my DRI CVS tree for Mask out highest bit but could not find the above. In which file should this be? xc/extras/Mesa/src/X86/common_x86_asm.S Okay, I just checked and I can still reproduce a SIGFPE with today's CVS. I've made doubly sure that the new libGL is used. Here is a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so #1 0x0840b6a0 in ?? () #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174) at t_vb_vertex.c:286 #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154 #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089 #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:399 #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:424 #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:493 #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60) at t_imm_api.c:77 #9 0x4241e5f1 in _tnl_Vertex3f (x=39.208, y=46.792, z=17) at t_imm_api.c:834 #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657, y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660, diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0) at /home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113 DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any ideas? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Xft (RENDER?) + 4.2.0 + DRI binary snapshots == signal 11
Dear list, Can anyone (especially those running a current DRI binary snapshot installed over an XFree86 4.2.0 installation) confirm an X crash (signal 11) reproducible by starting any Xft-using application, i.e. anything that renders anti-aliased fonts? E.g. on my laptop xterm -fa mono does the trick. Any information on this would be greatly appreciated... I know that just installing a CVS build would work, but I like to know that the binary snapshots also work. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] new DRI resume binary snapshots and patches available
Dear lists, New binary snapshots of the DRI suspend/resume modified Radeon drivers are available at http://cpbotha.net/dri_resume.html - these are the first DRI suspend/resume driver snapshots since the merge of XFree86 HEAD into the DRI tree. The updated patches are of course also available at the mentioned URL. For those who don't know: these are modifications to the DRI Radeon drivers which allow you to suspend to and resume from disc whilst running a 3D-capable X, even whilst running hardware-accelerated 3D applications. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Possible problems with post-merge snapshots
Dear list (and especially José), This is a heads-up regarding post-merge DRI driver snapshots. I tried building binary snapshots of my resume things yesterday in a post-merge tree which is why I ran into these issues. 1. It seems the XFree86 module ABI version has been bumped upwards. This means that snapshots as they are currently made will NOT work when installed over an existing XFree86 4.2 installation as the XFree86 will complain of an ABI version mismatch when trying to install the new modules. If one were to ship the XFree86 binary (I briefly experimented with this) it complains about the OLD 4.2 modules it has to load and also terminates. The snapshots are incredibly handy, so it would be nice to work around this. I was planning to try and bundle all loadable modules as well as the XFree86 binary, but haven't had the time yet. 2. Due to changes in the build configuration, just applying http://dri.sourceforge.net/snapshots/scripts/dri-xfree86.sed and building won't work, as the build system tries to build bunches of libraries that are not part of the DRI CVS tree. I hacked around this as I bundle libGLU with my driver packages as well. HTH, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible multiple glx context bug
On Wed, Oct 23, 2002 at 07:56:28AM +0100, Keith Whitwell wrote: Ian Romanick wrote: On Wed, Oct 23, 2002 at 12:27:57AM +0200, Charl P. Botha wrote: On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote: On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote: Run glthreads with something like: glthreads -n 5 Here's an additional data point. If you move the call to glXDestroyContext to the end of draw_loop (and delete the other two calls), the program works as expected on the Radeon. The event_loop won't terminate, but I leave fixing that trivial bug as an exercise for the reader. :) Hrmmm, interesting. The reason I made this is to reproduce a bug in a much larger application where that kind of control (taking glxDestroyContext() INto the thread) is quite difficult. Ian, do you consider this to be a bug? It's a bug somewhere. :) I'm going to have to dig more before I can determine if the bug is in the app, the driver, or both. Brian or Keith: Do either of you have an opinion about this? Certainly a bug. First thing of concern is whether it's the vtxfmt/codegen stuff which isn't threadsafe, but should get turned off at the first sign of multithreading. I just tried this with RADEON_TCL_FORCE_DISABLE=1, RADEON_NO_VTXFMT=1 and RADEON_NO_CODEGEN=1 and I can still reproduce the bug. Are any other bells ringing? This is with a DRI CVS checkout just before Alan Hourihane's great merge work. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] buglet in quicksort.cc
xc/lib/GLU/libnurbs/nurbtess/quicksort.cc has a double definition of swap(). Could someone with CVS access fix this? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible multiple glx context bug
On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote: On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote: Run glthreads with something like: glthreads -n 5 Here's an additional data point. If you move the call to glXDestroyContext to the end of draw_loop (and delete the other two calls), the program works as expected on the Radeon. The event_loop won't terminate, but I leave fixing that trivial bug as an exercise for the reader. :) Hrmmm, interesting. The reason I made this is to reproduce a bug in a much larger application where that kind of control (taking glxDestroyContext() INto the thread) is quite difficult. Ian, do you consider this to be a bug? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Thu, Oct 17, 2002 at 11:17:39AM -0600, Marc Aurele La France wrote: On 17 Oct 2002, Michel Dänzer wrote: On Don, 2002-10-17 at 04:50, David Dawes wrote: On Tue, Oct 15, 2002 at 12:28:27AM +0200, Charl P. Botha wrote: On Mon, Oct 14, 2002 at 04:14:22PM -0600, Marc Aurele La France wrote: On Tue, 15 Oct 2002, Charl P. Botha wrote: This would mean that the bug is back and people will again have the stupid No, it doesn't. VT switch lockup. What would be the New and Improved Way(tm) way of explicitly re-enabling bus-mastering at RADEONEnterVT() time since xf86EnablePciBusMaster() has been deprecated? Just like the change notice says: When a PCI device is enabled, it's bus mastering is also enabled. This occurs before any driver code is executed. I'm running the DRI tree, so I can't test. However, we still don't know why these cards disabled bus mastering at VT switches (when it was very clearly enabled before the switch), so what guarantees that they won't still do this? Mike (Harris), do you have one of the affected cards running XFree86 HEAD? No, the X server restores changes is makes to the PCI state when it gives up control of the console, so if bus mastering wasn't enabled *before* the X server started, it won't be after VT switching away. Several drivers had bugs where they didn't re-enable it when switching back. Drivers shouldn't assume anything more about the HW state after returning from a VT switch than they would at startup, but unfortunately some still do... Marc's change means that drivers don't need to care about bus mastering being enabled because it will now be enabled automatically for PCI cards that are being used by the X server. Sounds good, unfortunately it doesn't seem to work for the original poster - any idea why? Charl P. Botha did not actually try it. Thus, the key word in your sentence above remains seem. Sorry for the long quote above, but this should be almost the last mail in this thread. I've tested with CVS XFree86, and all is well. Bus mastering gets disabled when switched to VT but gets enabled again when switching back to X. The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is called from that re-enables bus mastering after a VT switch. Thanks and my apologies for the upset. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Thu, Oct 17, 2002 at 02:51:57PM -0600, Marc Aurele La France wrote: The question on my, and David's, mind is whether or not bus mastering was enabled on server entry. According to lspci, it was definitely enabled. Thanks and my apologies for the upset. Indeed. In the future, please differentiate between real and perceived problems. Please excuse me for having spent a frustrating two weeks of my time previously to try and find this problem and present a solution which, at that time, fixed VT switches for quite a number of ATI users. This should be seen in the context of the fact that this problem was known about and nobody else was able to/was willing to spend the time to find a suitable solution. Please also excuse me for getting a little concerned at your changes and the very cryptic CVS log message that you took time to submit. I would also like to thank you for the decidedly unclear reply you sent to the mail in which I voiced my concern. If I were you, I would simply have sent a mail clearing up the confusion (have a look at David's mail if you would like to know how this is done) and thus politely stopping that whole thread, but that's just me. Thanks again, -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snapshots now being built with gcc 3.2
On Fri, 2002-09-27 at 04:25, Andy Dustman wrote: Still getting the same problem with the r200. Interestingly, the amount of memory used for textures has gone up recently, from about 93 MB to 113 MB. Most obvious feature of this is what looks like a NULL pointer reference at the end. Also there is a load/unload/load of the xaa module. (WW) module minor version (0) is less than the required minor version (1) Hmmm, Michel, is this what you expect? Andy, you can download from my site http://cpotha.net/dri_resume.html my latest snapshot just for the included libxaa.a and libGL* - copy these out over your dri.sf.net installation. One other thing: There is a variable in the dripkg.sh script, PKG_MINIMAL=1, which is causing GL and core libraries not to be included the snapshot. Commenting this out reveals that the non-shared libraries are not getting built anyway. As above, you can get more up to date libGL.* thingies from my snapshot. HTH, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multitexturing slowness
On Thu, Sep 26, 2002 at 05:38:03PM +0200, Michel Dänzer wrote: That does get rid of the slowness, thanks. This begs the question: does it use multitexturing for anything except lightmaps? :) It does seem to look nicer... I don't want to be a pedant, but often I can't resist. Begging the question is an often misunderstood and misused phrase: http://skepdic.com/begging.html :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] patch radeon-20020923 hangsxfree4.2 on ati radeon M7
On Tue, 2002-09-24 at 11:56, Adam Duck wrote: Charl == Charl P Botha [EMAIL PROTECTED] writes: I've just check snapshot radeon-20020924 and same situation. I can run programs except those which create new window. For example: xinit /usr/X11R6/bin/xeyes is fine, when: xinit /usr/X11R6/bin/xterm crashes X server with SIGSEGV. Charl Hi Pere! :) Charl Guys, please search the archives before posting: Charl http://sourceforge.net/mailarchive/forum.php?thread_id=1104106forum_id=7177 I just wanted to say that just inserting the two Option strings into my Screen-section didn't solve the problem. I have leeched your binaries and have just copied libxaa.a over my previous one. And it works! Although the installation was a bit of a hassle, thank you all Hah clever! I wanted to suggest this as possible workaround, but thought it was too much hassle. So, in short: * install latest snapshot from dri.sf.net * get dri-resume snapshot from http://cpbotha.net/dri_resume.html and extract libxaa.a from it * copy libxaa.a into /usr/X11R6/lib/modules This is of course unless you just use my snapshot which is identical to DRI CVS except that it has some extra code for suspending/resuming that gets activated during switchVTs. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XAA versioning?
On Sun, Sep 22, 2002 at 10:33:15PM +0200, Michel Dänzer wrote: Several people on IRC reported crashes in the 2D code with the current trunk snapshots. I realized they are due to the TwoPoint acceleration functions depending on XAA changes. How can we handle this, bump the XAA version and disable those functions if it's too old? Meanwhile, users should be able to work around the problem with Option XaaNoSolidTwoPointLine Option XaaNoDashedTwoPointLine It's probably also a good idea to modify the binary snapshot tarballs on dri.sf.net to include an up-to-date libxaa.a. I've already done this on the latest snapshot from http://cpbotha.net/dri_resume.html - it obviously solves the crash problem for users without changes to the config. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 11:18:59PM +0200, Charl P. Botha wrote: I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in throwing away all my data) kernel a shot to see whether updates to agpgart make any difference. This experiment wasn't successful either. I tried with numerous different configs (radeon and agpgart modules, agpgart in kernel radeon module, both in kernel) but could still reproduce the switch to VT and back freeze every time. Thinking that the LockHeld semaphore which was added to i810_driver.c (as well as i830) to prevent syncs when DriLock hadn't been called was relevant (it was reported that this had caused hangs on VT switches on those chipsets) I implemented this locking in radeon_driver.c and radeon_dri.c as well. Still no luck... Does anyone have any other ideas? Best regards, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
Dear list, On Thu, Jul 18, 2002 at 07:04:25PM +0200, Charl P. Botha wrote: Thinking that the LockHeld semaphore which was added to i810_driver.c (as well as i830) to prevent syncs when DriLock hadn't been called was relevant (it was reported that this had caused hangs on VT switches on those chipsets) I implemented this locking in radeon_driver.c and radeon_dri.c as well. Still no luck... I built XFree86 from the DRI tree with -g as well as #define GlxBuiltInRadeon YES in the host.def in order to try and get an almost usable backtrace. After having crashed X by switching to VT and back (at least this is 100% reproducible) I attached to the process with gdb (ssh'd from another machine). I've attached the backtrace... it has a tad more detail than normal, but is there a way to get something a little more verbose? Maybe this shakes some marbles in some of the developers' heads (in a most pleasant manner, of course). Any more ideas would be greatly appreciated, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ (gdb) bt #0 0x40118054 in ioctl () from /lib/libc.so.6 #1 0xfc02 in ?? () #2 0x083b6f60 in ?? () #3 0x08533a6f in ?? () #4 0x0858eec0 in ?? () #5 0x08163c0b in miSpriteGetImage (pDrawable=0x881b7b8, sx=2, sy=7, w=16, h=16, format=2, planemask=4294967295, pdstLine=0xb454 À'\t) at misprite.c:494 #6 0x085c7c22 in ?? () #7 0x080b201f in DoGetImage (client=0x8755d88, format=2, drawable=6291997, x=2, y=7, width=16, height=16, planemask=4294967295, im_return=0x0) at dispatch.c:2256 #8 0x080b21db in ProcGetImage (client=0x8755d88) at dispatch.c:2350 #9 0x080aea86 in Dispatch () at dispatch.c:462 #10 0x080beb3b in main (argc=5, argv=0xbbb4, envp=0xbbcc) at main.c:454
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 01:04:38AM +0200, Michel Dänzer wrote: On Tue, 2002-07-16 at 23:02, Charl P. Botha wrote: Option AGPMode 2 Does 1x make a difference? 1x makes no difference; still X freezes after a switch to VT and back. # Option ForcePCIMode On # not supported by DRI yet The code is there but not enabled on x86 yet. Can you try with it enabled? You need to define PCIGART_ENABLED both in the DRM and the 2D driver. It would also be interesting to know how it works besides VT switching, see that other thread. Beware that it used to be unstable and may still crash, but I guess you've gotten used to that. ;) Thanks to ext3 crashes aren't HALF as painful as they used to be. ;) I will try with PCIGART_ENABLED this evening when I get home (I don't have the laptop with me). I'm also planning to give 2.5.25 a shot at some stage to see if updates to the AGPGART change things. Thanks for your input! Best regards, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 09:38:54AM +0200, Charl P. Botha wrote: On Wed, Jul 17, 2002 at 01:04:38AM +0200, Michel Dänzer wrote: The code is there but not enabled on x86 yet. Can you try with it enabled? You need to define PCIGART_ENABLED both in the DRM and the 2D driver. It would also be interesting to know how it works besides VT switching, see that other thread. Beware that it used to be unstable and may still crash, but I guess you've gotten used to that. ;) Thanks to ext3 crashes aren't HALF as painful as they used to be. ;) I will try with PCIGART_ENABLED this evening when I get home (I don't have the laptop with me). I'm also planning to give 2.5.25 a shot at some stage to see if updates to the AGPGART change things. Okay, I updated my DRI CVS checkout, made sure PCIGART was enabled in radeon_dri.c and the DRM sources and rebuilt both the kernel module and the radeon_drv.o module. X starts up, the bottom half of the screen is painted with a rubbish pattern and the top-half remains black. Once again, I have control of the mouse pointer, but otherwise can perform no input. Shutdown time... I checked the XFree86.log, and ForcePCIMode is definitely being honoured. I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in throwing away all my data) kernel a shot to see whether updates to agpgart make any difference. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
On Tue, Jul 16, 2002 at 01:58:29PM -0600, Keith Whitwell wrote: In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Here's mine (Radeon M7-P, i.e. Mobility 7500, i.e. LW): Bus 1, device 0, function 0: Non-prefetchable 32 bit memory at 0xe810 [0xe810]. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon switch to VT and back X freeze
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody system
with a Radeon driver snapshot of 20020715 as kindly supplied by dri.sf.net.
The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
and a Northwood P4.
So far, the DRI works wonderfully. glxgears yields a *very* impressive 1700
- 1800 FPS (with EnablePageFlip). However, when I switch to a VT (which
works) and then back, the X display mostly restores itself (some colour
artifacts, almost like we're seeing parts of some back buffer, which we're
not) but then promptly stops responding. I can still move the mouse
pointer, but that's it. X consumes 100% cpu according to top. I have to
shutdown at this point.
What I've tried so far:
- CVS checkout of DRI source and various crackpot hacks and experiments by
myself, mostly in RADEON{Enter,Leave}VT
- running X without DRI (by e.g. not modprobing the agpgart module) allows me
to switch to VTs and back to my heart's content; I need DRI however.
- various different kernel versions and configurations (currently at
2.4.19 with acpi 20020611 and swsusp patches; have tried without, no
success: ACPI is quite important though to keep this 2GHz desktop CPU cool)
- with and without radeonfb, with and without UseFBDev
- some of the radeon driver switches (e.g. CPPIOMode and ForcePCIMode)
- and more voodoo and late night craziness which I can't remember all that
well
To help make this a usefull sample point, I've attached the output of lspi
and lsmod, as well as XF86Config-4, XFree86.log and proc_interrupts.
BTW, I see no interrupt assigned to the Radeon, is this normal?
Regards,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon switch to VT and back X freeze
Err, I forgot those attachments. Here they are, along with the complete
mail for future reference:
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody system
with a Radeon driver snapshot of 20020715 as kindly supplied by dri.sf.net.
The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
and a Northwood P4.
So far, the DRI works wonderfully. glxgears yields a *very* impressive 1700
- 1800 FPS (with EnablePageFlip). However, when I switch to a VT (which
works) and then back, the X display mostly restores itself (some colour
artifacts, almost like we're seeing parts of some back buffer, which we're
not) but then promptly stops responding. I can still move the mouse
pointer, but that's it. X consumes 100% cpu according to top. I have to
shutdown at this point.
What I've tried so far:
- CVS checkout of DRI source and various crackpot hacks and experiments by
myself, mostly in RADEON{Enter,Leave}VT
- running X without DRI (by e.g. not modprobing the agpgart module) allows me
to switch to VTs and back to my heart's content; I need DRI however.
- various different kernel versions and configurations (currently at
2.4.19 with acpi 20020611 and swsusp patches; have tried without, no
success: ACPI is quite important though to keep this 2GHz desktop CPU cool)
- with and without radeonfb, with and without UseFBDev
- some of the radeon driver switches (e.g. CPPIOMode and ForcePCIMode)
- and more voodoo and late night craziness which I can't remember all that
well
To help make this a usefull sample point, I've attached the output of lspi
and lsmod, as well as XF86Config-4, XFree86.log and proc_interrupts.
BTW, I see no interrupt assigned to the Radeon, is this normal?
Regards,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW
02:04.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22 1394a-2000 Controller
02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
02:07.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
Module Size Used byNot tainted
i810_audio 19968 1
ac97_codec 9344 0 [i810_audio]
radeon 96952 2
agpgart20064 3
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type man XF86Config-4 at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the ### BEGIN DEBCONF SECTION line above, and/or after the
# ### END DEBCONF SECTION line below.
#
# To change things within the debconf section, run the command:
# dpkg-reconfigure xserver-xfree86
# as root. Also see How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz.
Section Files
# FontPathunix/:7100# local font server
# if the local font server has problems, we can fall back on these
FontPath/usr/lib/X11/fonts/misc
FontPath/usr/lib/X11/fonts/cyrillic
FontPath/usr/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/lib/X11/fonts/Type1
FontPath/usr/lib/X11/fonts/Speedo
FontPath/usr/lib/X11/fonts/100dpi
FontPath/usr/lib/X11/fonts/75dpi
FontPath/usr/lib/X11/fonts/TrueType
EndSection
Section Module
LoadGLcore
Loadbitmap
Loaddbe
Loadddc
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadrecord
Loadspeedo
Loadtype1
Loadvbe
EndSection
Section InputDevice
Identifier Generic Keyboard
Driver keyboard
Option CoreKeyboard
Option
Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, Jul 15, 2002 at 09:25:18PM +0100, Tim Smith wrote: I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the Which lockup is this? Which files in CVS should I watch for your commit? I've been scratching at the switch-to-vt-and-back freeze for a few days, but am a bit out of my depth with this source. Thanks for any information, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
