PROSAVAGE NO 3D SUPPORT?
Graphics Card: Savage (ProSavage8 KM266/KL266) Kernel: 2.6.19-2895.fc6 System: Fedora Core 6 X system: Xorg 7.0, Mesa drivers, OpenGL installed I get this warnings whe running glxgears: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering I had to add the following lines to Xorg.conf file: Section DRI Mode 0666 EndSection Section Extensions Option Composite Disable EndSection This enabled 3D support, otherwise it didn´t worked. The ¨Extensions¨ section is required to stop the screen flickering when running 3D apps. The FPS with indirect rendering is somewhere between 60 and 80 when the machine is not busy. What´s going on? Is there 3D support for my graphics card or what? The card is recognized as ProSavageDDR under WindowsXP. lspci -v output below: 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] (prog-if 00 [VGA]) Subsystem: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 5 Memory at dfe8 (32-bit, non-prefetchable) [size=512K] Memory at d000 (32-bit, prefetchable) [size=128M] Expansion ROM at dfe7 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [80] AGP version 2.0 PS: I´m not subscribed to the list, if you need to contact me than email at [EMAIL PROTECTED] . Everybody can learn how to make kids, but not everyone can raise them right! It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - 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
Re: PROSAVAGE NO 3D SUPPORT?
On 2/14/07, Gala Dragos [EMAIL PROTECTED] wrote: Graphics Card: Savage (ProSavage8 KM266/KL266) Kernel: 2.6.19-2895.fc6 System: Fedora Core 6 X system: Xorg 7.0, Mesa drivers, OpenGL installed I get this warnings whe running glxgears: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering I had to add the following lines to Xorg.conf file: Section DRI Mode 0666 EndSection Section Extensions Option Composite Disable EndSection This enabled 3D support, otherwise it didn´t worked. The ¨Extensions¨ section is required to stop the screen flickering when running 3D apps. The FPS with indirect rendering is somewhere between 60 and 80 when the machine is not busy. Since you are using Xorg 7.0 not have accelerated indirect rendering, only accelerated direct rendering. Alex What´s going on? Is there 3D support for my graphics card or what? The card is recognized as ProSavageDDR under WindowsXP. lspci -v output below: 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] (prog-if 00 [VGA]) Subsystem: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 5 Memory at dfe8 (32-bit, non-prefetchable) [size=512K] Memory at d000 (32-bit, prefetchable) [size=128M] Expansion ROM at dfe7 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [80] AGP version 2.0 PS: I´m not subscribed to the list, if you need to contact me than email at [EMAIL PROTECTED] . Everybody can learn how to make kids, but not everyone can raise them right! - 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
Re: [R300][PATCH] Add/fix COS SIN + FP fixes
Jerome Glisse wrote: On 2/14/07, Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: Roland Scheidegger wrote: Rune Petersen Ok commited. I didn't look too closely at this but I've a couple of comments. - COS looks too complicated broken. If you'd want to get 2 with a LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5 instructions before performing the sine, for something you can easily do in two, using another constant (just 1 add + 1 cmp needed, if you use the right constants for the add). Maybe it's not that bad though, I don't know how many rgb and a slots it will actually consume, but still, are constant slots that rare? Second, you'd really need to do range reduction of the input, otherwise results will be very wrong for inputs outside [-pi, pi]. This would be true for taylor approximation too, of course, unless you do an infinite series :-). You wouldn't need to do that for SCS. Oh, and forgot to mention, you probably really want to use the higher precision variant by default. 12% max relative error (and even absolute it's still 6%) will likely be visible in some cases depending what the shader is doing. Even the enhanced version seems to miss opengl conformance (accurate to about 1 part in 10^5) by roughly a factor of 10, which stretches the meaning of about a bit probably already. You could also rely on the precision hint for fragment programs to switch to the faster version instead of a dri conf option (note though the spec explicitly states implementations are discouraged even in this case to perform optimizations which could have significant impact on the output). This patch: - Fixes COS. - Does range reductions for SIN COS. - Adds SCS. - removes the optimized version of SIN COS. - tweaked weight (should help on precision). - fixed a copy paste typo in emit_arith(). Roland would you mind testing if the tweaked weight helped? And Jerome would you mind committing this? Rune Petersen Pushed, git isn't so frightening trust me :) I'll make you a promise: after March 1. I'll commit my own patches.. until than I can't really get a handle on it (too much on my mind). Rune Petersen - 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
Re: [R300][PATCH] Add/fix COS SIN + FP fixes
Roland Scheidegger wrote: Rune Petersen wrote: This patch: - Fixes COS. - Does range reductions for SIN COS. - Adds SCS. - removes the optimized version of SIN COS. - tweaked weight (should help on precision). - fixed a copy paste typo in emit_arith(). Roland would you mind testing if the tweaked weight helped? Well I didn't test it first time (just quoting the numbers from the link you provided), but I guess that's fine too. I was actually wondering myself if it's better to optimize for absolute or relative error, so choosing a weight in-between should work too (the difference is not that big after all). A couple comments though: Since ((x + PI/2)/(2*PI))+0.5 is (x/(2*PI) + (1/4 + 0.5) you could optimize away the first mad for the COS case. Ah I see you're a bit short on consts, if you want to only use 2 (btw I'd say there should be 32 not only 16 but I have no idea why the driver restricts it to 16). Also, the comments for SCS seem a bit off. That's a pity, because without comments I can't really see what the code does at first sight :-). Looks like quite a few extra instructions though, are you sure not more could be shared for calculating both sin and cos? I've looked a bit closer (this is an interesting optimization problem...) and I think it should be doable with fewer instructions, though ultimately I needed 2 temps instead of 1 (I don't think it's much of a problem, 32 is plenty, PS2.0 only exposes 12). Ok the equation was: Q (4/pi x - 4/pi^2 x^2) + P (4/pi x - 4/pi^2 x^2)^2 Simplified to: y = B * x + C * x * abs(x) y = P * (y * abs(y) - y) + y const0: B,C,pi,P const1: 0.5pi, 0.75, 1/(2pi), 2.0pi That's what I came up with with pseudo-code: //should be 5 slots (I guess it might generate 6 due to force same-slot, //but that needs fixing elewhere) //cos is even: cos(x) = cos(-x). So using simple trigo-fu //we get sin(neg(abs(x)) + pi/2)) = cos(x), no comparison needed and all //values for sine stay inside [-pi,pi] ([-pi/2, pi/2], actually) //hope it's ok to use neg+abs simultaneously? temp.z = add(neg(abs(src)), const1.x) temp.w = mul(src, C) //temp.xy = B*x, C*x (cos), temp.w = C * x, temp2.w = B * x (sin) temp.xy = mul(temp.z, BC) temp2.w = mul(src, B) //do cos in alpha slot not sin due to restricted swizzling //sin y = B * x + C * x * abs(x) temp2.z = mad(temp.w, abs(src), temp2.w) //cos temp2.w = mad(temp.y, abs(temp.z), temp.x) temp.xy = mad(temp2.wzy, abs(temp2.wzy), neg(temp2.wzy)) // now temp.x holds y * abs(y) - y for cos, temp.y same for sin dest.xy = mad(temp.xy, P, temp2.wzy) range reduction for cos: x = (x/(2*PI))+0.75 x = frac(x) x = (x*2*PI)-PI sin: x = (x/(2*PI))+HALF x = frac(x) x = (x*2*PI)-PI Isn't that an elegant solution :-) There may be any number of bugs, of course... Roland - 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
Re: [R300][PATCH] Add/fix COS SIN + FP fixes
Roland Scheidegger wrote: Rune Petersen wrote: This patch: - Fixes COS. - Does range reductions for SIN COS. - Adds SCS. - removes the optimized version of SIN COS. - tweaked weight (should help on precision). - fixed a copy paste typo in emit_arith(). Roland would you mind testing if the tweaked weight helped? Well I didn't test it first time (just quoting the numbers from the link you provided), but I guess that's fine too. I was actually wondering myself if it's better to optimize for absolute or relative error, so choosing a weight in-between should work too (the difference is not that big after all). A couple comments though: Since ((x + PI/2)/(2*PI))+0.5 is (x/(2*PI) + (1/4 + 0.5) you could optimize away the first mad for the COS case. I knew you were going to catch that. I ran out of scalers in the 2 consts I use. Decided to trade one instruction for one const. If you think its better to sacrifice a const, I wont mind changing it. Also, the comments for SCS seem a bit off. That's a pity, because without comments I can't really see what the code does at first sight :-). Looks like quite a few extra instructions though, are you sure not more could be shared for calculating both sin and cos? sorry about the comment. I see SCS as a work in progress. I felt I was fighting how emit_arith() syncs the vector scalar instructions. I intend to improve amit_arith() before taking a shot at improving SCS any further. I was thinking of storing when each scalar in a temp was written to and use it to pack th instruction tighter. Otherwise, looks good to me. Keep up the good work! Thank you for you comments. Rune Petersen - 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
Re: [R300][PATCH] Add/fix COS SIN + FP fixes
Roland Scheidegger wrote: Roland Scheidegger wrote: Rune Petersen wrote: This patch: - Fixes COS. - Does range reductions for SIN COS. - Adds SCS. - removes the optimized version of SIN COS. - tweaked weight (should help on precision). - fixed a copy paste typo in emit_arith(). Roland would you mind testing if the tweaked weight helped? Well I didn't test it first time (just quoting the numbers from the link you provided), but I guess that's fine too. I was actually wondering myself if it's better to optimize for absolute or relative error, so choosing a weight in-between should work too (the difference is not that big after all). A couple comments though: Since ((x + PI/2)/(2*PI))+0.5 is (x/(2*PI) + (1/4 + 0.5) you could optimize away the first mad for the COS case. Ah I see you're a bit short on consts, if you want to only use 2 (btw I'd say there should be 32 not only 16 but I have no idea why the driver restricts it to 16). Also, the comments for SCS seem a bit off. That's a pity, because without comments I can't really see what the code does at first sight :-). Looks like quite a few extra instructions though, are you sure not more could be shared for calculating both sin and cos? I've looked a bit closer (this is an interesting optimization problem...) and I think it should be doable with fewer instructions, though ultimately I needed 2 temps instead of 1 (I don't think it's much of a problem, 32 is plenty, PS2.0 only exposes 12). Ok the equation was: Q (4/pi x - 4/pi^2 x^2) + P (4/pi x - 4/pi^2 x^2)^2 Simplified to: y = B * x + C * x * abs(x) y = P * (y * abs(y) - y) + y const0: B,C,pi,P const1: 0.5pi, 0.75, 1/(2pi), 2.0pi That's what I came up with with pseudo-code: //should be 5 slots (I guess it might generate 6 due to force same-slot, //but that needs fixing elewhere) //cos is even: cos(x) = cos(-x). So using simple trigo-fu //we get sin(neg(abs(x)) + pi/2)) = cos(x), no comparison needed and all //values for sine stay inside [-pi,pi] ([-pi/2, pi/2], actually) //hope it's ok to use neg+abs simultaneously? temp.z = add(neg(abs(src)), const1.x) temp.w = mul(src, C) //temp.xy = B*x, C*x (cos), temp.w = C * x, temp2.w = B * x (sin) temp.xy = mul(temp.z, BC) temp2.w = mul(src, B) //do cos in alpha slot not sin due to restricted swizzling //sin y = B * x + C * x * abs(x) temp2.z = mad(temp.w, abs(src), temp2.w) //cos temp2.w = mad(temp.y, abs(temp.z), temp.x) temp.xy = mad(temp2.wzy, abs(temp2.wzy), neg(temp2.wzy)) // now temp.x holds y * abs(y) - y for cos, temp.y same for sin dest.xy = mad(temp.xy, P, temp2.wzy) range reduction for cos: x = (x/(2*PI))+0.75 x = frac(x) x = (x*2*PI)-PI sin: x = (x/(2*PI))+HALF x = frac(x) x = (x*2*PI)-PI Isn't that an elegant solution :-) There may be any number of bugs, of course... Very elegant I must say. Thank you I'll see about implementing this. Rune Petersen - 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
Re: i915 trouble -- IRQ being disabled
Hi,
This issue (IRQ being disabled) is still present in 2.6.20 and
2.6.20-git-as-of-yesterday. It breaks suspend-to-{}, it breaks switching
from console to tty, and sometimes it locks the system when trying to
shutdown. Any ideas?
Thanks,
Dominik
On Tue, Jan 30, 2007 at 12:59:04AM -0500, Dominik Brodowski wrote:
Hi,
On Mon, Jan 29, 2007 at 01:00:39PM +0100, Michel Dänzer wrote:
On Sun, 2007-01-28 at 22:14 -0500, Dominik Brodowski wrote:
[...] I was able to git bisect it down to the drm patches which went in
after 2.6.19 and before 2.6.19-rc1 got released.
Can you bisect it down to a single commit? If that's not possible with
the kernel tree, you can try the drm git tree from
git://git.freedesktop.org/git/mesa/drm .
The culprit is one of these (kernel git tree):
2228ed67223f3f22ea09df8854e6a31ea06d5619 - drm: i915 updates
a0b136bb696cfa744a79c4dd0c8f9f30fe3f - drm: i915: fix up irqflags arg
21fa60ed4eab5b3b28d05930bb086615ecc191b1 - drm: i915: Only return EBUSY...
2dbb232c4d6b6c89fc367f7566c7c87dd3b56cd7 - drm: i915: Fix 'sequence has...
376642cf2eb0f32d8502b0a2c4efd96a3f13a8b8 - drm: i915: Add SAREA fileds...
5b51694aff705c465ef5941a99073036f3e444d9 - drm: Make handling of...
2228ed72... has the issue, while
541f29aad766b6c7b911a7d900d952744369bf53 - drm: DRM_I915_VBLANK_SWAP
doesn't have it -- and all kernels in between crash during X startup, and
the last message in the X logs is
(II) I810(0): X context handle = 0x1
instead of:
(II) I810(0): X context handle = 0x1
(II) I810(0): [drm] installed DRM signal handler
(II) I810(0): [DRI] installation complete
(II) I810(0): direct rendering: Enabled
(II) I810(0): RandR enabled, ignore the following RandR disabled message.
(II) I810(0): Rotating to 0 degrees
(--) RandR disabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
drmOpenDevice: node name is /dev/dri/card0
As a sidenote, the last working kernel
541f29aad766b6c7b911a7d900d952744369bf53 - drm: DRM_I915_VBLANK_SWAP
returned this in dmesg when switching from console to terminal:
[ 108.905000] INFO: trying to register non-static key.
[ 108.905000] the code is fine but needs lockdep annotation.
[ 108.905000] turning off the locking correctness validator.
[ 108.905000] [c01034ee] dump_trace+0x64/0x1d0
[ 108.905000] [c0103674] show_trace_log_lvl+0x1a/0x2f
[ 108.905000] [c0103d29] show_trace+0x12/0x14
[ 108.905000] [c0103dcc] dump_stack+0x19/0x1b
[ 108.905000] [c012df5f] __lock_acquire+0x128/0x995
[ 108.905000] [c012eae2] lock_acquire+0x6e/0x8b
[ 108.905000] [c039ced3] _spin_lock_irqsave+0x3e/0x4e
[ 108.905000] [c0268bbf] i915_vblank_tasklet+0x3f/0x314
[ 108.905000] [c0263482] drm_unlock+0x8e/0x115
[ 108.905000] [c0261ac0] drm_ioctl+0x15b/0x19f
[ 108.905000] [c0166780] do_ioctl+0x50/0x67
[ 108.905000] [c01669e3] vfs_ioctl+0x24c/0x25f
[ 108.905000] [c0166a27] sys_ioctl+0x31/0x4a
[ 108.905000] [c0102e4d] sysenter_past_esp+0x56/0x8d
[ 108.905000] [b7f1d410] 0xb7f1d410
[ 108.905000] ===
Any ideas? Any debugging you want me to do?
echo 1 /sys/module/drm/parameters/debug
before switching to console might provide something interesting in the
kernel output.
this is with 2.6.19-rc6-latest:
lots of similar messages
[ 1320.522000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=
[ 1320.527000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0080
[ 1320.53] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=
[ 1320.538000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0020
[ 1320.542000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0080
[ 1320.546000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=
[ 1320.554000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0020
[ 1320.557000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0080
[ 1320.562000] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=
[ 1320.57] [drm:i915_driver_irq_handler] i915_driver_irq_handler
flag=0020
[ 1320.571000] [drm:drm_ioctl] pid=6459, cmd=0x4004644d, nr=0x4d, dev 0xe200,
auth=1
[ 1320.571000] [drm:drm_ioctl] pid=6459, cmd=0x40086414, nr=0x14, dev 0xe200,
auth=1
[
