[Dri-devel] Snapshots
Hi, there were 2 reports from snapshot users on dri-users that DRI was disabled with the new configuration stuff. In at least one case the problem was that libexpat was not installed on the system. Could the snapshot build be changed to link the drivers statically with libexpat? In either case I'll add a note in the FAQ. On a related note, there seem to be no trunk snapshots. Only in bleeding-edge there are snapshots available. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] Dynamic allocation
On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. This way we can now hand over all memory to the FBManager and allow it to give us back memory regions, rather than using the current scheme of semi-dynamic allocation that relies on fixed offsets but cannot guarantee those offsets in certain situations. So, I've moved onto the next stage of implementing the dynamics in the r200 driver which has shown some tricky pieces to solve with regard to allowing dynamic memory management. For testing purposes, I've added another ioctl to the r200 interface to pass the new back/depth offsets to the kernel driver and update these offsets the texture offset in the DDX driver on transitioning. The problem is that TransitionTo3D() is called too late to setup these new offsets. To explain a little We get the current device information during the initial screen setup by issuing the DRIGetDeviceInfo() call into the Xserver to retrieve these driver private details. If we modify them after this initial setup (which we do with transitioning) then we need to retrieve new private details to act upon. Currently I've inserted another DRIGetDeviceInfo() call into the r200_context.c to pick these up and moved the (modified) code from TransitionTo3d() in the DDX to the DDX's CreateContext() function. This works, but seems rather messy. Could we add this state to the existing mechanisms that exist to communicate cliprect changes between XFree86 and the driver? That is, if the driver detects that it's drawable has been invalidated (look at r200GetLock()) the new semantics would be that the driver should both - Ask the X server for a new set of cliprects (as it currently does) - Ask the kernel module (or X server) for the new buffer locations This may be more dynamic than you needed, but maybe a future step might require this level of control? It could be added at this stage - yes. But as you say, it's a little more dynamic than needed currently. It means changing the DRIGetDrawableInfo() call, thus requiring a version bump (which it would anyway as there'd be new protocol). I'm not necessarily suggesting new protocol -- just get the driver to do two things where it currently does one. Where previously there was a call to DRIGetDrawableInfo(), add a call to GetBufferOffsetIoctl(). Or DRIGetBufferInfo() if you wanted to ask the X server. But it's a case of if I add this extra DRIGetBufferInfo() call then we'll need to work out how to get it to work with older drivers. Actually putting it at this stage, may well work out. If we ever allow a non-unified back buffer architecture and allow per window back buffers to reduce the memory footprint furthur. Yes - that's what I was thinking of... We have to decide who's the boss of this memory -- the kernel or the X server. Previously we'd assumed that it would be the kernel, but that isn't necessarily the case as the X server already has a memory manager that could do the job, right? Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Alan. --- 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] Snapshots
Felix, On Fri, Oct 10, 2003 at 10:06:51AM +0200, Felix Kühling wrote: Hi, there were 2 reports from snapshot users on dri-users that DRI was disabled with the new configuration stuff. In at least one case the problem was that libexpat was not installed on the system. Could the snapshot build be changed to link the drivers statically with libexpat? In either case I'll add a note in the FAQ. I suppose so. Does any body here knows how to specify which library (static or dynamic) the linker should use? (I always just do -lname and never thought much about it...) On a related note, there seem to be no trunk snapshots. Only in bleeding-edge there are snapshots available. I checked the logs. It was breaking because the Xaw headers couldn't be found on my system. It should be fixed now. Jose Fonseca --- 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] Dynamic allocation
Alan Hourihane wrote: On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. This way we can now hand over all memory to the FBManager and allow it to give us back memory regions, rather than using the current scheme of semi-dynamic allocation that relies on fixed offsets but cannot guarantee those offsets in certain situations. So, I've moved onto the next stage of implementing the dynamics in the r200 driver which has shown some tricky pieces to solve with regard to allowing dynamic memory management. For testing purposes, I've added another ioctl to the r200 interface to pass the new back/depth offsets to the kernel driver and update these offsets the texture offset in the DDX driver on transitioning. The problem is that TransitionTo3D() is called too late to setup these new offsets. To explain a little We get the current device information during the initial screen setup by issuing the DRIGetDeviceInfo() call into the Xserver to retrieve these driver private details. If we modify them after this initial setup (which we do with transitioning) then we need to retrieve new private details to act upon. Currently I've inserted another DRIGetDeviceInfo() call into the r200_context.c to pick these up and moved the (modified) code from TransitionTo3d() in the DDX to the DDX's CreateContext() function. This works, but seems rather messy. Could we add this state to the existing mechanisms that exist to communicate cliprect changes between XFree86 and the driver? That is, if the driver detects that it's drawable has been invalidated (look at r200GetLock()) the new semantics would be that the driver should both - Ask the X server for a new set of cliprects (as it currently does) - Ask the kernel module (or X server) for the new buffer locations This may be more dynamic than you needed, but maybe a future step might require this level of control? It could be added at this stage - yes. But as you say, it's a little more dynamic than needed currently. It means changing the DRIGetDrawableInfo() call, thus requiring a version bump (which it would anyway as there'd be new protocol). I'm not necessarily suggesting new protocol -- just get the driver to do two things where it currently does one. Where previously there was a call to DRIGetDrawableInfo(), add a call to GetBufferOffsetIoctl(). Or DRIGetBufferInfo() if you wanted to ask the X server. But it's a case of if I add this extra DRIGetBufferInfo() call then we'll need to work out how to get it to work with older drivers. Actually putting it at this stage, may well work out. If we ever allow a non-unified back buffer architecture and allow per window back buffers to reduce the memory footprint furthur. Yes - that's what I was thinking of... We have to decide who's the boss of this memory -- the kernel or the X server. Previously we'd assumed that it would be the kernel, but that isn't necessarily the case as the X server already has a memory manager that could do the job, right? Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow? Keith --- 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] Snapshots
On Fri, 10 Oct 2003 10:17:23 +0100 José Fonseca [EMAIL PROTECTED] wrote: Felix, On Fri, Oct 10, 2003 at 10:06:51AM +0200, Felix Kühling wrote: Hi, there were 2 reports from snapshot users on dri-users that DRI was disabled with the new configuration stuff. In at least one case the problem was that libexpat was not installed on the system. Could the snapshot build be changed to link the drivers statically with libexpat? In either case I'll add a note in the FAQ. I suppose so. Does any body here knows how to specify which library (static or dynamic) the linker should use? (I always just do -lname and never thought much about it...) The linker option for libexpat is defined in config/cf/X11.tmpl. You could try changing EXPATLIB = -lexpat to EXPATLIB = -Wl,-Bstatic -lexpat -Wl,-Bdynamic On a related note, there seem to be no trunk snapshots. Only in bleeding-edge there are snapshots available. I checked the logs. It was breaking because the Xaw headers couldn't be found on my system. It should be fixed now. It had one positive side effect, people were actually using the config snapshots. ;-) Jose Fonseca Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 11:16:06AM +0100, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. This way we can now hand over all memory to the FBManager and allow it to give us back memory regions, rather than using the current scheme of semi-dynamic allocation that relies on fixed offsets but cannot guarantee those offsets in certain situations. So, I've moved onto the next stage of implementing the dynamics in the r200 driver which has shown some tricky pieces to solve with regard to allowing dynamic memory management. For testing purposes, I've added another ioctl to the r200 interface to pass the new back/depth offsets to the kernel driver and update these offsets the texture offset in the DDX driver on transitioning. The problem is that TransitionTo3D() is called too late to setup these new offsets. To explain a little We get the current device information during the initial screen setup by issuing the DRIGetDeviceInfo() call into the Xserver to retrieve these driver private details. If we modify them after this initial setup (which we do with transitioning) then we need to retrieve new private details to act upon. Currently I've inserted another DRIGetDeviceInfo() call into the r200_context.c to pick these up and moved the (modified) code from TransitionTo3d() in the DDX to the DDX's CreateContext() function. This works, but seems rather messy. Could we add this state to the existing mechanisms that exist to communicate cliprect changes between XFree86 and the driver? That is, if the driver detects that it's drawable has been invalidated (look at r200GetLock()) the new semantics would be that the driver should both - Ask the X server for a new set of cliprects (as it currently does) - Ask the kernel module (or X server) for the new buffer locations This may be more dynamic than you needed, but maybe a future step might require this level of control? It could be added at this stage - yes. But as you say, it's a little more dynamic than needed currently. It means changing the DRIGetDrawableInfo() call, thus requiring a version bump (which it would anyway as there'd be new protocol). I'm not necessarily suggesting new protocol -- just get the driver to do two things where it currently does one. Where previously there was a call to DRIGetDrawableInfo(), add a call to GetBufferOffsetIoctl(). Or DRIGetBufferInfo() if you wanted to ask the X server. But it's a case of if I add this extra DRIGetBufferInfo() call then we'll need to work out how to get it to work with older drivers. Actually putting it at this stage, may well work out. If we ever allow a non-unified back buffer architecture and allow per window back buffers to reduce the memory footprint furthur. Yes - that's what I was thinking of... We have to decide who's the boss of this memory -- the kernel or the X server. Previously we'd assumed that it would be the kernel, but that isn't necessarily the case as the X server already has a memory manager that could do the job, right? Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow? No. No preservation is done. We need to invalidate everything. Alan. --- 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] Dynamic allocation
Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow? No. No preservation is done. We need to invalidate everything. That's a problem, as the only way we can do things like accelerated CopyTexSubImage() and single-copy textures is if the FB contents are guarenteed to be preserved. That's (I believe) one of the goals of Ian's in-kernel memory manager. The other is to organize some sort of fair sharing of texture memory between competing contexts. I would guess that the X server memory manager doesn't try to do this sort of thing? Keith --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 12:24:56PM +0100, Keith Whitwell wrote: Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow? No. No preservation is done. We need to invalidate everything. That's a problem, as the only way we can do things like accelerated CopyTexSubImage() and single-copy textures is if the FB contents are guarenteed to be preserved. That's (I believe) one of the goals of Ian's in-kernel memory manager. O.k. The other is to organize some sort of fair sharing of texture memory between competing contexts. I would guess that the X server memory manager doesn't try to do this sort of thing? Not currently, but I guess it could be made to. Alan. --- 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
[Dri-devel] Savage (The recent game by S2Games)
Could some of the developers check out the playable demo? There seems to be an agp memory initialisation bug. one of the authors claims this is due to lacking s3tc support, even when I follow steps to disable all texture compression in the config file, I keep getting the agp memory initialisation bug. I'm on a Radeon R250 using day before yesterdays DRI snapshot. I also tried it on an older snapshot (2 months) with same result. demo torrent; http://gametab.com/files/torrents.php?fuse=95 discussion; http://www.linuxgames.com/news/feedback.php?identiferID=6363action=flatview the (or a) contact would be: jon at s2games dot com thx. Paul Heldens. --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 12:24:56PM +0100, Keith Whitwell wrote: | | No. No preservation is done. We need to invalidate everything. | | That's a problem, as the only way we can do things like accelerated | CopyTexSubImage() and single-copy textures is if the FB contents are | guarenteed to be preserved. Yes, it's extremely important. Besides performance loss and memory bloat, the lack of framebuffer memory preservation on Windows has forced some new extensions to have ugly semantics. See the vertex buffer object extension http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt for one example. This is one more case in which the Windows people did the wrong thing, and an opportunity for other systems to be better. Allen --- 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] Dynamic allocation
Allen Akin wrote: Besides performance loss and memory bloat, the lack of framebuffer memory preservation on Windows has forced some new extensions to have ugly semantics. See the vertex buffer object extension http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt for one example. This is one more case in which the Windows people did the wrong thing, and an opportunity for other systems to be better. Since I was part of that working group, I'd like to clarify why some of those decisions were made. In that case it wasn't just Windows issues. The big problem was (and will continue to be) power managment events. As near as I could tell, the power management issue was felt across the board. Platforms were not at all consistent (even in the same high-level architecture or OS) WRT what happens to video memory when someone closes the lid on their laptop. On some systems it's kept, on some it's dumped but the driver has a change to back it up, and on others it's just dumped. AFAIK, perhaps someone can correct me, XFree86 on Linux falls into the last category. --- 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] Dynamic allocation
Right. And certainly now with the new linear allocator the Xserver can manage the whole lot. Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow? No. No preservation is done. We need to invalidate everything. Thinking along the lines of pbuffers, and giving each process it's own framebuffer... What if Linux console were modified to use DRM for it's hardware access? This would allow all of the framebuffers to be managed through a single DRM driver. Now it would be possible to see the VT's on the main windowing display as well as switch to them. Also if video were being streamed to a window it could go full screen just by adding it to the VT list. Would it be interesting to assign each GUI process a VT and then allow compositing everything into a GUI or alternatively seeing each VT/process standalone? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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] Dynamic allocation
On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. Excellent, that will mean I can actually fix the VIA bug thats currently dependant on pixmap cache being 2048 lines and other stuff wanting to use the memory too. Is there any good example/docs on changes I need to make to use this for the 2D driver I have (both setup and pulling non pixmap cache linear space) and will it make XFree 4.4 ? --- 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] Dynamic allocation
On Gwe, 2003-10-10 at 23:16, Ian Romanick wrote: on some it's dumped but the driver has a change to back it up, and on others it's just dumped. AFAIK, perhaps someone can correct me, XFree86 on Linux falls into the last category. It depends on the BIOS and other factors. For ACPI it is our job to save the video ram if we need to --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 11:24:24PM +0100, Alan Cox wrote: On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. Excellent, that will mean I can actually fix the VIA bug thats currently dependant on pixmap cache being 2048 lines and other stuff wanting to use the memory too. Is there any good example/docs on changes I need to make to use this for the 2D driver I have (both setup and pulling non pixmap cache linear space) and will it make XFree 4.4 ? It's in the XFree86 CVS now, so it will make 4.4 - yes. It's also very simple to setup... After the call to the xf86InitFBManager() (or equivalent) for the XY Areas, you then do. xf86InitFBManagerLinear(pScreen, offset, size); The offset and size are pixel aligned for most hardware. So for 32bpp your looking to divide offset size by 4 to DWORD align it. This matches how XY areas are handled and will make the fallback's to allocating XY areas continue to work properly when no linear space is available. You'll then need to multiply back in the driver to get the true offset. All because of area fallbacks. Let me know if there's anything you think is missing, or if there are any problems for that matter. Alan. --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 11:24:24PM +0100, Alan Cox wrote: On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote: I've just committed a version of the DRI's common code mm.[ch] linear allocator into the XFree86 CVS which extends the FBManager's ability to serve real linear space rather than pinching it from the XY area's that's usually occupied by the pixmap cache. Excellent, that will mean I can actually fix the VIA bug thats currently dependant on pixmap cache being 2048 lines and other stuff wanting to use the memory too. Is there any good example/docs on changes I need to make to use this for the 2D driver I have (both setup and pulling non pixmap cache linear space) and will it make XFree 4.4 ? Forgot to mention. Look at the other drivers *_video.c files which most of them use the linear memory allocation currently, but is always falling back to XY allocation. The method hasn't changed, so just calling the linear init routine will make the Xv drivers use real linear space automatically. Alan. --- 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] [Announce] config-0-0-1-branch merged to the trunk
On Thu, 2003-10-09 at 22:05, Felix Khling wrote:
earlier today I finally merged the config-0-0-1-branch into the trunk.
Congratulations for the good work!
This means that most environment variables stop working [...]
How hard do you think it would be to allow options to be overridden by
environment variables for debugging, along the lines of
tcl_mode=0 torcs
?
A configuration GUI is available at my homepage:
http://fxk.de.vu/projects_cur_en.html.
Attached is a small patch for driconf 0.0.9:
* the python gtk module in current Debian packages defaults to
GTK2; this fix might be Debian specific though
* get the language from LC_MESSAGES
Also, when I try to rename an application, the only thing that happens
is that this error gets printed:
Traceback (most recent call last):
File /usr/lib/python2.3/site-packages/gtk-1.2/gtk.py, line 2000, in
__call__
return self.cb(_obj2inst(widget))
File /home/michdaen/src/dri-cvs/driconf-0.0.9/driconf.py, line 841,
in renameApp
app.name, app)
NameError: global name 'app' is not defined
2. I'd like to move the project homepage for driconf (the configuration
GUI) to a more public place, either dri.sf.net or dri.freedesktop.org.
It would be easy to add a DriConf page to the Wiki on dri.sf.net.
I see you've already added one, looks good.
What about importing it into DRI CVS?
Sounds like a good idea to me.
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
diff -up -r driconf-0.0.9.orig/driconf.py driconf-0.0.9/driconf.py
--- driconf-0.0.9.orig/driconf.py 2003-10-03 14:14:26.0 +0200
+++ driconf-0.0.9/driconf.py 2003-10-11 01:32:27.0 +0200
@@ -21,6 +21,8 @@
import os
import locale
import dri
+import pygtk
+pygtk.require('1.2');
from gtk import *
from driconf_xpm import *
@@ -1064,7 +1066,7 @@ def main():
# initialize locale
global lang, encoding
locale.setlocale(locale.LC_ALL, '')
-lang,encoding = locale.getlocale()
+lang,encoding = locale.getlocale(locale.LC_MESSAGES)
if lang:
underscore = lang.find ('_')
if underscore != -1:
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
On Fri, 2003-10-10 at 11:29, Helge Hafting wrote: It hangs at a black screen now, I don't get to play around with the cursor for a few seconds first. I mounted /var synchronously so I got a logfile. It is attached as X-dri-log. I don't see anything suspicious, this looks like a perfectly normal log. Does disabling the DRI make a difference? If yes, what about Option ForcePCIMode? If neither make a difference, what about disabling all acceleration? Glxgears still hangs if I run it. The hang is not as bad as the xserver hang, because I can use sysrq+S+U+B to reboot without messing up filesystems. Can you also try logging in remotely and killing glxgears? I haven't done that yet, but it seems like it could work. I used sysrq+K instead (kill all programs on that virtual console) That left the framebuffer in a unreadable state, but I was able to log in as root and remove the X lockfile. Attempting to restart X led to a no signal warning on my screen, so recovering the console by restarting X didn't work. shutdown -r now did the trick though. So apparently the chip is in a rather bad state after it happens. I wonder if it could be a hardware problem to boot. Have you tried other OSs on this machine? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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] Dynamic allocation
On Fri, Oct 10, 2003 at 03:16:45PM -0700, Ian Romanick wrote: | | Since I was part of that working group, I'd like to clarify why some of | those decisions were made. ... Apologies if I sounded too critical -- I agree that compromise was a reasonable thing to do in the VBO case. |... In that case it wasn't just Windows | issues. ... Yes, though the Windows design flaws are real, too. They affected a lot of other extension and implementation designs before VBOs came along. | ... The big problem was (and will continue to be) power managment | events. ... The trend is clearly toward making these sorts of things invisible to apps that don't explicitly ask for notification about them. For that matter, the trend is to make even less-dramatic events (like window exposures) invisible to most apps. VBOs are something of a special case -- a very low-level interface intended for use by experts who understand the risks. If it had been practical to make mapped buffer objects non-volatile, though, it still would have been worthwhile. It would have eliminated some awkward error conditions that the spec takes pains to handle, and that some developers will undoubtedly trip over. Allen --- 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
[Dri-devel] [Bug 778] DRM on IA64 deadlocks DRM client X Server
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=778 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 01:43 --- Reassigning bug to DRI project. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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
[Dri-devel] [Bug 778] DRM on IA64 deadlocks DRM client X Server
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=778 --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 01:46 --- Patch should be applied to xf-4_3-branch if possible (or DRI doesn't work properly), CVS head, and DRI-CVS. The patch applies to 4.3.0 cleanly, and CVS head cleanly. I haven't tested to see if it applied to DRI CVS head, however I'll commit this to the DRI trunk if nobody objects. Please give ACK/NACK. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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] Deadlock with radeon DRI
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an XFree86 bug report on this. I could not find a DRI
specific bug reporting mechanism other than the dri-devel list.
The IA64 implementation of CAS was this:
#define DRM_CAS(lock,old,new,__ret) \
do { \
unsigned int __result, __old = (old); \
__asm__ __volatile__( \
mf\n\
mov ar.ccv=%2\n \
;;\n\
cmpxchg4.acq %0=%1,%3,ar.ccv\
: =r (__result), =m (__drm_dummy_lock(lock)) \
: r (__old), r (new) \
: memory); \
__ret = (__result) != (__old);\
} while (0)
The problem was with the data types given to the cmpxchg4
instruction. All of the lock types in DRM are int's and on IA64 thats
4 bytes wide. The digit suffix cmpxchg4 signifies this instruction
operates on a 4 byte quantity. One might expect then since this
instruction operates on 4 byte values and in DRM the locks are 4 bytes
everything is fine, but it isn't.
The cmpxchg4 instruction operates this way:
cmpxchg4 r1=[r3],r2,ar.ccv
4 bytes are read at the address pointed to by r3, that 32 bit value is
then zero extended to 64 bits. The 64 bit value is then compared to
the 64 bit value stored in appliation register CCV. If the two 64 bit
values are equal then the least significant 4 bytes in r2 are written
back to the address pointed to by r3. The original value pointed to by
r3 is stored in r1. The entire operation is atomic.
The mistake in the DRM_CAS implemenation is that the comparison is 64
bits wide, thus the value stored in ar.ccv (%2 in the asm) must be 64
bits wide and for us that means zero extending the 32 bit old
parameter to 64 bits.
Because of the way GCC asm blocks work to tie C variables and data
types to asm values the promotion of old from unsigned int to
unsigned long was not happening. Thus when old was stored into
ar.ccv its most significant 32 bits contained garbage. (Actually
because of the way GCC generates constants it turns out the upper 32
bits was 0x, this was from the OR of DRM_LOCK_HELD which is
defined as 0x8000, but the compiler generates a 64 bit OR
operation using the immediate value 0x8000, which is legal
because the upper 32 bits are undefined on int (32 bit) operations).
The bottom line is that the test would fail when it shouldn't because
the high 32 bits in ar.ccv were not zero.
One might think that because old was assigned to __old in a local
block which was unsigned int the compiler would know enough when using
this value in the asm to have zero extended it. But that's not true,
in asm blocks its critical to define the asm value correctly so the
compiler can translate between the C code variable and what the asm
code is referring to.
The line:
: r (__old), r (new)
says %2 is mapped by r (__old), in other words put __old in a
general 64 bit register. We've told the compiler to put 64 bits of
__old into a register, but __old is a 32 bit value with its high
order 32 bits undefined. We need to tell the compiler to widen the
type when assigning it to a general register, thus the asm template
type definition needs to be modified with a cast to unsigned long.
: r ((unsigned long)__old), r (new)
Only with this will the compiler know to widen the 32 bit __old value
to 64 bits inside the asm code.
Thanks to Jakub Jelinek who helped me understand the nuances of GCC
asm templates and type conversions.
As a minor side note, definitions of bit flags should be tagged as
unsigned. Thus things like:
#define DRM_LOCK_HELD 0x8000
#define DRM_LOCK_CONT 0x4000
should really be:
#define DRM_LOCK_HELD 0x8000U
#define DRM_LOCK_CONT 0x4000U
John
---
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] Deadlock with radeon DRI
John Dennis wrote: The locking problem is solved, my original analysis was incorrect. The problem was that DRM_CAS was not correctly implemented on IA64. Thus this was an IA64 issue only, this is consistent with others who showed up in a google search describing the problem, all were on IA64. I have filed an XFree86 bug report on this. I could not find a DRI specific bug reporting mechanism other than the dri-devel list. This list is good. Can you put together a patch to correct the behaviour? Keith --- 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
