Re: options list with 2 drivers (bug 10132)
I'm looking at the details in the bugzilla entry right now. This may or may not apply to michalwd1979's problem. I think the problem happens when r128CreateScreen calls driParseOptionInfo. It gets the two arguments __driConfigOptions and __driNConfigOptions. Both are defined in the same r128screen.c file. The error message indicates that there is a mismatch between the two variables. I noticed that __driConfigOptions is public, since driconf needs to be able to access it, while __driNConfigOptions is static. Both drivers (shared objects) have a __driConfigOptions symbol with the same name. I guess what's happening is that the dynamic linker resolves __driConfigOptions to the same object in both drivers in a dual-screen system. On the second screen that happens to be the wrong one. I'm not sure how to fix this. Some linker magic may be needed. You need to make sure that in the r128 driver, __driConfigOptions is resolved to its own version of the symbol in all cases, even when another driver is linked in that has a symbol with the same name. I hope this analysis helps. Regards, Felix Am Freitag, den 30.11.2007, 11:06 +0100 schrieb Michel Dänzer: On Fri, 2007-11-30 at 08:28 +0100, michalwd1979 wrote: Hello, I found this report [Bug 10132] New: dri doesn't work on second head (r128) on the archives, and it seems to be also my problem (radeon 7000 and mga card). I would risk a statement that it would hit any system with 2 drivers that use different options. It is quite strange that there is so little reports about this. I guess that kind of setup is rare. I have tried to find out where the problem is, but I am not a dri developer and it was ... hard. I simply have no idea why both drivers get option list form first screen. Do You think that I have any chance to find the problem? I can spend some time working on it but please point me to right direction. Where should I start looking? I'd start by tracing driParseConfigFiles() to make sure it really only parses options for the specified screen/driver. I'm Cc'ing Felix Kühling, who wrote the driconf code and might be able to give more hints. For your reference Felix, the bug report mentioned above is https://bugs.freedesktop.org/show_bug.cgi?id=10132 . I am not sure if I am right but it seems that drivers get theirs options from xorg.conf and then form drirc file. I tried to play with options in drirc, but this not change anything. In my case MGA drivers constantly gets options defined in xorg.conf for radeon and fails. But how this options were send to it? drirc files are readed when opengl application starts and opens drivers but what is going on with the list from xorg.conf? xorg.conf options don't (directly) affect the Mesa drivers, so they're probably irrelevant for this. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] Two problems in latest DRM
Am Montag, den 02.10.2006, 11:24 +0200 schrieb Michel Dänzer:
Hi Felix,
On Sun, 2006-10-01 at 17:44 -0400, Felix Kühling wrote:
1: drm_lock.c: drm_unlock uses a new tasklet_lock. That leads to hangs
on my system (for some reason the driver can't find an IRQ for my PCI
card). Fortunately the NMI watchdog detects the lockup and kills the
Xserver, so I can recover the system without rebooting.
I can see that tasklet_lock is only initialized in drm_irq_install and
only if the DRIVER_IRQ_VBL is enabled. Thus you can't unconditionally
use that spinlock in drm_unlock. The patch adds a condition
dev-irq_enabled, but I'm not sure if this is the right condition. I
believe dev-irq_enabled can be set even without DRIVER_IRQ_VBL being
enabled. Michel, what's would be the right way to handle this?
I think initializing the spinlock unconditionally in drm_fill_in_dev()
is the simplest solution. Fixed in
3a16e615cabfed18b1891a732e7243ef41dc0ad0.
Thanks, this fixes the problem for me.
Regards,
Felix
2: drm_drawable.c: make idx and id signed integers in drm_rmdraw. There
are some comparisons such as id 0 and idx = 0 in there that don't
make sense for unsigned integers. And I actually got kernel oopses when
running glxinfo or glxgears in a naked Xserver when it destroyed the
last drawable. It crapped out here:
...
/* Can we shrink the arrays? */
if (idx == bitfield_length - 1) {
while (idx = 0 !bitfield[idx])
--idx;
...
idx will always be = 0 if it's unsigned. --idx will make the value wrap
around and the next access to bitfield[idx] oopses.
Good catch! I must have been 'lucky' for never hitting this on my
development machine, but I'm also slightly disappointed that gcc didn't
warn about it. Anyway, I pushed your fix as
d58389968124191a546a14b42ef84edc224be23d.
Thanks for the detailed report,
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] Two problems in latest DRM
Hi,
I found two problems in latest DRM while working on the mach64. I'm
attaching a patch for the two.
1: drm_lock.c: drm_unlock uses a new tasklet_lock. That leads to hangs
on my system (for some reason the driver can't find an IRQ for my PCI
card). Fortunately the NMI watchdog detects the lockup and kills the
Xserver, so I can recover the system without rebooting.
I can see that tasklet_lock is only initialized in drm_irq_install and
only if the DRIVER_IRQ_VBL is enabled. Thus you can't unconditionally
use that spinlock in drm_unlock. The patch adds a condition
dev-irq_enabled, but I'm not sure if this is the right condition. I
believe dev-irq_enabled can be set even without DRIVER_IRQ_VBL being
enabled. Michel, what's would be the right way to handle this?
2: drm_drawable.c: make idx and id signed integers in drm_rmdraw. There
are some comparisons such as id 0 and idx = 0 in there that don't
make sense for unsigned integers. And I actually got kernel oopses when
running glxinfo or glxgears in a naked Xserver when it destroyed the
last drawable. It crapped out here:
...
/* Can we shrink the arrays? */
if (idx == bitfield_length - 1) {
while (idx = 0 !bitfield[idx])
--idx;
...
idx will always be = 0 if it's unsigned. --idx will make the value wrap
around and the next access to bitfield[idx] oopses.
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
diff --git a/linux-core/drm_lock.c b/linux-core/drm_lock.c
index fa677ba..b25bf08 100644
--- a/linux-core/drm_lock.c
+++ b/linux-core/drm_lock.c
@@ -163,15 +163,17 @@ int drm_unlock(struct inode *inode, stru
return -EINVAL;
}
- spin_lock_irqsave(dev-tasklet_lock, irqflags);
+ if (dev-irq_enabled) {
+ spin_lock_irqsave(dev-tasklet_lock, irqflags);
- if (dev-locked_tasklet_func) {
- dev-locked_tasklet_func(dev);
+ if (dev-locked_tasklet_func) {
+ dev-locked_tasklet_func(dev);
- dev-locked_tasklet_func = NULL;
- }
+ dev-locked_tasklet_func = NULL;
+ }
- spin_unlock_irqrestore(dev-tasklet_lock, irqflags);
+ spin_unlock_irqrestore(dev-tasklet_lock, irqflags);
+ }
atomic_inc(dev-counts[_DRM_STAT_UNLOCKS]);
diff --git a/shared-core/drm_drawable.c b/shared-core/drm_drawable.c
index 5e2fc86..d203b24 100644
--- a/shared-core/drm_drawable.c
+++ b/shared-core/drm_drawable.c
@@ -132,7 +132,8 @@ int drm_rmdraw(DRM_IOCTL_ARGS)
{
DRM_DEVICE;
drm_draw_t draw;
- unsigned int id, idx, shift;
+ int id, idx;
+ unsigned int shift;
unsigned int irqflags;
u32 *bitfield = dev-drw_bitfield;
unsigned int bitfield_length = dev-drw_bitfield_length;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] DRIconf on SourceForge
Hi all, I have created a SourceForge project for the DRIconf applet: http://sourceforge.net/projects/driconf/. I'm hoping to make the development more open and attract translators and people with good ideas and/or Python coding skills. Especially on the translation side it will allow making releases with up-to-date translations, which hasn't worked so well in the past. I converted my local CVS repository to Subversion and moved it to SourceForge. If you'd like to get your feet wet please subscribe and introduce yourself to the mailing list [EMAIL PROTECTED] Cheers, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] DRIconf 0.9.1 released
Hi all, I just wrapped up a new release of DRIconf after receiving a couple of contributions since the 0.9.0 release: an updated Russian translation (Konstantin A. Lepikhov), a new Dutch translation (Benno Schulenberg) and a new icon and desktop file (Pascal de Bruijn). Note that the .desktop file needs to be installed manually to /usr/share/applications/driconf.desktop. The automatic installation script only covers the files that can be installed under /usr/local. The source is available for download from http://dri.freedesktop.org/wiki/DriConf. Thanks to all contributors! Enjoy, Felix Kühling -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (MGA) DRI locking
Am Donnerstag, den 27.07.2006, 22:08 +0200 schrieb Tilman Sauerbeck: Hi, I'm trying to fix bug 7265, but I'm stuck. I added some debugging output to the xserver and the mga driver and I attached the interesting parts of the lock. What's interesting is that DRILock()/DRIUnlock() are continually called about every second even if no DRI client is connected. This might be due to XAA rendering though, and it seems XAA cannot be disabled without disabling DRI, too. As my test case, I started glxinfo in a xterm (which hangs in mgaGetLock(), as expected). This is line 18 in the log. At the end of the log, you'll see that DRIDoBlockHandler() results in another DRIUnlock() call, although the lock isn't currently held. Now, the problem is that I cannot figure out why and how DRIDoBlockHandler() is called. It's assigned to the DRI inforec-wrap.BlockHandler, but I don't see when it's called. To make things worse, I cannot get a backtrace either... attaching GDB or using xorg_backtrace() will crash the server. Any idea what's wrong with the locking here? Hints on when DRIDoBlockHandler is called or why it can be called even though the DRI lock isn't held are appreciated :) DRIDoBlockHandler is called from DRIBlockHandler: if (pDRIPriv pDRIPriv-pDriverInfo-wrap.BlockHandler) (*pDRIPriv-pDriverInfo-wrap.BlockHandler)(i, blockData, pTimeout, pReadmask); DRIBlockHandler in turn is registered in DRIExtensionInit using RegisterBlockAndWakeupHandlers. Block and Wakeup handlers are called automatically whenever the server starts and stops processing client commands. I just notice that DRIBlockHandler is also called through __glXDRIleaveServer (glxdri.c), which was introduced in the AIGLX merge. Could it be that DRIBlockHandler gets called twice when it should only be called once? Regards, Felix Thanks, Tilman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI binary snapshots suspended
Hi, As you may have noticed, DRI binary snapshots have not been updated for a while. The reason was that I've been too busy to keep up with technical changes that would be needed to make the snapshots actually work. I have now invested a little time looking into the problems of including an Xserver binary into the snapshots and I'm getting increasingly frustrated. Partially installing current modular Xorg binaries on a monolithic system requires too many hacks and workarounds. I'm also having doubts that in the age of modular Xorg, binary snapshots are all that useful any more. Once a system is upgraded to modular, it should be possible to upgrade only a few components from source. No more need to download and build an entire monolithic X tree. There is also a sane build system in place now (though some argue otherwise ;-) that most enthusiasts are familiar with. So instead of wasting my time on tracking Xorg CVS (and other SCMs) and hacking up a partial binary distribution with increasing effort over time I'd rather work on the documentation, explaining how to build and test the latest driver changes in a modular Xorg environment. Maybe I'll even have some fun with Xgl and Compiz. :) That means, I am now officially suspending DRI binary snapshot builds. If anyone feels like resurrecting them, feel free to do so. All the scripts are in CVS. Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mach64
Am Freitag, den 24.03.2006, 23:50 +0200 schrieb Micha Feigin: On Thu, 28 Jul 2005 16:30:47 -0400 Alex Deucher [EMAIL PROTECTED] wrote: On 7/28/05, Svante Signell [EMAIL PROTECTED] wrote: Is anything happening on the Mach64 front for DRI/X.org? It would be nice to use the 3D capabilities, now that Debian has upgraded unstable to Xorg. there is a DRI driver for mach64, but the drm is not yet secure so it's not built by default. Somehow considering the age of this card I doubt the time will be found to secure the DRM, but maybe I'm wrong. I'm currently trying to get my hands on an old Mac Notebook with Mach64. In its current state, Mach64 DRI support is essentially a waste of everyone's time who has been working on it in the past. Probably most potential users aren't even aware of it. I am hoping to change that. Cheers, Felix binary snapshots: http://dri.freedesktop.org/wiki/Download#head-55420c59a1c2e9a70f07a6fa02f0d228ffb87b76 I am using the binary snapshot with the unstable version of X.org and its working great. Currently it doesn't really complicate things much as the kernel doesn't include the mach64 driver anyway so even if X included it, it would still require to compile the kernel driver each time you update the kernel. building from source: http://dri.freedesktop.org/wiki/Building Alex -- Svante Signell [EMAIL PROTECTED] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libglx requires new symbol in loader (Was: problem with binary dri snapshots)
Am Sonntag, den 26.03.2006, 12:18 -0800 schrieb Mike Mestnik: --- Felix Kühling [EMAIL PROTECTED] wrote: It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver to the snapshots. Yay! I came up with two workable solutions for this problem. The first one can be implemented in multiple ways. Make this function available as/in a module. I understand that this is part of the loader, but it should not be needed to boot-strap itself. The second implementation is to put this function in libglx.so, where it is used. My other solution is to include an xorg-additions.c into the snapshots that can be built and then linked against the installed xorg binary. This would need a configure script that detects what symbols are missing . Should not be too hard. When I build the snapshots, the latest Xorg server is being built, it's just not being included in the snapshot packages. libglx and libdri are part of the Xorg server source. So a configure test doesn't make sense. More generally, I appreciate your initiative. But keep in mind that the binary snapshots are not much more than a hack for bleeding edge testers. They are not officially supported by Xorg. IMHO convenience of binary snapshot users should not affect design decisions of Xorg. It works the other way around. The snapshot build, packaging and installation process needs to keep up with Xorg changes in order to allow adequate testing of current development code. I'm now considering a solution that would include a single server binary in the common package. Binary patching at installation time could be used to adjust that binary to the user's module paths etc. Regards, Felix I would gladly put forth the effort to bring any solution to life, I just would like to know what will/will-not be accepted. The problem with that is that the default ModulePath, RgbPath etc. I build with will only work with either one of Xorg 6.9 or 7.0, but not both. Hmm ... testing the latest and greatest stuff is getting messier. Regards, Felix Am Donnerstag, den 23.03.2006, 16:34 +0100 schrieb Michal Suchanek: Hello I tried installing the dri snapshots common-2006032[12]-linux.i386 with r200-2006032[12]-linux.i386, and I get undefined symbol in libglx.so. After reinstalling xorg-server 1.0.2 the problem goes away but it is because the library is overwritten with the older version. Using the X server and modules from http://dri.freedesktop.org/wiki/Download does not help either. Attaching the X server output. I do not see the error in the /var/log/X* files. Thanks Michal -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
libglx requires new symbol in loader (Was: problem with binary dri snapshots)
It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver to the snapshots. Yay! The problem with that is that the default ModulePath, RgbPath etc. I build with will only work with either one of Xorg 6.9 or 7.0, but not both. Hmm ... testing the latest and greatest stuff is getting messier. Regards, Felix Am Donnerstag, den 23.03.2006, 16:34 +0100 schrieb Michal Suchanek: Hello I tried installing the dri snapshots common-2006032[12]-linux.i386 with r200-2006032[12]-linux.i386, and I get undefined symbol in libglx.so. After reinstalling xorg-server 1.0.2 the problem goes away but it is because the library is overwritten with the older version. Using the X server and modules from http://dri.freedesktop.org/wiki/Download does not help either. Attaching the X server output. I do not see the error in the /var/log/X* files. Thanks Michal -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DMA scheduling
Am Donnerstag, den 16.03.2006, 15:52 + schrieb Keith Whitwell: I've been thinking a little bit about DMA scheduling for the graphics hardware. Currently we have a situation where any 3d app which happens to be able to grab the DRI lock can enqueue as many commands on the hardware dma queue as it sees fit. The Linux scheduler is the only arbiter between competing 3D clients, and it has no information regarding the GPU usage of these clients. Even if it did, there are benefits to be reaped from keeping the 3d DMA streams seperate and explicitly scheduling the dma rather than allowing clients to inject it in arbitary quantities and orders. Why do we want a GPU scheduler? 1) Fairness. We can currently have situations where one 3d applications manages to dominate the GPU while a second app in another window is locked out entirely. 2) Interactivity. It is quite possible to have one application which does so little rendering per frame that it can run at 3000fps while another eg, video-based application does a lot more and can just about keep up a 30fps framerate. Consider a situation where both applications are running at once. Simple fairness criteria would have them running at 1500fps and 15fps respectively - but it seems that fairness isn't what is required here. It would be preferable give the slower application a greater percentage of the GPU, so that it manages eg. 27fps, while the other is scaled down to only 300fps or so. Note that we currently don't even have the fair situation... 3) Resource management. Imagine two applications each of which has a texture working set of 90% of the available video ram. Even a smart replacement algorithm will end up thrashing if the applications are able to rapidly grab the DRI lock from each other and enqueue buffer loads and rendering. A scheduler could recognize the thrashing and improve matters by giving each app a longer timeslice on the GPU to minimize texture reloads. 4) Latency. There are currently frame throttling hacks in place to limit the latency, or IOW how far the CPU can be ahead of the GPU. If the scheduler were to get involved in this activity it would not only schedule queued commands to the hardware but also throttle (block) clients whose command stream processing is too far behind. Latency is also important for buffer swapping synchronized with the vrefresh. The only way to do this reliably right now is to lock the hardware, drain the DMA stream, wait for the refresh, swap, unlock. A low latency scheduler could make sure that the hardware never queues too many commands so that it would be able to inject buffer swapping commands synchronously with the vertical refresh without ever stalling the hardware and other clients. Regards, Felix [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DMA scheduling
into locations in vram.
The departure from the current code is that we are now asking for this
to be done at some point in the future. The current code actually
pulls in the buffers before phsyically enqueuing the command buffer on
the hardware.
Allowing this to be deferred to the future will allow the scheduler to
optimize the usage pattern of buffers, to reduce thrashing and to
attempt to fairly divide GPU resources (time, bandwidth, framerate,
etc) between competing 3d applications.
The scheduler will at some point in the future do the equivalent of:
- choose a particular dma command buffer for execution.
- effectively:
LOCK_HARDWARE
validateBuffers()
applyFixups()
retrieveClipRects()
foreach cliprect {
set cliprect;
fire command buffer;
}
UNLOCK_HARDWARE
at this point, note that validateBuffers() is primarily used within
kernelspace. This may mean that optimizations aimed at improving the
userspace behaviour of this call may not be important in the longer
term.
That aside, what is missing before we can implement the scheduler? I
see a only couple of (small?) items.
1) retrieveClipRects()
- The way that other driver architectures have done this is to create
a regular shared memory region that the X server and kernel module
can access which holds the cliprects of all active drawables. The
memory region doesn't have to be pinned or anything special, just
readable and understandable by both parties. Access is probably
protected by the DRI lock.
2) 2D blits.
- The regular mechanism of setting a cliprect and firing a command
buffer works for most hardware we know about, but only for 3d
commands. 2d commands tend not to be affected by the 3d state used
for the cliprect.
- The i830 may or may not have a way to set a cliprect which affects
2d state, but that's probably not helpful for solving the general
problem.
If you look at the i915 driver, there's quite a few places where we
lock hardware and then use the cliprect list to emit 2d blits, eg for
screen clearing, swapBuffers, copyPixels, etc.
This could work with the scheduler if the application cleared out all
previous dma from the scheduler queue before being allowed to emit
those hard-coded blits. The blits themselves would have to go to
hardware immediately, before UNLOCK_HARDWARE, and not be subject to
scheduling, otherwise the X server might change the cliprects before
they are scheduled.
While the above would work, and would certainly be fine as a first
step, it seems to reduce the utility of the scheduler as clients can
still skew the behaviour of the dma stream significantly just by
issuing lots of blits.
I'm considering a system where operations that don't respect the
standard method of setting a cliprect are passed to the scheduler as
special tokens. These tokens are scheduled as usual, the same as dma
command buffers, but when it comes time to fire them, are passed to
the hardware's drm component to be turned into real dma commands. At
the moment, I think the two tokens would be copy-blit and
fill-blit, and that is pretty much all the 3d drivers need.
3) The X server.
Is the X server command stream scheduled? I would like to think it
was, but see the above. The X server would want more and more varied
control over the 2d and video hardware and command streams. For Xgl,
it is a lot easier to see how this would work. What about regular X
servers?
It has been pointed out that you can divide X server drawing into two
components:
1) Drawing on behalf of clients. This includes 2D xlib
drawing as well as 3D commands arising from indirect GLX
clients.
2) Drawing as a result of window management operations, such
as mapping, unmapping and moving windows.
From the point of view of the scheduler, it may be advantageous to
treat these seperately. The drawing commands from (1) can effectively
be sheduled normally, maybe even as multiple streams, one per
client/context.
The window-managment drawing operations are associated with changes to
cliprect lists and these may benefit from being scheduled differently.
They may also be subject to different constraints based on how easy or
difficult it is to propogate the cliprect changes to other queues. If
cliprect changes cannot be propogated, it will be necessary to drain
the other queues before executing the window managment drawing.
Keith
___
xorg mailing list
[EMAIL PROTECTED]
http://lists.freedesktop.org/mailman/listinfo/xorg
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.Net email is sponsored by xPML, a groundbreaking
Re: New DRI snapshots built from modular Xorg
Am Dienstag, den 14.03.2006, 18:59 -0800 schrieb Mike Mestnik: --- Felix K�hling [EMAIL PROTECTED] wrote: Hi, I just uploaded the first set of snapshots built from the modular Xorg tree (20060226). This now has the latest and greatest changes in Xorg CVS that the monolithic tree did not have. Among other things this means that i915 should now work again, with rotation support. It also has Benjamin Herrenschmidt's memory mapping changes that should solve lockup problems on many Radeons. Please let me know if there are any new problems with installing these snapshots. Great! Any reason why prelink complains about non-PIC libGL? I think you need to add -fPIC somewhere. That's not my fault. I use the build system pretty much from up-stream. There are reasons why libGL is not position independent. They have been discussed at length on the mailing lists. You'll find it in the archives and/or in bugzilla. I'm not too familiar with the details but IIRC it had something to do with the efficiency of dispatch stubs. My understanding from those emails is that making them position independent incurs a run-time performance penalty that wasn't considered to be worth the benefit of faster loading or better security on hardened systems. Don't quote me on this, I really didn't follow those discussions very thoroughly. ;-) Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
This looks somewhat familiar. I saw this on a Radeon 7500 where AGP writes from the card to system memory did not work reliably. So uploading textures to AGP memory (through DMA) was corrupting textures. Reducing the AGP speed to 2x solved the problem on that card. The problem only occurred after a while of heavy texture usage, when it started using the AGP texture heap. After that it kept using the AGP heap and I saw texture corruption in other games too. The same card also suffered from soft lockups due to AGP status writeback that was affected by the same unreliability. I solved it locally be disabling status writeback in the kernel module before I figured out that reducing the AGP speed helped as well. YMMV. Regards, Felix Am Donnerstag, den 02.03.2006, 18:48 +0100 schrieb Rune Petersen: I didn't get the best shot, but I didn't want to risk a lockup at the time. Try looking closer at the bot. When I exited to the menu most of the background was corrupted. Rune Petersen Aapo Tahkola wrote: Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Cruft in www.freedesktop.org/dri/ (was Re: New DRI snapshots built from modular Xorg)
Am Montag, den 27.02.2006, 11:20 +0100 schrieb Christoph Brill: Felix Kühling wrote: [snip] Please let me know if there are any new problems with installing these snapshots. Regards, Felix Thanks for the work! BTW: Someone should redirect www.freedesktop.org/*dri*/*snapshots*/ to http://dri.freedesktop.org/snapshots/ ... it's listed first on google when search for dri snapshot and it's quite dead :) Ugh, this looks like a very old version of the DRI webspace on fd.o. Did this resurface after the recent server update or has this been around all the time? What would be the best way to deal with this? Simply delete it or add a redirect as suggested? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Cruft in www.freedesktop.org/dri/ (was Re: New DRI snapshots built from modular Xorg)
Am Montag, den 27.02.2006, 18:38 +0200 schrieb Daniel Stone: On Mon, Feb 27, 2006 at 11:28:31AM -0500, Felix Kühling wrote: Am Montag, den 27.02.2006, 11:20 +0100 schrieb Christoph Brill: Felix Kühling wrote: [snip] Please let me know if there are any new problems with installing these snapshots. Regards, Felix Thanks for the work! BTW: Someone should redirect www.freedesktop.org/*dri*/*snapshots*/ to http://dri.freedesktop.org/snapshots/ ... it's listed first on google when search for dri snapshot and it's quite dead :) Ugh, this looks like a very old version of the DRI webspace on fd.o. Did this resurface after the recent server update or has this been around all the time? What would be the best way to deal with this? Simply delete it or add a redirect as suggested? [EMAIL PROTECTED]:/srv/www.freedesktop.org/www% mv dri /srv/dri.freedesktop.org/old-from-www.fd.o [EMAIL PROTECTED]:/srv/www.freedesktop.org/www% Hmm, I wasn't that much worried about loosing data. I don't think the old location had anything that the new one does not have. I was more worried about giving people a chance to update their bookmarks. That's why I asked whether this resurfaced recently or if it was there all the time. In the latter case a redirect would be nice. I just don't have any idea how to do that. Thanks, Felix Cheers, Daniel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Cruft in www.freedesktop.org/dri/ (was Re: New DRI snapshots built from modular Xorg)
Am Montag, den 27.02.2006, 20:34 +0200 schrieb Daniel Stone: On Mon, Feb 27, 2006 at 01:16:59PM -0500, Felix Kühling wrote: Am Montag, den 27.02.2006, 18:38 +0200 schrieb Daniel Stone: [EMAIL PROTECTED]:/srv/www.freedesktop.org/www% mv dri /srv/dri.freedesktop.org/old-from-www.fd.o [EMAIL PROTECTED]:/srv/www.freedesktop.org/www% Hmm, I wasn't that much worried about loosing data. I don't think the old location had anything that the new one does not have. I was more worried about giving people a chance to update their bookmarks. That's why I asked whether this resurfaced recently or if it was there all the time. In the latter case a redirect would be nice. I just don't have any idea how to do that. Sure, redirect for all of /dri/ added. Thanks a lot. It works nicely. Cheers, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-announce] Re: [Mesa3d-users] Mesa 6.4.2 released
Am Dienstag, den 28.02.2006, 03:03 + schrieb Sergio Monteiro Basto: On Mon, 2006-02-20 at 22:41 +0100, Roland Scheidegger wrote: Sergio Monteiro Basto wrote: On Sat, 2006-02-04 at 11:04 -0700, Brian Paul wrote: Sergio Monteiro Basto wrote: Includes updates of the DRI drivers and GLX code ? I don't recall any DRI/GLX check-ins to the 6.4 branch. It's up to the DRI developers to check in bug fixes to the stable branch, but that doesn't happen too often, unfortunately. Hi, Brian I had thinking, thinking and came up this idea. You may make some releases of stable branch with updates of DRI Drives. In times to times, because Mesa is very mature and DRI drives aren't. Like putting the Development of DRI drives in Stable branch. And in official page of building DRI, ask to use stable branch of Mesa. With this formula we can update Xorg CVS with DRI drives more often, and most important, we can put users testing code more similar. You can't just copy the dri directory from cvs head to the stable branch, if you're suggesting something like that, this usually won't compile (as internal functions/structs etc. change). FWIW, I usually do update the stable branch (if I don't forget it...), but only for bugfixes, you won't see new features / optimizations or similar from me in the stable branch (unless I'd be asked to commit it there or I'd think this really warrants an exception). So 6.4 branch got that no-tcl blender fix (it's newer than the 6.4.2 release though), but it doesn't contain things like r100 cube maps. To test last features of DRI drives, you should need lastest drives of X tree, but to test latest Mesa3D it self you don't need it latest X. DRI drivers live in Mesa3D. Binary DRI drivers contain the Mesa core and it's probably the biggest part of the binaries. It implements a lot of hardware-independent stuff, basically the entire OpenGL state machine and rendering pipeline. The hardware-specific part is usually relatively small and many hardware features need some kind of support in core Mesa. You can't easily separate the two. There are no well defined interfaces where the one ends and the other begins. Before the development of DRI has move to Mesa tree, the development was made using always the same Mesa3D code. And there was a reason to move the DRI drivers into the Mesa tree. Every time core Mesa in DRI CVS was updated it was a painful and error-prone process to update the DRI drivers to work with the latest Mesa 3D core. I know what I'm talking about. A lot of the initial work on the Savage 3D driver was porting it to a new Mesa version. Developing both in the same tree makes a lot of sense since they share a lot of code and there are no stable interfaces. Stabilization in core Mesa automatically leads to stabilization in the DRI drivers. So releasing everything at the same time makes sense too. Therefore I think DRI developers should update Mesa stable branch, not just with bug fix , but also with new features / optimizations. At same time that update driver on Xorg tree. Why should a _stable_ Mesa release branch track changes in _unstable_ Xorg CVS HEAD? That doesn't make sense. If this is made, DRI Building should be done with Mesa stable branch and more quickly dri code enter in Xorg tree, where could be test without snapshots, therefore the Distros could put the code out faster and can be tested for a much bigger number of people. You *can* live without snapshots. You can build everything from the sources just as easily as the snapshots are built. Providing the snapshots is merely a matter of convenience. What you are suggesting would make life more convenient for you but would make development less productive. Backporting new features to a (then no longer) stable branch would be time consuming and error prone and something that active developers would hate doing. Supporting and maintaining such a branch would be an even bigger nightmare. Therefore it is common practise to backport only bug fixes with a well known impact to stable branches. At the same time new features need some shakedown time before they can be picked up with good conscience by distributions that have any notion of quality standards. Another reason to have a development tree that stabilizes before a release and to maintain a known good tree on a stable release branch. What you're asking for is the latest features in a near production-quality code branch. That's a contradiction in itself and it's simply not going to happen. Regards, Felix This is my ideia . Roland -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web
DRI snapshot license?
Hi, I'm working on a new DRI snapshot build system that uses the modular Xorg tree for building core components and DDX drivers. I have it working and am theoretically ready to upload new snapshots. There is only one catch. The old snapshots used to include a LICENSE file from the monolithic tree: xc/programs/Xserver/hw/xfree86/doc/LICENSE. I can't find that file anywhere in the modular trees. The COPYING file in the xserver/xorg module is only a placeholder. I don't feel good about distributing snapshots without any license statement. So I am going to include the following LICENSE file: 8-- DRI snapshots are a compilation of many sources that are covered by different open-source licenses. Refer to the respective sources for details. DRM: http://webcvs.freedesktop.org/dri/drm/ Xorg: http://webcvs.freedesktop.org/xorg/ Mesa: http://webcvs.freedesktop.org/mesa/Mesa/ 8-- Comments? Advice? Flames? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRI snapshots built from modular Xorg
Hi, I just uploaded the first set of snapshots built from the modular Xorg tree (20060226). This now has the latest and greatest changes in Xorg CVS that the monolithic tree did not have. Among other things this means that i915 should now work again, with rotation support. It also has Benjamin Herrenschmidt's memory mapping changes that should solve lockup problems on many Radeons. Please let me know if there are any new problems with installing these snapshots. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
Am Samstag, den 25.02.2006, 09:51 + schrieb Roland Scheidegger:
CVSROOT: /cvs/dri
Module name: drm
Repository: drm/shared-core/
Changes by: [EMAIL PROTECTED] 06/02/25 09:51:15
Log message:
Add all radeon pci ids known by ddx, but only r350/rv350 and below
(new chips may be problematic).
Not quite. It's still missing 0x3150 which is the M24 in my notebook.
Fglrx identifies it as MOBILITY RADEON X600 (M24 3150). It works just
fine with the free drivers as an RV350 (Mesa treats it as an RV350 too),
though the radeon driver in Xorg seems to think it's an RV380.
radeon_probe.c:{ PCI_CHIP_RV380_3150, PCI_CHIP_RV380_3150, RES_SHARED_VGA }
I added this line to drm_pciids.txt and otherwise used the latest binary
snapshot (from today):
--- drm_pciids.txt 25 Feb 2006 09:51:15 - 1.32
+++ drm_pciids.txt 27 Feb 2006 01:37:11 -
@@ -1,4 +1,5 @@
[radeon]
+0x1002 0x3150 CHIP_RV350|CHIP_IS_MOBILITY ATI Radeon X600 Mobility
0x1002 0x4136 CHIP_RS100|CHIP_IS_IGP ATI Radeon RS100 IGP 320
0x1002 0x4137 CHIP_RS200|CHIP_IS_IGP ATI Radeon RS200 IGP 340
0x1002 0x4144 CHIP_R300 ATI Radeon AD 9500
Regards,
Felix
Leave the existing entries for new chips in though. Remove ids not
known by ddx (secondary ids, non-existant,...). Correct some entries
(name/family). Make the radeon family enum look more alike the ddx/dri
versions. See #5413
Modified files:
drm/shared-core/:
drm_pciids.txt radeon_cp.c radeon_drv.h
Revision ChangesPath
1.32 +42 -53drm/shared-core/drm_pciids.txt
1.74 +2 -0 drm/shared-core/radeon_cp.c
1.67 +7 -6 drm/shared-core/radeon_drv.h
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Snapshots have stoped at r300-20060206.
Am Dienstag, den 21.02.2006, 11:02 + schrieb Foxy: Felix Kühling wrote: Am Sonntag, den 19.02.2006, 21:13 -0800 schrieb Mike Mestnik: There have been no new snapshots since the 6th. Yes. The snapshot build is currently done against Xorg 6.9, which is broken with the latest Mesa and won't be fixed because the monolithic Xorg tree is officially dead. I'm working (slowly) on making a snapshot build for the modular Xorg tree. It may take one or two weeks till I finish up the scripts. Regards, Felix that's why it does not work with xorg 7.0, stupid me, I have installed it without any error but now I hove an error message. How to uninstall it btw? install.sh restore But that only works if you installed the driver once. If you installed it twice or more without restoring in between, this doesn't work. You'll have to re-install your distribution's X packages and remove anything else that is left behind by hand. See the install script for details. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Snapshots have stoped at r300-20060206.
Am Sonntag, den 19.02.2006, 21:13 -0800 schrieb Mike Mestnik: There have been no new snapshots since the 6th. Yes. The snapshot build is currently done against Xorg 6.9, which is broken with the latest Mesa and won't be fixed because the monolithic Xorg tree is officially dead. I'm working (slowly) on making a snapshot build for the modular Xorg tree. It may take one or two weeks till I finish up the scripts. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Stubs for drm_mtrr_add and drm_mtrr_del when !__OS_HAS_MTRR
Hi,
does anyone object to applying this patch to linux-core/drmP.h:
--- drmP.h 2 Jan 2006 05:54:10 - 1.172
+++ drmP.h 18 Feb 2006 18:46:54 -
@@ -780,6 +780,20 @@
#else
#define drm_core_has_MTRR(dev) (0)
+
+static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
+ unsigned int flags)
+{
+ return -ENODEV;
+}
+
+static inline int drm_mtrr_del(int handle, unsigned long offset,
+ unsigned long size, unsigned int flags)
+{
+ return -ENODEV;
+}
+
+#define DRM_MTRR_WC 1
#endif
/**/
This fixes the build of savage_bci.c when __OS_HAS_MTRR is false. See
also: https://bugs.freedesktop.org/show_bug.cgi?id=5942
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [radeon] endless loop in idle ioctl?
Am Freitag, den 17.02.2006, 21:02 +0100 schrieb Markus Dahms: Hi there, I have some stability problems with radeon cards in my system. Doing something involving 3D graphics (e.g. Blender) after a while (often within minutes) the screen locks up (mouse is still movable) and the Xorg process goes up to 99% CPU. To use the screen again I have to reboot. From the GDB backtrace of the X server I suspect it's a kernel module problem: #0 0xa7f11cc4 in ioctl () from /lib/tls/libc.so.6 #1 0x080a2890 in xf86ioctl () #2 0xa7a92672 in drmCommandNone () from /usr/X11R6/lib/modules/linux/libdrm.so #3 0xa7a5181a in RADEONWaitForIdleCP () from /usr/X11R6/lib/modules/drivers/radeon_drv.so #4 0xa786758d in XAAInit () from /usr/X11R6/lib/modules/libxaa.so #5 0xa78b19d7 in xf86InitCursor () from /usr/X11R6/lib/modules/libramdac.so #6 0x08089e03 in xf86Wakeup () #7 0x080ca3f3 in WakeupHandler () #8 0x080e8731 in WaitForSomething () #9 0x080c9970 in Dispatch () #10 0x080d6765 in main () (at least the upper 4 calls are always the same, the rest differs) The backtrace only tells you that the engine stopped processing commands. But it doesn't tell you why. Finding the exact trigger can be very hard. Does somebody have a hint? I don't want to believe it's a broken mainboard or something... Software: * Debian Etch (testing) * Xorg 6.9.0 (same with 6.8.0) * Linux Kernel 2.6.16-rc2+e (GIT, same with older kernels) * radeon.ko from kernel Hardware: * 2 x P3 1000MHz on Asus CUV266-D, 1 GB RAM * Radeon 9250, same problem with Radeon 7500 Everything is done with AGP 1x mode, as higher rates increase the chance to crash this system (even in 2D mode). If you have AGPFastWrites enabled, do disable them. Did you set any other funny options in the configuration file? It may also be related to AGP writeback of engine status. It doesn't work reliably with some AGP bridges and leads to the symptoms described above. In that case the engine is finished processing commands and ready for new ones, but the driver never knows about it. It's pretty simple to disable this feature in the radeon.ko source. Search for Writeback in radeon_cp.c. There is a test whether writeback works. At the end of the test just set dev_priv-writeback_works = 0; unconditionally. I don't think it's a heat problem as there are enough fans and the cooler on the graphics card stays cold. Markus Hope this helps, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
Am Montag, den 13.02.2006, 16:27 -0700 schrieb Jesse Allen: On 2/13/06, Linus Torvalds [EMAIL PROTECTED] wrote: On Mon, 13 Feb 2006, Adrian Bunk wrote: The one thing I have not yet been proven wrong for is that this PCI id is the only one we have in this driver for an RV370. It definitely is an RV370, you're right in that. I'm too lazy to actually see if the other entries that claim to be RV350's really are RV350's. Well a while back, I hacked in the pci id for my Xpress 200M (5955), which is basically an RV370 with no dedicated vram. I did the same thing and claimed an RV350, which is the closest model. This allowed the radeon module to load. When I startx'ed and DRI was allowed to load on it, it locked up. So I never sent in the patch. I believe the person who sent this one in originally seemed to indicate that it worked, and I believed it if he had an X300 and my problem was having the IGP version. But now having this reported, I'm pretty sure it is the same problem. RV370 doesn't seem to work as an RV350. The Xpress200 chips have a completely different GART implementation. Thus the driver can't even send commands to the command processor and that's why X locked up on you when DRI was enabled. This has nothing to do with the Xpress200 being (almost) an RV370 or not. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: Re: sizeof(I830DRIRec) does not match passed size from device driver
Am Mittwoch, den 08.02.2006, 21:22 + schrieb Dave Airlie: This is due to snapshots building X.org drivers from the monolith tree, the monolith tree is dead so no new devel is done in it.. TG commited changes to the i810 driver for rotate which changed the size of rec... That sucks, but thank's for the heads up. I'll disable the i9xx snapshot for now. Koby, snapshots from before January 24 should still work. But you'll obviously not have rotation support. re-doing snapshot to use the modular tree is a bit of work though.. Getting snapshots from the modular tree to work will probably require that a modular Xorg is installed somewhere on the build machine. I may get away with installing a modular Xorg on the build machine in some dummy location that doesn't interfere with the Xorg 6.8 installed by the distro (Ubuntu Breezy). Then I can build the driver modules and some other stuff for the common snapshots against that. Alternatively I can build a semi-complete modular Xorg every time. Any other ideas? Regards, Felix Dave. On Wed, 8 Feb 2006, Koby Leung wrote: Hey everyone, Just wanted to drop a note to see if anyone was working with this yet, and to see if I could offer assistance. I'm open to anything, and will supply any log files or other assistancethat you'd like. Thanks in advance! Koby -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon X1600?
Am Dienstag, den 07.02.2006, 10:31 -0500 schrieb [EMAIL PROTECTED]: Actually, I've been having trouble with my Xpress 200M locking up in 2D mode. I'm still trying to determine what the cause of the lockup is. OT: The radeon driver locked up on my Xpress 200 until I disabled color tiling. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Auto-discovery of 3D applications
One more show-stopper for auto-discovery of OpenGL apps is the fact that some applications load libGL dynamically at run-time. I haven't got any feedback to my GL application survey, but at the moment I see a built-in database (does lookup-table sound less scary?) of known GL applications as the only realistic solution. I will have to rely on user-feedback for new entries. I'm hoping that the existance of an application menu with a lack of entries will provide sufficient incentive. Regards, Felix Am Sonntag, den 29.01.2006, 19:35 -0800 schrieb Donnie Berkholz: Felix Kühling wrote: Yeah, but these are exactly the hard cases that are most confusing to users and that I'm trying to solve. Also some executables don't have very descriptive names, like fgfs for FlightGear. It's also impossible to sort auto-detected applications into meaningful categories. Maybe parsing of the menus of the desktop environment would be feasible instead? http://freedesktop.org/wiki/Standards_2fmenu_2dspec defines a distro-neutral standard for such menus. On my Debian box the Gnome menus aren't too helpful in terms of completeness and categorization of applications. But the Debian menu would come pretty close. Do other distributions have something equivalent? I agree on some of your points, but maintaining a database of all 3D applications in existence will probably be a ton of work, won't scale well, and will always be missing stuff, so any alternative would be welcome. As far as the menus go, Gentoo just uses whatever upstream installs. Donnie -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
sizeof(I830DRIRec) does not match passed size from device driver
See https://bugs.freedesktop.org/show_bug.cgi?id=5792 for details. I'm fairly certain that we have solved all installation and configuration issues. What remains is some size mismatch that prevents 3D from working on an i855 with a recent binary snapshot. Could someone familiar with the driver take a look at this please? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
3D application survey for DRIconf
Hi DRI users, for the next version of DRIconf I'm working on a database of known applications that can be selected from a menu. This way users won't need to go through the confusion of finding out the correct executable name any more. However, the range of applications and games I'm using myself is rather limited, so I am conducting this survey. Please send me the names and correct executable names of your favourite 3D applications and games that you configure with DRIconf. Send these to my private email address, NOT to the mailing lists. Depending on the volume of feedback I may want to filter and process the emails automatically, so please send plain-text emails in the following format: Subject: [DRIconfAppDB] arbitrary subject ### category : application name : executable name ... Any lines that do not start with ### (no leading white space) and contain exactly two colons (:) will be ignored by the script I may write. So feel free to add more comments or your signature etc. White space around category, application, and executable names will be stripped. White space inside the names will be preserved. Category names are case-insensitive. So far I have defined the following categories: Benchmarks Games-Arcade Games-RPG (role playing and adventure) Games-Shooter (1st person shooters) Games-Simulation Games-Strategy ModelRender (modelling and rendering) Multimedia ScienceEng(science and engineering) I may also add a category for Xscreensaver hacks. If a category gets too big then I may have to subdivide it further. Please let me and the mailing list know if you think I forgot an important category. All data you provide will be anonymized. No personal information about you will be visible in DRIconf or disclosed to others. ;-) Thanks in advance, Felix Kühling -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Auto-discovery of 3D applications (was: 3D application survey for DRIconf)
Am Sonntag, den 29.01.2006, 14:00 -0800 schrieb Donnie Berkholz: Felix Kühling wrote: for the next version of DRIconf I'm working on a database of known applications that can be selected from a menu. This way users won't need to go through the confusion of finding out the correct executable name any more. However, the range of applications and games I'm using myself is rather limited, so I am conducting this survey. Please send me the names and correct executable names of your favourite 3D applications and games that you configure with DRIconf. Send these to my private email address, NOT to the mailing lists. Depending on the volume of feedback I may want to filter and process the emails automatically, so please send plain-text emails in the following format: Is it possible that this could be dynamically created and cached on each system by checking for applications in PATH that have libGL in NEEDED? Then one could have a Scan for new applications that would re-check. I suppose readelf -a $exe | grep NEEDED ought to work on most systems. That ought to catch the majority of them, except those annoying shell scripts that run something else somewhere else. Yeah, but these are exactly the hard cases that are most confusing to users and that I'm trying to solve. Also some executables don't have very descriptive names, like fgfs for FlightGear. It's also impossible to sort auto-detected applications into meaningful categories. Maybe parsing of the menus of the desktop environment would be feasible instead? http://freedesktop.org/wiki/Standards_2fmenu_2dspec defines a distro-neutral standard for such menus. On my Debian box the Gnome menus aren't too helpful in terms of completeness and categorization of applications. But the Debian menu would come pretty close. Do other distributions have something equivalent? Your readelf trick would work as a filter to identify the 3D applications. Thanks for the hint. Shell scripts would need some heuristics to find the actual executable. This could get messy. A database may be the only way. BTW, readelf is part of binutils. Can one reasonably assume binutils to be installed on every desktop system? Also, what about *BSD? Do they use ELF binaries? Thanks, Donnie Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA / Driver broken if bpp!=16
Am Freitag, den 27.01.2006, 11:33 +0100 schrieb Michael Karcher: Am Donnerstag, den 26.01.2006, 22:31 +0100 schrieb Michael Karcher: Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: I don't have a Savage card to test anything myself. Looks like the driver's ColorMask code depends on the card model. Which card are you using? As the subject says, it is a Savage IX built into a Thinkpad T20. I probably should add that I am using 16bpp, which makes bitmask errors possible. I now tried other depths, which just showed another bunch of problems. If I switch to 24bpp, I get really funny colors in 2D mode, they change with the xgamma setting. I guess the gamma correction tables are messed up. 3D acceleration produces very strange results (picture width horizontally half of what it should be, distorted geometry and colors) which give the impression that some part of hard- or software is assuming 2 bytes per pixel instead of four. Software fallback (as Felix mentioned) in the red/blue stereo case works OK (except for the funny colors already seen in 2D), and looks the same as with LIBGL_ALWAYS_INDIRECT, but of course it is slow. If the color depth makes a difference then it could be related to the z-buffer depth or maybe color dithering. There is nothing you can do about the z-buffer depth (on Savage4 you could experiment with a floating-point z-buffer). But try disabling color dithering in DRIconf. Regards, Felix After that experience I tried 15bpp. In this case 2D looks quite OK. The gradient in the window title of my sawfish theme looks a bit odd with too much red mixed in some steps, but that might be an application bug. 3D acceleration does not work correctly, as warning messages of libgl already say driver claims to not support visual 0x... The output of 3D acceleration looks like it is meant for 16bpp. Software fallback in the red/blue-stereo case does *not* work correctly: The image width doubles, and at some time the application crashes. It looks like rendering for 32bpp, which might be OK. A final note to the 16bpp case: The performance of xmakemol and the User-to-system CPU usage ratio seem to indicate the software fallback, so the question remains: Why is the output wrong? Michael Karcher --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.9.0 released
Am Freitag, den 27.01.2006, 17:45 +0100 schrieb Michel Dänzer: On Thu, 2006-01-26 at 23:24 -0500, Felix Kühling wrote: It is my pleasure to announce a new release of DRIconf, version 0.9.0 of the DRI configuration applet. The source and installation instructions can be found on the project homepage at http://dri.freedesktop.org/wiki/DriConf. Note that updated pre-packaged versions for Linux distributions are not available yet. The .deb is at http://incoming.debian.org/ now and will be in sid within 24 hours. :) Nice. :-) This version introduces a completely redesigned user interface that is intended to be both simpler and more intuitive. If the old user interface resembled the GNOME configuration editor then the new one looks and feels much more like a configuration applet. Thus the big change in the version number. FWIW, I like the new UI much better (it reminded me that I unintentionally overrode some settings for some apps :). My only suggestion would be to hide the default settings in both parts of the UI, on the one hand so that it'll pick up changes to the default values, and on the other hand because it would tidy up the upper part IMO. Matthew suggested to make the option descriptions shorter and add longer descriptions in a tool tip. That would tidy up the upper part but you'd still have the overview of all options. It may require a change in the drivers, though, and possibly a change of the configuration infrastructure itself. I'm going to look into this. I believe I can do this without breaking compatibility between old/new drivers and DRIconf version. On a slightly related note, a drag bar between the parts to change their relative height might be nice. I don't like the drag-bar. In the old UI it tended to mess up the automatic widget space allocation and forced me to hard-code some widget and window sizes in pixels. If this is really an issue I might break out the application settings into a separate dialog instead. Thanks for this great update, keep 'em coming! :) Thanks for the feedback! Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Correcting myself. There have been updates to the Savage driver after I stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and maybe others. Sorry folks, I appreciate your work! Is anyone going to look into this xmakemol issue? Regards, Felix Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: Felix Kühling wrote: Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Correcting myself. There have been updates to the Savage driver after I stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and maybe others. Sorry folks, I appreciate your work! Is anyone going to look into this xmakemol issue? I took a quick look at xmakemol. The first thing I'd check is if the driver code for glColorMask is operating properly. For red/blue stereo, the scene is rendered twice, first with glColorMask(T,F,F,T), then glColorMask(F,F,T,T). I took a brief look to refresh my memory. The difference between Savage3D-based and Savage4-based cards is that Savage4 can disable all drawing in the case glColorMask(F,F,F,F). Maybe useful if you want to render only to the Z-buffer. But I'm not even sure that would work correctly. In all other cases that are not glColorMask(T,T,T,T) the driver will fallback to software. The code looks correct to me but I don't think I ever tested it thoroughly. I don't have a Savage card to test anything myself. Me neither. Looks like the driver's ColorMask code depends on the card model. Which card are you using? Micheal is using a Savage3D-based card. Regards, Felix BTW, the author of xmakemol needs to be taught how to use function prototypes. Put them in a header file; don't repeat the prototype inside each and every function it's used in! -Brian -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] DRIconf 0.9.0 released
Hi DRI users, It is my pleasure to announce a new release of DRIconf, version 0.9.0 of the DRI configuration applet. The source and installation instructions can be found on the project homepage at http://dri.freedesktop.org/wiki/DriConf. Note that updated pre-packaged versions for Linux distributions are not available yet. This version introduces a completely redesigned user interface that is intended to be both simpler and more intuitive. If the old user interface resembled the GNOME configuration editor then the new one looks and feels much more like a configuration applet. Thus the big change in the version number. !!! WARNING !!! The new code changes the structure of your configuration file in order to be able to represent it in the simplified user interface. In general that should not change the effect of the configuration file. But that code has not been widely tested yet. So if you can't afford to loose your settings please make a backup copy of your configuration file first (~/.drirc). Please report any problems you find on one of these mailing lists. Include a copy of the original configuration file in the report so that I can reproduce and investigate the problem. Unfortunately the amount of changes in the user interface means that the translations (except the German one) aren't up-to-date. I hope I will be able wrap up another release in a few weeks with updated translations. I wouldn't mind adding a few new ones at the same time. If you'd like to translate DRIconf to your language, just follow the instructions at the top of the Makefile that is included in the source tarball. Distribution packagers may want to take a look at this release. But I suggest to wait for the next version that will include updated translations (unless I have to make a bug-fix release sooner than that). Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FreeBSD CURRENT + DRM + agp_ati
Am Donnerstag, den 29.12.2005, 20:40 -0500 schrieb Adam K Kirchhoff: [snip] What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! So not only does setting the debug sysctl seem to affect the framerate, so does displaying the framerate within the application. If I launch any of those xscreensaver apps with the -fps option (including flurry, glforestfire, flipflop, queens, and flyingtoasters), I get quite reasonable framerates. If I launch them without the -fps option, I get 1 FPS if I'm lucky (and I mean that literally... The window only updates itself once every second, if that). -fps causes a software fallback which implies a glFinish. Without -fps it hits no software fallbacks and interrupt-based frame-throttling will be used. Maybe interrupts get lost so that you time-out in the frame-throttling code (radeon_wait_irq has a 3-second time-out ATM). That would explain low frame rates. With debugging output the waiting condition is probably true when it gets to radeon_wait_irq most of the time, so it doesn't have to wait - no time-out. Can you try playing with the fthrottle_mode option to test that theory anyway. fthrottle_mode=0 glxgears would run glxgears with busy-waiting instead of interrupts. Regards, Felix Here's the output from 'glxgears -info' with LIBGL_DEBUG set to verbose: [ [EMAIL PROTECTED] - ~ ]: glxgears -info libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so drmOpenByBusid: Searching for BusID pci::01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:05.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI Radeon 20051013 AGP 4x NO-TCL GL_VERSION= 1.3 Mesa 6.5 GL_VENDOR = Tungsten Graphics, Inc. GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_S3_s3tc 177 frames in 7.0 seconds = 25.286 FPS 4 frames in 6.0 seconds = 0.667 FPS 7 frames in 7.0 seconds = 1.000 FPS Adam -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
No DRI snapshot builds during vacation
Hi, I'll be on vacation from December 20 until January 7. During that time I won't be able to build and upload DRI snapshots. If anyone wants to provide snapshot builds in the mean time, the entire set of scripts is in CVS in the repository :ext:your user ID@dri.freedesktop.org/cvs/dri in the snapshots directory. This is what you need: * a fast internet connection * about a gigabyte of free disk space (the sources alone eat about 360MB) * some spare CPU cycles * a freedesktop ssh account in the dri group (for upload permissions) Change the DEVELOPER=... line in config.sh and you should be good to go. Just run all.sh for the complete build, packaging and upload. Detailed build logs are saved in the log subdirectory. report.sh generates and mails automated failure reports. But only use this once you're sure the build system itself is solid. If you need assistance to get the build system to work, I will have access to email. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Stuck with FC4 / i915 Graphics
This is the second report of an i810 user getting a black screen. In both cases the server log files submitted are incomplete. Something is going wrong here, but I don't know what it is. Can anyone familiar with the i810 driver comment? Lilian, Steph: could you provide one more data-point? When you started X and the screen is blank, can you switch virtual consoles or log in via ssh and check if the Xserver is still running (ps aux | grep X). The incomplete log files make me believe that the Xserver may be dying a rather horrible death for some reason in the middle of the driver initialization. Thanks, Felix Am Dienstag, den 06.12.2005, 22:42 +0800 schrieb Steph: Hi All, I have been trying to get DRI for my Fedora Core 4 install with no luck. Been at it on and off for about 4 days and have tried just about everything I can think of, so I figured it was time to ask for help! I am fairly familiar with linux, have no problems working in the console, compiling for source etc, although I have very little understanding of how the kernel and related modules work. Ok, here is what I have installed: Fedora Core 4, Updated using Yum, Using xorg-x11-6.8.99.14-3 from here (http://sergiomb.no-ip.org/xorg/xorgRC2/ - followed the instructions on that page to install it). I have a motherboard with the Intel 915 chipset on it. Right now I can only get X to start using the 'vesa' driver, and not at all using the i810 driver. I cant get the i915 driver to load. A few things: Result of dmesg | grep drm (run while X was running with Vesa driver): [drm] Initialized drm 1.0.1 20051102 [drm] Initialized i915 1.2.0 20041217 on minor 0: [drm] Module unloaded Result of dmseg | grep agp (run while X was running with Vesa driver): Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 915G Chipset. agpgart: Detected 32508K stolen memory. agpgart: AGP aperture is 256M @ 0xd000 When I try and startx with the i810 driver, I just get a blank screen, but no obvious errors in the logfile! I have attached the X logfile. Can anyone give me any advice where I go next? Unfortunatly I have to use Maya (3d program) for work, and since the License uses the mac address on the network card, I can use the linux version as well as the windows one on my machine. Unfortunatly it wont work properly without the right graphics driver :-( Any help would be much appreciated, Thanks, Steph -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
Am Samstag, den 26.11.2005, 10:47 -0700 schrieb Brian Paul: Aapo Tahkola wrote: On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul [EMAIL PROTECTED] wrote: I've been playing around with the EGL r200 driver. Digging through the framebuffer allocation code I've found a few problems. In order to support pbuffers and framebuffer objects we need to be able to work with color/depth/stencil buffers are various locations in video memory. The current code sets the front/back/depth buffer offsets and pitches once in the radeon_do_init_cp() function and there's no way to change them thereafter. It looks like the only code that uses this information is the glClear and SwapBuffers-related code in radeon_cp_dispatch_clear(), radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code that enables/disables color tiling. Could someone more familiar with the code comment on what it would take to fix the code so that color/depth buffers at arbitrary locations can be used? I'd probably do away with the front/back_offset/pitch fields entirely and pass the offset/pitch values as parameters to the ioctls. I'd also write the code so there's no distinction between front/back color buffers. Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. I was wondering about that too. There may be some reason for doing those things in the kernel, but I don't know of any. At least on some hardware buffer clearing and swapping is done by the 2D engine. Instead of exposing the necessary functionality through some generic blit or fill ioctls, specific clear and swap operations were implemented. The fact that the Xserver provides the offsets and pitches adds some sense of security by preventing untrusted clients from overwriting random memory. I believe it should be possible to replace clear and swap ioctls with generic blit and fill ioctls that do some range checking on their arguments. -Brian Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: problem found with new xorg-6.9RC2 on savage with DRI enabled
What does your host.def file look like? What I'm getting at, when you build Xorg 6.9RC2, do you use the Mesa copy in extras or do you point MesaSrcDir at a different Mesa checkout? Regards, Felix Am Dienstag, den 15.11.2005, 20:39 + schrieb Sergio Monteiro Basto: On Mon, 2005-11-14 at 12:38 -0800, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergio Monteiro Basto wrote: On Mon, 2005-11-14 at 07:51 -0800, Ian Romanick wrote: Sergio Monteiro Basto wrote: Today, I test chromium, tuxracer and foobillard and none of then runs try to dig with gdb and all stop on run_texnorm_stage() here is the debug with backtrace: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1208801600 (LWP 12723)] 0x00ec8a80 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/savage_dri.so (gdb) cont Continuing. What platform are you running on? Properly built drivers on Linux or BSD should *NEVER* encounter this code. That code has been removed from the Linux builds for almost a year. I suspect that you're either picking up a very old savage_dri.so or something is not right with your build. The code is #ifdef'ed out at line 186 of src/mesa/x86/x86_common.c: #if defined(__linux__) !defined(IN_DRI_DRIVER) Clearly, IN_DRI_DRIVER should be defined when building the Savage DRI driver! :) Hi, Well I downgrade to xorg-6.9RC1 and the problem disappears, so is a very recent regression. About IN_DRI_DRIVE, yes it is defined at all the places. With RC1 I still get this Arithmetic exception but 3D apps works without problems. If I recall correctly this Arithmetic exception is not new at all. BTW don't know if meters but my laptop is one mobile AMD Athlon(tm) 4 Processor thanks (for your time), I will go investigate this, but this is not the problem because this doesn't stop the app. That is true, but there are other places in the code that depend on IN_DRI_DRIVER being correctly set. If it's not set at this place, it is likely that it's not set at the other places either. Having it not set in the other places may be the source of the crash. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Cedega r200 CVS.
Am Sonntag, den 13.11.2005, 20:39 -0500 schrieb Gavriel State: Felix Kühling wrote: There is a known problem with applications that load libGL dynamically with RTLD_LOCAL. Not sure if this is the problem in this case, but the symptom (driver not finding a symbol that should be exported by libGL) and the fact that it's application-dependent point in that direction. I vaguely remember hearing about a Cedega patch for this issue. Cedega doesn't load libGL dynamically with RTLD_LOCAL. As Cedega starts up, it loads some other libraries dynamically with dlopen, and one of those libraries is command-line-linked to libGL. The libraries that are loaded with dlopen are opened with RTLD_LAZY. AFAIK RTLD_LOCAL is the default is RTLD_GLOBAL is not specified. (RTLD_LOCAL is defined as 0 in /usr/include/bits/dlfcn.h. ;-) What's the origin of this issue on the DRI side, and is it likely to be fixed in the future? Short answer: no. The DRI drivers are no longer linked against a specific libGL. This is to enable loading of the same driver binaries in different libGLs or the Xserver itself for indirect accelerated rendering. Basically all dependencies on the window system were moved out of the DRI drivers and into libGL. The drivers are not linked against libGL, they just expect that they can magically see symbols from libGL or whoever loaded the driver. When libGL itself is loaded dynamically without RTLD_GLOBAL the driver can't see those symbols and loading fails. Take care, -Gav Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Cedega r200 CVS.
Am Samstag, den 12.11.2005, 11:01 -0500 schrieb Adam K Kirchhoff: So I heard from someone on the transgaming forums that Morrowind is running just as fast with the DRI drivers as it with the drivers from ATI on their system. Which surprised me, since it was painfully slow on my machine. I gave it another shot, but this time setting LIBGL_DEBUG to verbose. When I tried to launch Morrowind, I noticed an undefined symbol: _glapi_Dispatch error when libGL tried to load r200_dri.so. However, all native apps run just fine, and I get the following from glxinfo: GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI R200 20050831 AGP 4x TCL GL_VERSION= 1.3 Mesa 6.5 GL_VENDOR = Tungsten Graphics, Inc. Any ideas? There is a known problem with applications that load libGL dynamically with RTLD_LOCAL. Not sure if this is the problem in this case, but the symptom (driver not finding a symbol that should be exported by libGL) and the fact that it's application-dependent point in that direction. I vaguely remember hearing about a Cedega patch for this issue. Adam Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm stable branch created
Am Freitag, den 11.11.2005, 13:38 -0500 schrieb Adam Jackson: Please note that libdrm now has a 1.0 branch. If you make changes to the DRM headers like the recent via_drm.h updates, such that drivers will need them to build, make sure they are applied to the 1.0 branch as well. A rough roadmap for libdrm 1.1: - Build and install the test apps by default - Add xdriinfo to the test app suite I don't see what xdriinfo has to do with libdrm. It does not talk to the DRM at all. It only interacts with the Xserver's DRI extension and libGL. libGL loads DRI drivers on xdriinfo's behalf but never initializes them. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Why does libdrm configure.sh check for C++ compiler
The weirdest thing. Trying to get the snapshots building on a new computer I ran into trouble because libdrm's configure.sh checks a C++ compiler and fails if none is installed. What does libdrm need a C++ compiler for? I couldn't see anything suspicious in configure.ac, but then again, I don't know much about automake. Any ideas anyone? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Looking for i915 build info
Am Dienstag, den 08.11.2005, 17:05 -0400 schrieb Dave Kavanagh: I am looking at adding vblank synchronization support to the i915 driver. I have a few questions on how all of the pieces fit together and where the source code comes from. From my understanding, the snapshots such as i915-20051107-linux.i386 contain source code that is built to update the kernel DRM modules (i915.ko and drm.ko). The snapshot also contains binary files (i915_dri.so and i810_drv.o) that are copied over the existing X modules. i810_drv.so in the latest version. ;-) We're using the DLLoader now. My question is this. Where is the source code that builds the new X modules? I found the code that builds the original modules in the X source but I can't find the source for the updated modules. The DDX (2D) driver modules are built from Xorg CVS HEAD. The DRI (3D) driver modules are built from Mesa CVS HEAD. I am very new to DRM/DRI so I may be missing something but it seems to me that adding vblank synchronization support will require modifications to both the DRM and DRI parts of the equation. I don't know what the status of this is in the i915 driver. But in general you are right. Both DRM and DRI need support for vblank synchronization, for example by using IRQs. Can somebody enlighten me? Any information is appreciated. Thanks, Dave Kavanagh Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRI binary snapshots
Hello DRI testers, I finally got around to bringing the snapshot build up to speed with the latest changes in the build process and uploaded a first set of new snapshots to http://dri.freedesktop.org/snapshots/. They are completely untested so be prepared for problems with the first couple of rounds. Please report any issues with the snapshots to [EMAIL PROTECTED] As long as they are problems with the snapshot build and packaging process I will try to resolve them ASAP. The new snapshots also include a package for the experimental R300 driver. I hope the R300 developers are fine with exposing their work to a larger audience. ;-) Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 unstable with TCL enabled
Am Freitag, den 07.10.2005, 15:20 + schrieb Jacek Popławski: On Fri, Oct 07, 2005 at 02:25:26PM +0200, khaqq wrote: Sounds close enough to what I'm running here, stable too, and I had frequent lockups before (6.8.2). I had noticed the lockups would occur less frequently without TCL. Now it's perfectly stable with or without TCL. So it is possible to have stable and fast OpenGL with open soruce drivers and Radeon (I still can't crash it!). But are there binary snapshots for end users available? I found only old ones. xorg is available only as source and Mesa/drm only as source from CVS. Will http://dri.freedesktop.org/snapshots/ be updated? Eventually. I haven't got around to adjusting the snapshot build scripts to changes in the build process (libGL from Mesa and libdrm via pkgconfig come to mind). It will be a week before I have time to look into it (hopefully). You're welcome to beat me to it. ;-) In the mid-term I intend to build snapshots from the modular tree. But that's a slightly bigger project. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM MTRR's
In the savage DRM driver I added some code that uses knowledge about adjacent address ranges and BAR sizes (as opposed to the actual VRAM size) to allocate the minimum number of MTRRs. This was the only way to cover the frame buffer and additional frame buffer apertures without wasting too many MTRRs. It still relies on the automatic MTRR setup on some hardware where it does the right thing. See savage_bci.c function savage_driver_firstopen for details. Regards, Felix Am Freitag, den 23.09.2005, 12:42 +0100 schrieb Alan Hourihane: On Fri, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: Has anyone any objections to me removing the MTRR code from the DRM. It doesn't have the intimate knowledge needed to properly configure MTRR's and fails in many cases. There are two cases currently, one for the framebuffer and a second for the entire AGP space. Certainly in Intel hardware this is the same memory space and you always get bogus error messages in your kernel logs as things fail due to lack of boundary checks. I'm more of the opinion that it should be left up to userspace to configure MTRR's if it indeed wants them and we shouldn't force them within the DRM. Additionally, the Xserver (for user-space) already sets up the MTRR's, as should Xgl (Xegl) or other user space apps. What makes the situation a little worse is that vesafb (and other *fb drivers) also setup an mtrr which frequently stops subsequent processes from adding a new one that overlaps an existing write-combining range. But the *fb drivers do provide a nomtrr option in many cases. (But I'd like to remove it from them too :-) or at least default those to off) Comments ?? One thing to add, is that I did initially look at just removing DRIVER_USE_MTRR from the intel DRM, but it really doesn't satisfy other use cases for the other chipsets. Again, inline with the fact there may already be existing mtrr's setup and the DRM fails to honour proper checking. But I'm interested in others comments on this. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: State of the SiS driver
Am Sonntag, den 14.08.2005, 12:04 +0200 schrieb Philipp Klaus Krause: I have some questions about the SiS driver: 1) The SiS driver looks different from the other drivers. It doesn't have a custom tnl_pipeline as all the other drivers except tdfx do. Was this some old style of writing drivers and all others have already been converted? The custom tnl_pipeline is merely an optimization for the more-or-less common case of unclipped primitives. Depending on the capabilities of the hardware more restrictions apply (e.g. one-sided lighting, with some primitives flat shading may not be supported, ...). Mesa drivers can work without a custom tnl_pipeline. It's not a replacement for the general case though. All drivers have the standard _tnl_render_stage as last fallback stage in the pipeline. Regards, Felix 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? 3) Is there any documentation for the SiS 305. I mean, what did the people that wrote this driver use? Or is it just a 6326 with another texture unit added so the documentation for the 6326 was used? The wiki says there is no documentation except that two documents from UtahGLX which obviously aren't enough for writing a driver. Was this driver released by SiS or was the chip reverse-engineered? Philipp -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRIconf release 0.2.7
Hi DRI users and developers, I released a new version of DRIconf. This release includes new Italian and Russian translations by Giampaolo Bozzali and Konstantin A. Lepikhov. The other important change (especially for packagers) is the changed installation path for the python modules. They are now installed into /usr/local/lib/driconf. The driconf startup script explicitly looks for them in that directory. This should solve the problems on some distributions where /usr/local/lib/python-x.y/site-packages was not in the default module search path. Packagers can edit setup.cfg in order to change the installation path. In that case you should also change the driconf startup script accordingly. In terms of functionality 0.2.7 is identical to 0.2.6. The downloads can be found at http://dri.freedesktop.org/wiki/DriConf, as usual. Packagers are very welcome to add or update links to their packages. Thanks to all contributors and packagers. Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM hook renaming
Hi Eric, Nice change. I looked over the savage changes and the only thing that I noticed was the comment before the new savage_driver_firstopen. The MTRRs are deleted in lastclose, not unload. The code actually does the right thing. Otherwise it looks good as far as Savage is concerned. Cheers, Felix Am Mittwoch, den 03.08.2005, 17:00 -0700 schrieb Eric Anholt: Here's a proposed patch to rename the driver hooks to something that I feel is a bit more sane. The renames: preinit - load postinit - (removed) presetup - firstopen postsetup - (removed) open_helper - open prerelease- preclose free_filp_priv- postclose pretakedown - lastclose postcleanup - unload release - reclaim_buffers_locked version - (removed) - postinit was (almost always) just used to print out description and version information. It was the same across almost all drivers. The exceptions were the intel chipsets and MGA, where they did some counters setup, which was moved into load for the same effect as before, I believe. - postsetup was totally unused. - version got replaced by setting the values in the driver struct. - radeon's preinit handler should have been a postsetup (now firstopen) because it's setting up mappings which get torn down on lastclose. - savage had its handlers split up to deal with mapping setup better, as well. - Note that the diff is kinda noisy because I moved the BSD stuff to have the driver fields in a similar way as Linux. - I tried to generally order the setup/teardown hooks as load/firstopen/open/preclose/postclose/lastclose/unload in the code, for sanity. My cheapo approximate diff-line-counter says: Add: 663 Del: 917 I've only tested this on a couple cards, on FreeBSD, so far. I'm hoping for someone else to do a read-through review to catch dumb mistakes. I'll test on Linux before committing, if someone else doesn't beat me to it. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 80 column format
Am Montag, den 27.06.2005, 15:56 -0400 schrieb Vladimir Dergachev:
I have been going through R300 drm source trying to implement all the
suggestions that people offerred.
I am having some hard time with 80 column rule. Now, in general, I agree
with it and it makes sense. However take a look at the following piece of
code:
/ snip * line 264 r300_cmdbuf.c /
for(i=0;isz;i++){
values[i]=((int __user*)cmdbuf-buf)[i];
switch(r300_reg_flags[(reg2)+i]){
case MARK_SAFE:
break;
case MARK_CHECK_OFFSET:
if(r300_check_offset(dev_priv, (u32)values[i])){
DRM_ERROR(Offset failed range check
(reg=%04x sz=%d)\n, reg, sz);
return DRM_ERR(EINVAL);
}
break;
/ snip /
To me it looks perfectly fine - we have a for cycle, a switch statement
inside and an error check in one of switch statement clauses. I don't see
how separating these out into other functions is going to improve
readability.
Problem is that there is no sane way I can fit the error message in 80
columns without being cryptic.
Any ideas ?
Not indenting case labels saves you 8 columns. Also you can split
strings like this:
DRM_ERROR(Offset failed range check
(reg=%04x sz=%d)\n, reg, sz);
Or refactor the code like this, saving another 8 columns for the error
message by avoiding one nesting level:
switch(r300_reg_flags[(reg2)+i]){
case MARK_SAFE:
break;
case MARK_CHECK_OFFSET:
if(!r300_check_offset(dev_priv, (u32)values[i]))
break; /* Check passed. */
DRM_ERROR(Offset failed range check
(reg=%04x sz=%d)\n, reg, sz);
return DRM_ERR(EINVAL);
Use your fantasy! ;-)
thank you !
Vladimir Dergachev
Cheers,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 initial PCI-express patch .. not working ...
Am Donnerstag, den 02.06.2005, 08:56 -0400 schrieb Alex Deucher: On 6/2/05, Dave Airlie [EMAIL PROTECTED] wrote: I tried the patch on my x800 (0x554F), but no luck here either; hangs nicely. I haven't tried fglrx yet. well I got fglrx 8.12.10 up and running last night (had to install FC3 no idea why it didn't like ubuntu.) hmmm... I guess I may have the same issues as I'm also running ubuntu... The problem I had with fglrx and Ubuntu was that it doesn't include matching kernel headers for its kernel so the fglrx kernel module compilation fails. So I downloaded a kernel-source package from Debian unstable and compiled that from source. Regards, Felix At least I have some hope of figuring out the registers beyond the highly useful docs :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing install.sh dependancy on ed
Hi Roy, Sorry for the late reply. I have applied the first part of your patch and changed the check for 'ed' into a check for 'sed' instead of removing it. However, the snapshot build host seems to be down since May 18, so no new snapshots with the fixed install.sh will be available until this is fixed. Regards, Felix Am Mittwoch, den 25.05.2005, 13:58 +0100 schrieb Roy Marples: Hi! ed was recently removed from Gentoo's default profile - and dripkg's install.sh requires ed. install.sh also uses sed, so why not just remove the ed dependancy from install.sh? Here's a patch which does just that. Thanks -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Change of focus
Hello everybody, I am writing this mail as to let you all know that my focus with respect to DRI development is changing and that I will no longer be able to work on the Savage driver. As of Tuesday I am an employee of ATI Technologies, Inc. I relocated to Toronto, Canada last weekend. I no longer have any Savage hardware here, and even if I did I would be in a very frustrating position of not being allowed to officially work on the driver since that would conflict with my interests as an ATI employee. I had informed a few people of this upcoming change a couple of months ago in the hope to find someone to take over maintainership of the Savage 3D driver, but no one stepped up so far. I sincerely hope that the Savage driver will not become bit-rot. I'd like to thank everybody who has contributed to the Savage 3D driver while I've been working on it. My interest in DRI in general has not ceased though. I'm working in ATI's Linux team, so I will be dealing with DRI in one way or another. Once things settle down a little here (need to find an apartment and everything) I will probably continue contributing to the open source DRI development, though as far as hardware-specifics are concerned, I will be limited to ATI hardware. Best regards, Felix -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02alloc_id135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Latest savage snapshot doesn't work
I haven't changed anything in the Savage DRM in a while. Must be some change in the generic drm module. I won't be able to look into this. Does the oops below ring a bell, anyone? Regards, Felix Am Samstag, den 21.05.2005, 14:22 +0200 schrieb Jacopo Ghigleri: Hi. I just tried the latest savage snapshot (20050517) and it doesn't work: drm modules compile and install just fine, drivers install too, but there is a problem (oops) upon loading the savage module: here is what my dmesg says: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #2:[EMAIL PROTECTED] for device :01:00.0 mtrr: 0x9000,0x800 overlaps existing 0x9000,0x100 Unable to handle kernel NULL pointer dereference at virtual address printing eip: *pde = Oops: [#1] PREEMPT Modules linked in: savage drm ip_nat_irc ip_nat_tftp ip_nat_ftp ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00013246 (2.6.11-gentoo-r4) EIP is at 0x0 eax: 0005 ebx: ecx: edx: cef37220 esi: cb9e1000 edi: cdd00c00 ebp: cef37170 esp: cbcb6f4c ds: 007b es: 007b ss: 0068 Process modprobe (pid: 10124, threadinfo=cbcb6000 task=ccfeaa80) Stack: cef88f4b cb9e1000 0005 cef37170 cef37220 cef37170 cdd00c00 cef3718c cef37220 cef857f1 cdd00c00 cef37170 cef37220 cbcb6000 cef373c0 08049460 cbcb6000 ce816017 cef37220 cef36f40 c0131f1f c04ec1c8 Call Trace: [cef88f4b] drm_get_dev+0x9b/0x130 [drm] [cef857f1] drm_init+0x111/0x170 [drm] [ce816017] savage_init+0x17/0x1b [savage] [c0131f1f] sys_init_module+0x16f/0x220 [c01031af] syscall_call+0x7/0xb Code: Bad EIP value. The two modules (savage and drm) appear loaded from lsmod, but glxinfo reports indirect rendering and glxgears results are in agreement with this. Some info on my sistem: prosavage kn133 (twister k), Gentoo Linux with Xorg 6.8.2, revision r1-0.1.2, kernel 2.6.11-gentoo-r4. Thanks in advance, Jacopo --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-users -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri_client and drm.h
Am Freitag, den 20.05.2005, 13:09 +0100 schrieb Dave Airlie: At the moment we use drm.h from the shared directory in the drm, I'm going to switch this to the shared-core directory, Maybe we're not talking about the same thing, but I did change mesa/src/mesa/drivers/dri/Makefile.template to use the drm.h from shared-core when I committed the new Savage DRM in January. I'm also wondering that currently we have a copy of libdrm in dri_client, can we not symlink the files out of the drm? I know ajax was moving towards a shared version of libdrm, but maybe this should happen first... the main reason I'm wondering is there is a C++ keyword in drm.h and the less places I've got to hunt down and remove it the better... Dave. -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
Am Freitag, den 20.05.2005, 09:22 -0400 schrieb Vladimir Dergachev: Hi all, I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Known issues/help needed: * Radeon 9800 cards are still exhibiting an occasional lockup. * It would be interesting to know whether the driver works with some of the newer cards (like Radeon X800) I've got a new Notebook with an X600. I have to test this some time soon. It may be a week or two before I get a round to it though (I haven't even had time to try fglrx on it yet ;-). Anyway, you guys have done amazing work on the r300 driver. It sounds like it's become really usable for everyday use by now. * Also see the list at http://r300.sf.net/r300_dri.php Big thanks to everyone who contributed to this release, especially Aapo Tahkola, Ben Skeggs and Nicolai Haehnle ! enjoy ! Vladimir Dergachev Best regards, Felix -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Direct rendering problem with quake2 on Radeon 8500
I think you can spend a lot of time on this problem, but maybe we should check some simpler things first: * which 3D driver are you using? From Xorg CVS or Mesa CVS? The latter one is the most up-to-date. With LIBGL_DEBUG=verbose you can check which driver binary is being used, just in case ... * Are you using any radeon driver options in xorg.conf? Don't use AGP fast writes. Maybe try different AGP speeds. Or maybe a different color depth helps. * Are you using any 3D driver options (driconf)? You may be able to work around some lockups by disabling TCL, HyperZ and/or using different frame throttling methods. * Are you only getting lockups with quake2 or also with other 3D apps? * Which Radeon version do you have exactly? More comments about the hard way below ... Am Donnerstag, den 19.05.2005, 15:27 +0600 schrieb Dimitry Naldayev: Felix Khling [EMAIL PROTECTED] writes: [snip] top - 11:02:53 up 19:53, 8 users, load average: 1.22, 0.57, 0.25 Tasks: 59 total, 3 running, 54 sleeping, 0 stopped, 2 zombie Cpu(s): 0.3% us, 99.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem:255232k total, 185004k used,70228k free,29812k buffers Swap:0k total,0k used,0k free, 117208k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1444 root 25 0 148m 5832 3332 R 99.3 2.3 1:59.36 X 1423 dima 15 0 2628 1084 908 S 0.7 0.4 0:01.30 esd 1487 dima 16 0 1864 964 764 R 0.3 0.4 0:00.14 top As I can see --- all cpu power eaten by X server, but I cant kill it :( even with help -9 or -11 signal 8o probably because the proces is in system (kernel) mode... [snip] Try to find a version in CVS that works and then narrow it down to one specific commit that introduced the problem. This will be time consuming and not very exciting though. now I rewert to clean (ie stable) xorg-6.8.1 build from source. Are you also using the Mesa 3D driver from xorg-6.8.1? The problem is most likely in the 3D driver. Try reverting Mesa CVS to an older version (cvs update -dP -D date) and recompiling the 3D driver from there. Make sure that the new (old) driver actually gets used. (but I do not change drm module... it look like xorg source do not contain drm sources) this not help much :( quake crached after a minute or two. only garbage on the screen and locked mouse... but Xserver itself not locked I can shutdown Xserver by keyboard... coredump for quake2 not generated regardless I set ulimit -c unlimited but there is a message in the log of running quake2: Error: R200 timed out... exiting [ from your other mail] but... why I can't kill X server? 9 signal is very powerfull, but not work Your top-output above shows that it's spinning in kernel mode. That's why you can't kill it. What I can do farther? any ideas? can this problem be related to drm module? Probably not. The DRM is just stupid to wait forever for the graphics engine to become available. But the actual trigger for the lockup is most likely in the 3D driver. what other drm modules I can try ? You can do the same with DRM CVS as with the Mesa CVS above. [snip] Probably quake2 or the 3D driver segfaults before the mouse grab and graphics mode can be restored, possibly in r200DestroyContext. If it's crashing in the graphics driver this should be fairly easy to track down. Enable core dumps (ulimit -c unlimited) and analyze the core dump with gdb to see where it crashed (gdb -c core `which quake2`). I set ulimit -c unlimited... but were is core dump? I cant find it :( nor for quake2 nor for quake3 (quake3 finished with signal 11) The core dump should be in the current working directory. Sometimes it's called core.pid. Which shell are you using. Ulimit is a built in command in bash. I don't know if it works the same in other shells. OTOH quake2 may not be crashing because of a segfault. Sometimes I saw quake2 die because of some invalid commands it sent to the Xserver. In that case you should see an error message in the terminal where you started quake2. -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Direct rendering problem with quake2 on Radeon 8500
Am Mittwoch, den 18.05.2005, 11:29 +0600 schrieb Dimitry Naldayev: Felix Khling [EMAIL PROTECTED] writes: Am Dienstag, den 17.05.2005, 11:19 +0600 schrieb Dimitry Naldayev: Hi all. I cant get direct rendering whit quake2 :( the quake2 reports inderect rendering have useed :( see log of quake2 report in attachments. I suspect that this is a known problem with applications loading libGL dynamically with RTLD_LOCAL. It makes symbols in libGL unavailable to the 3D drivers. Therefore direct rendering is broken with such applications. A workaround is to export LD_PRELOAD=path to libGL in the environment before starting quake2. yes. This help me. Is this a good idea build libGL from Mesa cvs tree not from xorg cvs tree ? and why ? I haven't tried building libGL from Mesa CVS yet. But AFAIK it shouldn't make a big difference. I haven't been following that development so I can only speculate about the exact differences. but I have next problem: X server locked after a few minutes playing in quake2 ;( My computer do not react on mouse or keyboard activity... but this is not bus lock --- mplayer is contining playing music and I can login on the computer through SSH. it is the head of top output: top - 11:02:53 up 19:53, 8 users, load average: 1.22, 0.57, 0.25 Tasks: 59 total, 3 running, 54 sleeping, 0 stopped, 2 zombie Cpu(s): 0.3% us, 99.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem:255232k total, 185004k used,70228k free,29812k buffers Swap:0k total,0k used,0k free, 117208k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1444 root 25 0 148m 5832 3332 R 99.3 2.3 1:59.36 X 1423 dima 15 0 2628 1084 908 S 0.7 0.4 0:01.30 esd 1487 dima 16 0 1864 964 764 R 0.3 0.4 0:00.14 top As I can see --- all cpu power eaten by X server, but I cant kill it :( even with help -9 or -11 signal 8o probably because the proces is in system (kernel) mode... Sounds like a graphics engine lockup. Some process keeps holding the lock waiting for the engine to become available, which it never does because it's locked up. In the mean while X tries to grab the lock and fails. So it keeps retrying, eating 100% CPU. Just a theory though. There have been reports about instabilities with r200-based cards. It was introduced by some driver change last year. But AFAIK noone got around to tracking it down. :-/ what I can do? and how I can debug the problem? Try to find a version in CVS that works and then narrow it down to one specific commit that introduced the problem. This will be time consuming and not very exciting though. PS: I have more problems: If I exit from quake before X locked --- the mouse locked (or grabbed ??) I cant use it :( the mouse cursor placed in the left top corner of display. and size of display do not returned to normal rezolution... but keyboard work and I can cleanly shutdown X server... Why this can be? Probably quake2 or the 3D driver segfaults before the mouse grab and graphics mode can be restored, possibly in r200DestroyContext. If it's crashing in the graphics driver this should be fairly easy to track down. Enable core dumps (ulimit -c unlimited) and analyze the core dump with gdb to see where it crashed (gdb -c core `which quake2`). (Caution, quake2 may be a shell script. You must point gdb the actual executable instead.) In gdb use the bt command to see a call stack trace. up and down jump between stack frames. Use print to inspect variables. (This is just general advise. I don't have any r200 hardware myself ATM.) -- Dimitry HTH, Felix -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Direct rendering problem with quake2 on Radeon 8500
Am Dienstag, den 17.05.2005, 11:19 +0600 schrieb Dimitry Naldayev: Hi all. I cant get direct rendering whit quake2 :( the quake2 reports inderect rendering have useed :( see log of quake2 report in attachments. I suspect that this is a known problem with applications loading libGL dynamically with RTLD_LOCAL. It makes symbols in libGL unavailable to the 3D drivers. Therefore direct rendering is broken with such applications. A workaround is to export LD_PRELOAD=path to libGL in the environment before starting quake2. [snip] HTH, Felix -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dropped polygons on savage
Am Samstag, den 30.04.2005, 22:53 -0500 schrieb Steve Holland: I find that the current savage snapshot (20050430) seems to randomly drop individual polygons or polygon strips (they become transparent to background). Hardware is SuperSavage/IXC (IBM Thinkpad T23) on FC3/linux 2.6.11.2. I noticed this sometimes too, but I was never able to reproduce it reliably. Does the problem go away if you set the enable_fastpath option to false? Testcase: Aviascene http://69.5.151.193:81/~sdh4/aviascene (problem is most severe with texturing off (press t)) Screenshot: http://69.5.151.193:81/~sdh4/savagebug.png Problem did not occur with 20041108 snapshot or prior, or with direct rendering disabled, or with other DRI drivers. Lots of changes have occurred in the driver since 2004. It can't be a DMA problem because the driver can't use DMA on SuperSavages. The fastpath is my next suspect (see above). Rerendering a frame a second time gives exactly the same polygons dropped as in the original render. That's good, makes the problem slightly easier to debug. Thanks, Steve Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] New DRIconf release 0.2.6
Hi all, I just uploaded a new DRIconf release 0.2.6. See http://dri.freedesktop.org/wiki/DriConf. Important changes in this release: * A Spanish translation by David Rubio Miguélez * Some fixes that make maintaining and testing translations easier * If pygtk-2.6 is available, the AbougDialog widget is used instead of a plain message dialog. DRIconf is approaching version 1.0.0, meaning that it is getting close to what I want it to be. The only missing feature that I'd like to add is drag-n-drop in the configuration tree, though I'm not sure yet when I'm going to take the time to work this out. Another important feature that needs attention is internationalization (I18N). So far Spanish and German translations of the DRIconf GUI are available. The latest 3D drivers also have translated option descriptions in Spanish, Dutch (thanks to Manfred Stienstra) and of course German. So I18N of the DRI configuration infrastructure is making nice progress. If you'd like to add a translation to your native language, take a look at the Makefile included in the DRIconf tarball and at http://dri.freedesktop.org/wiki/ConfigurationForDevelopers, section How to translate option descriptions. I'd be happy to add your translations to Mesa CVS (for option descriptions) and/or DRIconf (the GUI). Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Help wanted: Translations for driver option descriptions
Hi DRI developers and users, As you may or may not know, it is possible to translate the option descriptions that you see in DRIconf. I just changed the way these translations are managed in Mesa to use GNU gettext, the standard tool for I18N. If you're interested in translating existing driver options to your language, please take a look at http://dri.freedesktop.org/wiki/ConfigurationForDevelopers section How to translate option descriptions and/or the start of mesa/src/mesa/drivers/dri/common/xmlpool/Makefile. I'd be happy to add your .po-files to Mesa CVS such that everybody can enjoy your translations. BTW, the user interface of DRIconf supports I18N via GNU gettext as well as of version 0.2.5. ;-) Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Improving translatability of driver options
Am Freitag, den 08.04.2005, 08:39 -0600 schrieb Brian Paul: This is basically for I18N, right? Yes. You mention that Python and the gettext tools to run the Makefile. Will everyone need these? I.e. is there a new dependency here? Python and gettext will be needed to generate a header file that will be used by the drivers. I'm thinking to put the generated header into CVS just like other Python-generated files in Mesa. When options are added or translations updated a new version will have to be generated and committed to CVS. gettext tools will also be needed to update the message catalog and translations from the option template that contains options with English descriptions. Developers who add new options and translators who add a new language will need to do this. People who just want to build Mesa/DRI don't need any additional software. My only concern is if you can live with another deeper subdirectory in Mesa or if you'd like it somewhere else up the tree hierarchy. Either way, I'd recommend putting all the I18N stuff for option descriptions in a separate subdirectory because it will accumulate more files for new languages and because the process that generates the option header creates further temporary files and even subdirectories for each language. I'd like to keep these out of the way. Regards, Felix -Brian Felix Kühling wrote: I haven't got any feedback on this yet. I have made a few improvements and as far as I'm concerned it's ready for CVS. If no one objects I'll commit this over the weekend. I'll also update the documentation in the Wiki about adding new options and translations. Regards, Felix Am Dienstag, den 29.03.2005, 02:19 +0200 schrieb Felix Kühling: Hi, [ For the proposal outlined below I would like to create a new directory in Mesa CVS. Brian, is this ok with you? What about mesa/src/mesa/drivers/dri/common/xmlpool? Any objections or alternatives? ] I thought about how translatability of driver options could be improved. My recent experience with using gettext in DRIconf got me thinking if the same tools could be used for translating driver options. This would have two big advantages: 1. Gettext and related tools are well known to translators, even without programming experience. 2. Translations for different languages are maintained in separate files, which also makes life easier for translators. However, then a mechanism is needed to combine all the translations into a single file, because the XML schema that drivers use to advertise their options wants all translations of an option in one place. I have written a small Python script that does the job of generating something like xmlpool.h (options.h) from a template file (t_options.h) containing the English descriptions and gettext translations in separate files. I'll be offline for the rest of the week. Therefore I'm attaching a .tar.gz containing the work I have done so far for interested people to look at. It contains a new common/xmlpool.h and a directory common/xmlpool with the option template t_options.h, a German translation de.po, and everything that's needed for maintaining translations and generating options.h from t_options.h+translations. This is already working for me. To try this live, extract the tarball in mesa/src/mesa/drivers/dri. Then cd into common/xmlpool and run make to generate options.h (you need Python and the gettext tools installed). Then rebuild the drivers. Take a look at the start of common/xmlpool/Makefile for details about adding new translations. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improving translatability of driver options
I haven't got any feedback on this yet. I have made a few improvements and as far as I'm concerned it's ready for CVS. If no one objects I'll commit this over the weekend. I'll also update the documentation in the Wiki about adding new options and translations. Regards, Felix Am Dienstag, den 29.03.2005, 02:19 +0200 schrieb Felix Kühling: Hi, [ For the proposal outlined below I would like to create a new directory in Mesa CVS. Brian, is this ok with you? What about mesa/src/mesa/drivers/dri/common/xmlpool? Any objections or alternatives? ] I thought about how translatability of driver options could be improved. My recent experience with using gettext in DRIconf got me thinking if the same tools could be used for translating driver options. This would have two big advantages: 1. Gettext and related tools are well known to translators, even without programming experience. 2. Translations for different languages are maintained in separate files, which also makes life easier for translators. However, then a mechanism is needed to combine all the translations into a single file, because the XML schema that drivers use to advertise their options wants all translations of an option in one place. I have written a small Python script that does the job of generating something like xmlpool.h (options.h) from a template file (t_options.h) containing the English descriptions and gettext translations in separate files. I'll be offline for the rest of the week. Therefore I'm attaching a .tar.gz containing the work I have done so far for interested people to look at. It contains a new common/xmlpool.h and a directory common/xmlpool with the option template t_options.h, a German translation de.po, and everything that's needed for maintaining translations and generating options.h from t_options.h+translations. This is already working for me. To try this live, extract the tarball in mesa/src/mesa/drivers/dri. Then cd into common/xmlpool and run make to generate options.h (you need Python and the gettext tools installed). Then rebuild the drivers. Take a look at the start of common/xmlpool/Makefile for details about adding new translations. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Improving translatability of driver options
Hi, [ For the proposal outlined below I would like to create a new directory in Mesa CVS. Brian, is this ok with you? What about mesa/src/mesa/drivers/dri/common/xmlpool? Any objections or alternatives? ] I thought about how translatability of driver options could be improved. My recent experience with using gettext in DRIconf got me thinking if the same tools could be used for translating driver options. This would have two big advantages: 1. Gettext and related tools are well known to translators, even without programming experience. 2. Translations for different languages are maintained in separate files, which also makes life easier for translators. However, then a mechanism is needed to combine all the translations into a single file, because the XML schema that drivers use to advertise their options wants all translations of an option in one place. I have written a small Python script that does the job of generating something like xmlpool.h (options.h) from a template file (t_options.h) containing the English descriptions and gettext translations in separate files. I'll be offline for the rest of the week. Therefore I'm attaching a .tar.gz containing the work I have done so far for interested people to look at. It contains a new common/xmlpool.h and a directory common/xmlpool with the option template t_options.h, a German translation de.po, and everything that's needed for maintaining translations and generating options.h from t_options.h+translations. This is already working for me. To try this live, extract the tarball in mesa/src/mesa/drivers/dri. Then cd into common/xmlpool and run make to generate options.h (you need Python and the gettext tools installed). Then rebuild the drivers. Take a look at the start of common/xmlpool/Makefile for details about adding new translations. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | xmlpool.tar.gz Description: application/compressed-tar
[Announce] DRIconf 0.2.5
Hello DRI users, I'm happy to announce a new DRIconf release 0.2.5. It is now available for download from http://dri.freedesktop.org/wiki/DriConf. Short summary of new features: * I18N (InternationlizatioN), only a German translation so far, more translations are very welcome * More attractive look with icons in the configuration tree * Full editing of unknown options and unknown drivers (though type and range checking is not possible) * Less popup messages The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Happy Easter, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.2.5
Am Sonntag, den 27.03.2005, 19:45 +0200 schrieb David: El Domingo, 27 de Marzo del 2005 4:02 PM, Felix Kühling escribió: The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Well, I think that there should be more strings marked for translation. I suppose you're referring to option descriptions? They are not part of the DRIconf user interface, they are defined in the drivers themselves. Of course you're welcome to translate them too. Take a look at mesa/src/mesa/drivers/dri/common/xmlpool.h in Mesa CVS. Now that I know gettext, I'm considering to generate xmlpool.h automatically from .po-files. That would make life easier for maintainers of translations, especially for non-programmers. BTW, do you use any special tool for editing .po files? I tried the Emacs mode for po files, but I'm not too happy with it. (Maybe I'd change my mind if I was dealing with longer .po files.) Anyway here's the .po for the Spanish translation. Thanks for this very quick reply. I'll wait for a few more translations before making a new release. I went through your translation. I know very little Spanish myself (I know how it's pronounced ;-) and have a few comments/questions: The í in aplicacíón looks like a typo: msgstr Crear un nuevo dispositivo o aplicacíón You translated anyway in two different ways. Is that intentional? Would it be better to use the same formulation in both cases? ¿Salir de todos modos? ¿Salvar de todas formas? Is Creados a typo? AFAIK plural should not change the verb: msgstr Creados nuevos archivos de configuración DRI %s por usted. The last one is more out of curiosity: You used usted when addressing the user, which is used very much in South America among strangers. AFAIK in Spain tú is more widely used, though I don't know which is the usual form in user interfaces. What is your experience? See ya. David Rubio. Hasta luego, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.2.5
Am Sonntag, den 27.03.2005, 14:25 -0600 schrieb D. Hageman: RPMS are now available as well. Cool, thanks! I do have a suggestion/issue. I notice that one of the tabs is labeled Features that are not hardware-accelerated and you can really read text on the tab unless you mouse over it. We should probably look at a different wording for that. Non-accelerated Features? Software GL extensions? Non-accelerated Extensions? This is not part of the user interface. The r200 driver defines this string. Someone would have to fix it there. The truncation of long tab labels and tooltip with the full description was added in version 0.2.4. This seemed to be the best way to handle such long labels. Once you know the text you only need the short version and you know what's meant anyway. (First I tried line-wrapping long labels, but I didn't find a way to limit the width of the labels (gtk_widget_set_size_request) without making all shorter labels the same width.) I imagine you should be able to set a tool tip that will explain it further on mouse over. It is something to think about. The section descriptions in the driver don't have a notion of a short and a long description. If a long section description is given by the driver, the user interface needs to cope with that in some way. The truncation + tooltip thing was the only solution I could come up with till now. If anyone knows a better way to do this with GTK (e.g. limiting the width of line-wrapped labels without making it the minimum width at the same time), I'm all ears. On Sun, 27 Mar 2005, Felix [ISO-8859-1] Kühling wrote: Hello DRI users, I'm happy to announce a new DRIconf release 0.2.5. It is now available for download from http://dri.freedesktop.org/wiki/DriConf. Short summary of new features: * I18N (InternationlizatioN), only a German translation so far, more translations are very welcome * More attractive look with icons in the configuration tree * Full editing of unknown options and unknown drivers (though type and range checking is not possible) * Less popup messages The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Happy Easter, Felix -- [snip] //\\ || D. Hagemandhageman@dracken.com || \\// -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.11.5(6) breaks savage drm module
Am Sonntag, den 27.03.2005, 20:52 +0100 schrieb António Alegria: I had the Savage dri module snapshot working perfectly with kernel 2.6.11.2 and after updating to 2.6.11.6, and reinstalling it, the module won't load. Checking dmesg gives error messages which refer to drm_ioctl.c. I checked the last kernel patches and 2.6.11.5 changed drivers/char/drm/drm_ioctl.c. Here is the diff taken from www.linuxhq.org: diff -Nru a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c --- a/drivers/char/drm/drm_ioctl.c 2005-03-18 22:35:10 -08:00 +++ b/drivers/char/drm/drm_ioctl.c 2005-03-18 22:35:10 -08:00 @@ -326,6 +326,8 @@ DRM_COPY_FROM_USER_IOCTL(sv, argp, sizeof(sv)); + memset(version, 0, sizeof(version)); + dev-driver-version(version); retv.drm_di_major = DRM_IF_MAJOR; retv.drm_di_minor = DRM_IF_MINOR; This should not matter because you should not use the in-kernel DRM together with a snapshot. You must disable all DRM options in your kernel configuration (and recompile/install the kernel). If this doesn't solve your problems, please post the error messages from dmesg. I tried using the snapshots from 2005-03-14 and 2005-02-22. They worked with 2.6.11.2. Hope you can solve this. Thanks! Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.2.5
Am Sonntag, den 27.03.2005, 22:22 +0200 schrieb David: El Domingo, 27 de Marzo del 2005 9:16 PM, Felix Kühling escribió: Am Sonntag, den 27.03.2005, 19:45 +0200 schrieb David: El Domingo, 27 de Marzo del 2005 4:02 PM, Felix Kühling escribió: The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Well, I think that there should be more strings marked for translation. I suppose you're referring to option descriptions? They are not part of the DRIconf user interface, they are defined in the drivers themselves. Of course you're welcome to translate them too. Take a look at mesa/src/mesa/drivers/dri/common/xmlpool.h in Mesa CVS. I'll take a look. Now that I know gettext, I'm considering to generate xmlpool.h automatically from .po-files. That would make life easier for maintainers of translations, especially for non-programmers. A brief note on this: I searched google for pygettext and I read somewhere that it has been deprecated for xgettext, now supporting python. I installed python-demo from a suse package, but make po failed saying that pygettext could not be found, so I copied pygettext.py to the driconf directory and edited the Makefile so that python pygettext.py were called instead of only pygettext. Ok, I changed the Makefile to use xgettext and also fixed a bug about creating lang/LC_MESSAGES directories. It's attached and will be in the next release. BTW, do you use any special tool for editing .po files? I tried the Emacs mode for po files, but I'm not too happy with it. (Maybe I'd change my mind if I was dealing with longer .po files.) I use a plain text editor: Kate. I could have used also KBabel or another specific tool, but IMHO they are very complicated for the normal user. Anyway here's the .po for the Spanish translation. Thanks for this very quick reply. I'll wait for a few more translations before making a new release. I went through your translation. I know very little Spanish myself (I know how it's pronounced ;-) and have a few comments/questions: The í in aplicacíón looks like a typo: msgstr Crear un nuevo dispositivo o aplicacíón Yes, It's a typo. It should be aplicación. Fixed in my local CVS. You translated anyway in two different ways. Is that intentional? Would it be better to use the same formulation in both cases? ¿Salir de todos modos? ¿Salvar de todas formas? Both forms are correct. And you are right. Choose one. I chose the (slightly) shorter one. ;-) Is Creados a typo? AFAIK plural should not change the verb: msgstr Creados nuevos archivos de configuración DRI %s por usted. Yes, but here the phrase is a short form for: Han sido creados nuevos archivos de configuración por usted. All right, so it's not a verb but a participle. My fault. It would be more natural with a passive form: Se han creado nuevos archivos de configuración de DRI por usted. or Se han creado por usted nuevos archivos de configuración de DRI. I'll leave this alone for now as I can't tell what's better. I won't argue with any changes you make in a later revision of es.po, you're the native speaker. The last one is more out of curiosity: You used usted when addressing the user, which is used very much in South America among strangers. AFAIK in Spain tú is more widely used, though I don't know which is the usual form in user interfaces. What is your experience? Usted is the polite form. Kids use it to talk to adults, and people use it when talking to somebody who had never meet before, etc. In South America it is used way more often. However, it is the form that user interfaces use. KDE uses it all the time. Ok. Thanks for the insight. :) Anyway it was a _fast_ translation. ;-) See ya. David Rubio. Hasta luego, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | # Convenient makefile for managing translations. # Prerequisites: # - pygettext from the python distribution # - GNU gettext # How to use this: # To start working on a new translation edit the POS=... line # below. If you want to add for example a french translation, add # fr.po. # Then run make po to generate fresh .po files from translatable # strings in driconf.py. Now you can edit the new .po file (fr.po in # the example above) to translate the strings. Please make sure that # your editor encodes the file in UTF-8. # Finally run make mo to generate a new binary file for gettext. It # will be stored in lang/LC_MESSAGES/driconf.mo. You can test the # new translation by running ./driconf in the current directory # without reinstalling DRIconf all the time. Of course you need
Re: [Savage40] Re: Savage dri does not resume from disk
Hi Dario, With the help of Sergey Zharkov I narrowed down the problem. I'm CCing this to the dri-devel and savage40 lists as a summary. The problem seems to be in the AGP GART driver which is in the Linux kernel. A new snapshot won't help you, I can't fix the problem there. I haven't had the time to prepare a good bug-report for the kernel developers yet. I would have to upgrade the kernel and get swsusp to work with it first (last time I tried this was several months ago). I think I won't have time for this in the next two weeks. :( See my comment below for a good workaround. Am Montag, den 21.03.2005, 21:11 +0100 schrieb Dario Saccavino: I am experiencing the same problem with swsusp2 (version 2.1.8, kernel 2.6.11): after resuming from suspend to disk, if I launch a 3D application the computer hangs. I can avoid the problem completely by specifying DmaMode none in xorg.conf or by shutting down X before suspending. In order to make swsusp work reliably you should set BusType to PCI. This will disable any use of AGP memory, both for textures and for DMA. With BusType PCI you do not need to set DmaMode to None, but you may get slightly better performance. Your mileage may vary. I'm using a CVS snapshot dating about 2 weeks ago; is this fixed now, or going to be? I can supply logs and testing, if you need some help. Dario Regards, Felix On Wed, 16 Mar 2005 14:47:01 +0300, Sergey Zharkov [EMAIL PROTECTED] wrote: Felix, I've tried some coding to make savage resume looking at radeon resume code but failed completely :(( Unfortunately I'am ABAP/4 developer - not a C guru. The only thing that may help real dri developers to suggest how to resume - when I switched DMA mode from command or vertex to None i've lost about 5 % of speed but the dri system was able to resume from disk if no glx apps were running. And even with glx apps running it was resuming, but the glx apps were resuming with black window. Anyway after resume I was able to start glx apps and they worked, with dma enebled I had to pull a power cord and battery out to restart. And the bug is not in the kernel I guess - restarting X after resume with enabled dma works fine. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] DRIconf 0.2.4
Hello all, I made another release of DRIconf (0.2.4), fixing a rather nasty bug in 0.2.3 with some older versions of pygtk-2. I used this opportunity to polish the user interface a little. Especially new users should find it easier to get started with this one. See the CHANGELOG for details or just try it and see for yourself. Cheers, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Donnerstag, den 17.03.2005, 08:17 +0300 schrieb Sergey Zharkov: Felix, It works great!!! Thanks for the patch - now my suspend-resume works like piece of cake - without DMA modes yet Didn't you say it worked with PCI DMA? With BusType PCI and DmaMode != None it is using DMA. Though PCI DMA is slower than AGP DMA, in some cases even slower than no DMA at all. :-/ but even without dma the performance is much better than on savage DRI 1.0. If there will be any changes in agp - i am ready to test. The patch from yesterdays mm4 version did not help. Hmm, ok. I'll commit my patch to Xorg CVS and see if I can get the via-agp issue resolved with the kernel people. Regards, Felix On Thu, 2005-03-17 at 00:26 +0100, Felix Kühling wrote: Am Mittwoch, den 16.03.2005, 16:26 +0100 schrieb Felix Kühling: Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov: [snip] What I'am afraid of is that savage_dri or savage_drv drivers writhe something into the chip hardware that is not loaded there by kernel modules start - so if i do resume from ram the chip registers keep those values and resume even if glx app was running in time of suspend. But if i resume from disk kernel modules are loaded back with initial values - but some commands or chip register values that were initialised by xorg or dri drivers need to be restored on enterVT function. The same way as radeon do. As far as I can tell, the Savage hardware state is almost completely restored in enterVT. EnterVT doesn't care about 3D state though, that's why 3D windows that were running during suspend are black after resume. I think it would be easy to get it working with a running 3D application during suspension. The Xserver would have to invalidate the 3D hardware state in the sarea, so that the 3D driver restores it after resume. I'll send you a patch later tonight for testing this. Please try the attached patch (apply in xc/programs/Xserver/hw/xfree86/drivers/savage). Test with BusType PCI, with a 3D app running while suspending. On resume it should now display correctly. If it works, I will commit this to Xorg CVS. [snip] Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Mittwoch, den 16.03.2005, 14:47 +0300 schrieb Sergey Zharkov: Felix, I've tried some coding to make savage resume looking at radeon resume code but failed completely :(( Unfortunately I'am ABAP/4 developer - not a C guru. The only thing that may help real dri developers to suggest how to resume - when I switched DMA mode from command or vertex to None i've lost about 5 % of speed but the dri system was able to resume from disk if no glx apps were running. And even with glx apps running it was resuming, but the glx apps were resuming with black window. Anyway after resume I was able to start glx apps and they worked, with dma enebled I had to pull a power cord and battery out to restart. And the bug is not in the kernel I guess - restarting X after resume with enabled dma works fine. Could you try if Option BusType PCI makes any difference with DMA enabled? Try it with a DRI app running while suspending and without. This is to confirm if the problem is in the Savage DRM or in the AGP driver (or both :( ). Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Mittwoch, den 16.03.2005, 15:17 +0300 schrieb Sergey Zharkov: Setting BusType to PCI and even BusType AGP with DmaType PCI helps - the thing resumes. So it seems to be a bug in AGP dma resuming. But not in kernel one - there is a resume code in via-agp driver, that worked for DRI 1.0 You mean the old Savage DRM driver 1.0? That one didn't use DMA, which is about the same as setting DmaMode to None now. Another thing you can try is running textured applications with only AGP textures (with BusType AGP and DmaType PCI). Run the application like this: texture_heaps=2 textured DRI application This will disable the local memory texture heap and use only the AGP heap. If our theory is correct, it should lock up after resume. Regards, Felix On Wed, 2005-03-16 at 13:01 +0100, Felix Kühling wrote: Am Mittwoch, den 16.03.2005, 14:47 +0300 schrieb Sergey Zharkov: Felix, I've tried some coding to make savage resume looking at radeon resume code but failed completely :(( Unfortunately I'am ABAP/4 developer - not a C guru. The only thing that may help real dri developers to suggest how to resume - when I switched DMA mode from command or vertex to None i've lost about 5 % of speed but the dri system was able to resume from disk if no glx apps were running. And even with glx apps running it was resuming, but the glx apps were resuming with black window. Anyway after resume I was able to start glx apps and they worked, with dma enebled I had to pull a power cord and battery out to restart. And the bug is not in the kernel I guess - restarting X after resume with enabled dma works fine. Could you try if Option BusType PCI makes any difference with DMA enabled? Try it with a DRI app running while suspending and without. This is to confirm if the problem is in the Savage DRM or in the AGP driver (or both :( ). Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov: Felix, Unfortunately I never posted a bug for kernel and have no idea how to do that. I found a related bug: http://bugzilla.kernel.org/show_bug.cgi?id=3864. Though that user was not getting lockups, just some distortions. Probably with different graphics hardware (no details in the report). You can register at bugzilla.kernel.org (click on New Account near the bottom of the page) and make an additional comment. I have tryed all kernel versions starting from 2.6.11 - mm1,2,3 , ac series, nitro patches, builtin swsuspend as well as swsuspend2 2.1.8 That's good. - 2.1.8.2 . Hardware is Twinhead Efio 121A laptop Via KN266 chipset, Athlon XP-M 1700+. lspci output would be nice too (for them). The only thing - I am not shure that the via-agp driver is causing this bug - if I restart X after resuming I get DRM working again, so agp module is there. When X is started it allocates AGP memory, when it quits, the memory is freed again. Between suspend and resume via-agp it has to remember that state and restore the AGP hardware properly on resume. That doesn't seem to work correctly. Restarting X is a reinitialization of the relevant AGP hardware state and restores AGP to working order. (That's my understanding anyway) Actually swsusp2 is auloading all modules on suspend and loading them back - so I have agp functionality restarted properly. When you suspend with DRI enabled, the AGP module is used, so swsusp can't unload it. If it forces unloading, you're in trouble, but I don't think it would do that. What I'am afraid of is that savage_dri or savage_drv drivers writhe something into the chip hardware that is not loaded there by kernel modules start - so if i do resume from ram the chip registers keep those values and resume even if glx app was running in time of suspend. But if i resume from disk kernel modules are loaded back with initial values - but some commands or chip register values that were initialised by xorg or dri drivers need to be restored on enterVT function. The same way as radeon do. As far as I can tell, the Savage hardware state is almost completely restored in enterVT. EnterVT doesn't care about 3D state though, that's why 3D windows that were running during suspend are black after resume. I think it would be easy to get it working with a running 3D application during suspension. The Xserver would have to invalidate the 3D hardware state in the sarea, so that the 3D driver restores it after resume. I'll send you a patch later tonight for testing this. The only thing I could not find is what is actually written to chip - probably it could be easeir for the guys who really create the driver. If you can suggest some places in code (function names etc ) which do modify hardware registers I could try to play with them. Actually what radeon does (if I got it correct ) - is reinitialising DMA each enterVT function, but I could not find function that just reinitialise DMA in savage code. KernelInit or AGPInit in EnterVT restarted the whole X server instead or restoring DMA state. DMA itself seems to be working fine, because it worked with PCI DMA. I'm pretty sure it's AGP that's broken after resume. On Wed, 2005-03-16 at 15:24 +0100, Felix Kühling wrote: Am Mittwoch, den 16.03.2005, 15:36 +0300 schrieb Sergey Zharkov: You right - just running texture_heaps=2 lament killed my system immediately. Ok, that makes it very likely that the via-agp driver is at fault. We should report a bug in the Linux bugzilla. First we should test if the latest kernel version is affected too. Which kernel version have you been using? Since you have done all the testing and I am otherwise busy ATM it would be very helpful if you could take care or reporting the bug in the kernel bugzilla. I suppose you know that you have to provide accurate information about your hardware, what tests you performed and the results ... Send the bug id to dri-devel, so interested DRI experts (me for one ;-) can help resolve this. Thanks, Felix On Wed, 2005-03-16 at 13:30 +0100, Felix Kühling wrote: Am Mittwoch, den 16.03.2005, 15:17 +0300 schrieb Sergey Zharkov: Setting BusType to PCI and even BusType AGP with DmaType PCI helps - the thing resumes. So it seems to be a bug in AGP dma resuming. But not in kernel one - there is a resume code in via-agp driver, that worked for DRI 1.0 You mean the old Savage DRM driver 1.0? That one didn't use DMA, which is about the same as setting DmaMode to None now. Another thing you can try is running textured applications with only AGP textures (with BusType AGP and DmaType PCI). Run the application like this: texture_heaps=2 textured DRI application This will disable the local memory texture heap and use only the AGP heap. If our theory is correct
Re: Savage dri does not resume from disk
Am Mittwoch, den 16.03.2005, 16:26 +0100 schrieb Felix Kühling:
Am Mittwoch, den 16.03.2005, 17:35 +0300 schrieb Sergey Zharkov:
[snip]
What I'am afraid of is that savage_dri or savage_drv drivers writhe
something into the chip hardware that is not loaded there by kernel
modules start - so if i do resume from ram the chip registers keep those
values and resume even if glx app was running in time of suspend. But if
i resume from disk kernel modules are loaded back with initial values -
but some commands or chip register values that were initialised by xorg
or dri drivers need to be restored on enterVT function. The same way as
radeon do.
As far as I can tell, the Savage hardware state is almost completely
restored in enterVT. EnterVT doesn't care about 3D state though, that's
why 3D windows that were running during suspend are black after resume.
I think it would be easy to get it working with a running 3D application
during suspension. The Xserver would have to invalidate the 3D hardware
state in the sarea, so that the 3D driver restores it after resume. I'll
send you a patch later tonight for testing this.
Please try the attached patch (apply in
xc/programs/Xserver/hw/xfree86/drivers/savage). Test with BusType PCI,
with a 3D app running while suspending. On resume it should now display
correctly. If it works, I will commit this to Xorg CVS.
[snip]
Thanks,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./savage_driver.c.~1.31.~ 2005-03-03 17:33:26.0 +0100
+++ ./savage_driver.c 2005-03-17 00:16:33.933174152 +0100
@@ -31,6 +31,7 @@
#ifdef XF86DRI
#define _XF86DRI_SERVER_
#include savage_dri.h
+#include savage_sarea.h
#endif
@@ -2025,6 +2026,7 @@
#ifdef XF86DRI
SavagePtr psav= SAVPTR(pScrn);
ScreenPtr pScreen;
+SAVAGESAREAPrivPtr pSAREAPriv;
#endif
TRACE((SavageEnterVT(%d)\n, flags));
@@ -2035,6 +2037,10 @@
#ifdef XF86DRI
if (psav-directRenderingEnabled) {
pScreen = screenInfo.screens[scrnIndex];
+ pSAREAPriv = (SAVAGESAREAPrivPtr)DRIGetSAREAPrivate(pScreen);
+ /* Assume that 3D state was clobbered, invalidate it by
+ * changing ctxOwner in the sarea. */
+ pSAREAPriv-ctxOwner = DRIGetContext(pScreen);
DRIUnlock(pScreen);
psav-LockHeld = 0;
}
Re: [Announce] New DRIconf version 0.2.3
Am Dienstag, den 15.03.2005, 01:41 +0100 schrieb Roland Scheidegger: Felix Kühling wrote: Hi all, I just uploaded a new DRIconf version (0.2.3), which features better support for floating-point ranges like the brilinear option proposed by Roland Scheidegger. There are also a few bug fixes and usability improvements as well as updates and additions to the README file. The new slider widget for the float range works very nice. I do get some crash when exiting the app: TypeError: main_quit() takes no arguments (1 given) But it's not bothering me too much :-). Err, this happens when you close the window using the window manager. I never tried that, so I missed this problem. If you close using the Exit button in the toolbar, it works just fine. Looks like I'll be making a new release soon. :-/ This version is for gtk2. I'm not too keen on keeping the gtk1.2 branch up-to-date. Does anyone still use it? Not currently, I used to use it on SuSE 8.1 though (even the gtk1.2 version was a major pain to install, and I couldn't get the gtk 2 version to work ever, I tried to install some libraries but never succeeded). Not sure if there are many people around which would use bleeding edge drivers on such old distros. True. Thanks for the feedback, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] New DRIconf version 0.2.3
Am Dienstag, den 15.03.2005, 10:36 -0600 schrieb D. Hageman: I have made a RPM, SRPM and SPEC file of driconf available. The RPM was made under Fedora Core 3. The link is in the Download section on this page: http://dri.freedesktop.org/wiki/DriConf Could you also add a note near the top of the page, under Installation Instructions? This way people who can use your RPMs can skip the part about manual installation. I will do my best to track releases to keep them updated, but if you can't wait it should be easy to modify the SPEC file to make it work for you. //\\ || D. Hagemandhageman@dracken.com || \\// Thanks, Felix P.S.: Anyone interested in making a Debian package? I have no experience in making Debian packages, so I'd prefer to leave this to someone who has. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] New DRIconf version 0.2.3
Am Dienstag, den 15.03.2005, 11:37 -0600 schrieb D. Hageman: I added to the Installation instructions: Packages are available for Linux distributions utilizing RPM package management in the Download section. We currently do not have Debian packages available. If you are interested in the role of Debian package manager for this project please send an e-mail to the dri-devel mailing list. Great, thanks. I also added another note that there are still source tarballs available. We don't want to scare away people who don't use RPM. On Tue, 15 Mar 2005, Felix [ISO-8859-1] Kühling wrote: [snip] Cheers, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: [Announce] New DRIconf version 0.2.3
Am Dienstag, den 15.03.2005, 15:59 -0500 schrieb Michel Dänzer: On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote: I added to the Installation instructions: Packages are available for Linux distributions utilizing RPM package management in the Download section. We currently do not have Debian packages available. If you are interested in the role of Debian package manager for this project please send an e-mail to the dri-devel mailing list. Actually, I've had driconf 0.2.2 packages at deb http://people.debian.org/~daenzer/dri-trunk-sid/./ for over a year, but anybody is welcome to pick that up. I must have missed that. I added a note to .../wiki/DriConf. Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: radeon, apertures memory mapping
[slightly off topic] Am Sonntag, den 13.03.2005, 12:56 -0500 schrieb Jon Smirl: On Sun, 13 Mar 2005 19:47:14 +0200, Ville Syrjälä [EMAIL PROTECTED] wrote: I don't understand why we have GART memory anyway. It's just main memory and I don't see any point going through the GART to access it with the CPU. Only the graphics card needs to use the GART. I see no need to for the CPU to go through the GART either. The main CPU page tables can provide the same rearranging that the GART does. We do need specially marked GART memory because of caching issues. If the CPU writes to GART RAM the write may still be on the CPU chip in a cache. We have to make sure it gets pushed into physical memory so that the GPU can see it. If this is true, then I'm surprised that PCI-DMA with normal cacheable memory works. All practical experience with the Savage driver teaches me that a memory barrier is sufficient. Or does a memory barrier really flush all CPU caches? [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] New DRIconf version 0.2.3
Hi all, I just uploaded a new DRIconf version (0.2.3), which features better support for floating-point ranges like the brilinear option proposed by Roland Scheidegger. There are also a few bug fixes and usability improvements as well as updates and additions to the README file. This version is for gtk2. I'm not too keen on keeping the gtk1.2 branch up-to-date. Does anyone still use it? Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Mittwoch, den 09.03.2005, 02:08 +0300 schrieb Sergey Zharkov: Felix, Sorry for reporting bug on this address - just culd not find any place t report for DRI, and you seems to be the only man who actually program the driver. The DRI developers list is [EMAIL PROTECTED] Savage issues can also be discussed at [EMAIL PROTECTED], which is a moderated list. I've recently moved from Savage DRM 1.x to 2.x from cvs with kernel 2.6.11 - I've received 10% increase in speed, quality of rendering looks better as well (i got rid of some ugly artifacts on my favorite SeriousSam game) - the only thing DRI does not resume from disk anymore. It resumes from memory (acpi state S3) fine, but when I resume from disk even having no apps using DRI during suspend-resume, each time I try to start 3D application everything hangs and the only chance I have is to switch power off. Just curious are you aware about this - may be you have any idea how to make resume from disk working again, Not really. Resume from disk was only half working for me with DRM 1.x. It locked up after some time with more demanding applications. I was guessing that it locked up whenever the driver started using AGP textures, but I never looked into it more seriously. With the new driver I have never tried resume from disk, and I don't know what would be needed to make it work. I'm CCing to dri-devel. Can someone give me a brief summary what a driver needs to support resume from disk? I seem to remember that i915 and unichrome saw changes in that area in the last months. The hardware is Twinhead Efio 121A, KN266 based laptop Thank you Sergey -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Savage Command DMA
Hi Savage Users, Last night I committed support for command DMA for Savage4-based chips to DRM, Xorg and Mesa CVS. Unfortunately the upgrade may not be completely smooth, because the DRM and DDX changes exposed some bugs in the Mesa driver that have been fixed now. So if you upgrade, you need to upgrade all three components to get command DMA and to avoid strange failures of the 3D driver. On the bright side, this improves performance slightly and will hopefully bring a big performance boost to SuperSavages. These chips used to lock up in vertex DMA mode. I hope that command DMA works better with them. If it doesn't please let me know, then I'll have to disable command DMA too, on these chips. There is a new option for xorg.conf now: (from the manual page) Option DmaMode string This option influences in which way DMA (direct memory access) is used by the kernel and 3D drivers. Any -- Try command DMA first, then vertex DMA (default) Command -- Only use command DMA or dont use DMA at all Vertex -- Only use vertex DMA or dont use DMA at all None -- Disable DMA Command and vertex DMA cannot be enabled at the same time. Which DMA mode is actually used in the end also depends on the DRM version (only = 2.4.0 supports command DMA) and the hardware (Savage3D/MX/IX doesnt support command DMA). If you have trouble (lockups) with command DMA, please let me know (include information about your hardware, lspci output at least). As a workaround try setting DmaMode to Vertex, which should result in the old behavior. Best regards, Felix P.S.: Binary snapshot users will have to be patient. Hardware problems on the build machine prevent the builds at the moment. -- | Felix Khling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ports/76257: nvidia_driver breaks xorg-clients build
Am Dienstag, den 22.02.2005, 08:15 -0800 schrieb Eric Anholt: On Tue, 2005-02-22 at 00:08 -0500, Mikhail Teterin wrote: Could you try if the attached patch against xdriinfo.c works with NVidia's GLX? If it does, then I'll commit this to Xorg CVS. Using glXGetProcAddressARB instead of glXGetProcAddress allows the utility to build, but it still does not work -- the calls return NULL at run-time. If your program only works with Xorg's GLX, than, indeed, the error message may need to become more informative. If, on the other hand, using the glXGetProcAddressARB works when linked with Xorg's GLX -- why bother with the #ifdefs at all? Just use the old call for the time being. :-) As mentioned earlier in the PR, changing to glXGetProcAddressARB results in xdriinfo segfaulting, at least for me on amd64. Eric, could you find out where it's segfaulting? -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon unified driver
Am Samstag, den 19.02.2005, 01:11 +0100 schrieb Nicolai Haehnle: Hi, On Saturday 19 February 2005 00:46, Roland Scheidegger wrote: There is some problem with driconf, it seems to have some problems because the driver's name (radeon) does not match what it expects (r200). Likewise, I couldn't figure out how you'd have 2 separate config sections for both r100 and r200, currently you'll get all options of the r200 (though it won't work for that chip family...), some options just won't do anything on r100. When I started working on the R300 driver, I did some similar work so that the R300 driver should in theory be able to handle R200 as well (this R200 support has certainly gone to hell by now because of all the hacking that has been going on). The point is, I also faced the driconf issue, and you can see how I attempted to tackle it at http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/r300/radeon_screen.c?rev=1.7view=auto My solution is probably not that good, but it might give you some ideas. This is not going to work with the GUI configuration tool. It looks for a symbol called __driConfigOptions in the driver module, so with your change driconf would claim that the driver doesn't support configuration. It can't call the driver to probe on which hardware it's running, so you can't use different sets of options for different hardware supported by the same driver. I have the same problem in the savage driver. Some options just don't make sense on Savage3D-based hardware, so they have no effect in this case (for example floating-point depth buffer). So, when I read the configuration I have code like this in the driver: imesa-float_depth = driQueryOptionb(imesa-optionCache, float_depth) savageScreen-chipset = S3_SAVAGE4; Additionally you could put hardware-specific options into separate sections, so that the user can tell, which options will have an effect on her hardware. cu, Nicolai Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Texture heap aging with multiple clients
Hi,
I just read how the i8x0 drivers use the timestamp of texture objects
and heaps to avoid idling the engine for each texture upload. I think
I'm going to do the same in the Savage driver.
However, I believe this doesn't handle the case of multiple clients.
Whenever another client modified a texture heap the heap's timestamp
should be updated when taking the lock. This could be done in the
driver's getLock method. Example pseudo-patch for i810GetLock:
/* Shared texture managment - if another client has played with
* texture space, figure out which if any of our textures have been
* ejected, and update our global LRU.
*/
for ( i = 0 ; i imesa-nr_heaps ; i++ ) {
+ /* Update the heap's timestamp. Do this before DRI_AGE_TEXTURES updates
local_age. */
+ if ( imesa-texture_heaps[ i ]
+ imesa-texture_heaps[ i ]-global_age[ 0 ] imesa-texture_heaps[ i
]-local_age )
+imesa-texture_heaps[ i ]-timestamp = /* get a current time stamp */;
DRI_AGE_TEXTURES( imesa-texture_heaps[ i ] );
}
Does this look about right, or did I misunderstand something?
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
Am Mittwoch, den 16.02.2005, 00:14 -0500 schrieb Alex Deucher: On Wed, 16 Feb 2005 05:51:25 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sunday 13 February 2005 16:30, Felix K=FChling wrote: I took another look at your lspci-output. It's a PCI card, right? I saw vertex corruption with PCI-DMA on my Savage4 once. Maybe this isn't working reliably. Does it help to set enable_vdma to false (in driconf or the environment)? Performance will be worse though. The chip is connected to a PCI bus on the notebooks main board. Haven't tried enable_vdma as solution to problem is below. Have you overclocked your front-side bus? In that case, does it help if you don't overclock? No overclocking by me, All I do is underclock the LCD clock=20 to 40MHz in the hope of less heat under the keyboard :-) Did you override the VideoRam size in xorg.conf? Maybe you made it believe that it has more memory than is actually available. Yes, that was it, memory size was set to 16384, it =20 apparently got only 8192 according to Xorg log. Dunno why the machine is advertised with 16M and used this setting wo DRI for 3 years. the DDX never used more than a couple megs probably. Now it does work with tuxkart and tuxracer. fgfs will not load anymore, perhaps not enough video memory? Maybe fgfs needs a certain minimum texture size that is not available with 8MB memory. You could try to reduce the resolution in order to make more texture memory available. This may also improve performance with other applications due to reduced texture swapping. Is there a savage IX chip with 16M? There were some, but I don't think they ever left S3's testing labs. No commercial vendors that I know of used them. FWIW, 16MB is the theoretical limit you can get with this chip because of the layout of the PCI address mapping. Alex -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] .drirc?!
Am Montag, den 14.02.2005, 07:45 -0800 schrieb Ian Romanick: Jaxon Lee wrote: The opensource 3D drivers seem upset that they can't find .drirc. libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/akshunj/.drirc: No such file or directory. Where do I get it? What's supposed to be in it? Anybody know? The .drirc file is just a config file that allows you to tweak certain device-specific options on a global or per-application basis. You don't need it, so it's a bit of an over-statement for libGL to call this an error. The configuration parser uses __driUtilMessage to print this message. Don't know why this ends up being printed as an error message. Sometimes this seems to be the last message from the driver before it bails out for some other reason, so people incorrectly blame it on the missing configuration file. Should I rephrase the message to clearly state that this is *not an error* or just not print anything if the file can't be read? In fact, I'm not even sure that the Unichrome driver supports any configurable options. Hm... You wouldn't see this message if the driver didn't support configuration. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
Am Sonntag, den 13.02.2005, 11:03 +0100 schrieb [EMAIL PROTECTED]: On Saturday 12 February 2005 16:33, Felix K=FChling wrote: Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb=20 [EMAIL PROTECTED]: On Monday 07 February 2005 15:33, Felix K=3DFChling wrote: Am Montag, den 07.02.2005, 15:12 +0100 schrieb=3D20 [EMAIL PROTECTED]: [snip] Tested with 2.6.11-rc3. DRM functional with glxgears. tuxkart and tuxracer work most the time but sometimes=3D20 painting occurs outside of games window. Parts of the image=3D20 appear (sometime mirrored) outside game window or random=3D20 patterns appear. I can't reproduce this on my Savage/IX. Someone else reported problems with 2.6.11-rc3, something like it wouldn't even load the DRM modules. Maybe something's broken with current DRM on Linux 2.6.11-rc3. If this problem persists with the latest snapshot (tomorrow's should have my latest fixes) could you try if it works with a stock 2.6.10 kernel (you'd have to recompile the DRM for it)? OK, I will try with 2.6.10. Cursor and numeric display in game window=3D20 appear as random patterns. I just fixed another bug in texture tiling on Savage/IX. Though it only affected the road-texture in Tuxkart for me. Most textures were looking correctly. If you still get broken textures with tomorrow's snapshot then it might be a difference between our chip revisions (sigh). Sometimes above games mess up the screen but restart Game a=3D20 few times fixes it. Can't reproduce this either. I took another look at your lspci-output. It's a PCI card, right? I saw vertex corruption with PCI-DMA on my Savage4 once. Maybe this isn't working reliably. Does it help to set enable_vdma to false (in driconf or the environment)? Performance will be worse though. Have you overclocked your front-side bus? In that case, does it help if you don't overclock? Every time starting tuxkart or tuxracer different textures get messed up. For example, in tuxracer sometime trees and=20 herrings show as randomly colored rectangles/shapes only,=20 and herring counter and speed indicator OK; restart and=20 tress and herrings OK but indicators show (some) digits as=20 rectangles. Ground in tuxracer seems to go partially wrong as well,=20 seems that some textures do not belong there Seems to go wrong already during initialization as behavior afterward seems consistent. By what I see about wrong texture patterns, just wondering,=20 could pointers to some texture buffers be invalid and it=20 then paints with crap data? Did you override the VideoRam size in xorg.conf? Maybe you made it believe that it has more memory than is actually available. =3D46lighgear messes up the entire screen and would never work. BTW, the games work on i810 HW with 2.6.11-rc3. Since Linux 2.4 is no longer=3D20 open for new features there is not much point back-porting it to Linux 2.4.=3D20 See=3D20 http://dri.freedesktop.org/wiki/S3Savage for more information about the savage driver status. I just added a note about Linux 2.4 to that page. Sorry, have not found any reference to 2.4 being unsupported=3D20 on that page.=3D20 Are there any test programs available to systematically test=3D20 DRM/GL functionality? Regards Michael -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Fwd: Snapshot build failed]
Weitergeleitete Nachricht Von: Felix Kuehling [EMAIL PROTECTED] An: [EMAIL PROTECTED] Betreff: Snapshot build failed Datum: Sun, 13 Feb 2005 07:41:54 -0800 (PST) A snapshot build failed at Sun Feb 13 07:41:54 PST 2005. Please inspect the logfiles in /home/fxkuehl/snapshots/log. Summary: Updating sources from CVS ... done. HEAD: Preparing the builds ... done. HEAD: Building ... failed. Errors occured. Skipping archive. [snip] Tail of logfile log/HEAD-mesa.build: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I/home/fxkuehl/snapshots/cvs/drm/HEAD/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../dri_client -I../dri_client/imports -Wall -Os -gstabs+ -pipe -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 r200_lock.c -o r200_lock.o gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I/home/fxkuehl/snapshots/cvs/drm/HEAD/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../dri_client -I../dri_client/imports -Wall -Os -gstabs+ -pipe -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 r200_screen.c -o r200_screen.o r200_screen.c: In function `r200CreateScreen': r200_screen.c:407: error: `addr' undeclared (first use in this function) r200_screen.c:407: error: (Each undeclared identifier is reported only once r200_screen.c:407: error: for each function it appears in.) make[6]: *** [r200_screen.o] Error 1 make[6]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa/drivers/dri/r200' make[5]: *** [subdirs] Error 1 make[5]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa/drivers/dri' make[4]: *** [drivers-dri] Error 2 make[4]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa' make[3]: *** [default] Error 2 make[3]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa' make: *** [linux-dri-x86] Error 2 make: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/mesa' = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Snapshot build failed]
Am Sonntag, den 13.02.2005, 13:39 -0500 schrieb Michel Dänzer: On Sun, 2005-02-13 at 18:38 +0100, Felix Kühling wrote: r200_screen.c: In function `r200CreateScreen': r200_screen.c:407: error: `addr' undeclared (first use in this function) Whoops, my bad, should be fixed now. I wonder how that built for me... Thanks. BTW, I changed cron job to send automatic failure mails directly to dri-devel now. They are sent only once every day and only when a snapshot fails. Complete build log files will be uploaded to http://dri.freedesktop.org/snapshots/log. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb [EMAIL PROTECTED]: On Monday 07 February 2005 15:33, Felix K=FChling wrote: Am Montag, den 07.02.2005, 15:12 +0100 schrieb=20 [EMAIL PROTECTED]: Hardware: Toshiba Libretto L2 Tm5600 with: :00:04.0 VGA compatible controller: S3 Inc. 86C270-294=3D20 Savage/IX-MV (rev 13) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=3D Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3D3Dmedium TAbort- =3D TAbort- MAbort- SERR- PERR- Latency: 248 (1000ns min, 63750ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=3D3D128=3D M] Expansion ROM at 000c [disabled] [size=3D3D64K] Capabilities: available only to root Software: Gentoo current with Gentoo supplied X Window System Version 6.8.1.903 (6.8.=3D 2 RC 3) Release Date: 25 January 2005 X Protocol Version 11, Revision 0, Release 6.8.1.903 Build Operating System: Linux 2.4.29-rc3-mhf239 i686 [ELF]=3D20 Current Operating System: Linux mhfl4 2.4.29-rc3-mhf239 #2 Tue Jan 18 17:43=3D :33 CET 2005 i686 Build Date: 05 February 2005 Installed snapshot from savage-20050205-linux.i386.tar.bz2. On starting X: [snip] So, driver in snapshot still reports 1.0. Seems to be quite old (2001). The new Savage DRM 2.0.0 (in fact 2.2.0 by now) is only available for Linux 2.6.=20 Tested with 2.6.11-rc3. DRM functional with glxgears. tuxkart and tuxracer work most the time but sometimes=20 painting occurs outside of games window. Parts of the image=20 appear (sometime mirrored) outside game window or random=20 patterns appear. I can't reproduce this on my Savage/IX. Someone else reported problems with 2.6.11-rc3, something like it wouldn't even load the DRM modules. Maybe something's broken with current DRM on Linux 2.6.11-rc3. If this problem persists with the latest snapshot (tomorrow's should have my latest fixes) could you try if it works with a stock 2.6.10 kernel (you'd have to recompile the DRM for it)? Cursor and numeric display in game window=20 appear as random patterns. I just fixed another bug in texture tiling on Savage/IX. Though it only affected the road-texture in Tuxkart for me. Most textures were looking correctly. If you still get broken textures with tomorrow's snapshot then it might be a difference between our chip revisions (sigh). Sometimes above games mess up the screen but restart Game a=20 few times fixes it. Can't reproduce this either. =46lighgear messes up the entire screen and would never work. BTW, the games work on i810 HW with 2.6.11-rc3. Since Linux 2.4 is no longer=20 open for new features there is not much point back-porting it to Linux 2.4.=20 See=20 http://dri.freedesktop.org/wiki/S3Savage for more information about the savage driver status. I just added a note about Linux 2.4 to that page. Sorry, have not found any reference to 2.4 being unsupported=20 on that page.=20 Are there any test programs available to systematically test=20 DRM/GL functionality? Regards Michael -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: fglrx vs. r200 dri
Am Samstag, den 12.02.2005, 01:00 +0100 schrieb Roland Scheidegger: Ian Romanick wrote: Roland Scheidegger wrote: The blending seems to stay exactly the same, just the area where it's happening gets smaller. This ain't so hot, newer chips seem to do a better job there. Still, it might make sense to implement that as an user option, especially since it's so dead simple to do. Unfortunately would require a drm version bump again... A generic blending quality vs. performance slider would probably be the right way to go here. It seems like most Windows drivers have something similar. This sounds like the right thing to do. I don't think driconf offers slider-options though right now. DriConf tries to choose an appropriate widget based on the type and value range specification of an option. If you want a slider then a float option with a single interval sounds like an appropriate description for it. However, driconf doesn't implement this yet so it will fall back to a simple entry widget. It wouldn't be too hard to add a slider widget though. If you make it an integer option with a single valid interval then driconf will represent it with a spinbutton. Roland -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
