View previous topic :: View next topic |
Author |
Message |
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Wed Apr 14, 2004 2:26 am Post subject: [SOLVED] XFree 4.3.99, GLX: no double buffered visuals? |
|
|
I just upgraded to xfree-4.3.99.902-r2 (the last before the licensing change) on my U1E-200 with a Creator card. Luckily most everything still seems to work.
I was hoping to get GLX working (because of the infamus libGL.so sparc segfault bug), but instead I get this:
Code: |
krypton root # glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x27 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
|
Code: |
krypton root # glxgears
Error: couldn't get an RGB, Double-buffered visual
|
Code: |
krypton root # xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: Gentoo Linux (XFree86 4.3.99.902, revision r2)
vendor release number: 40399902
XFree86 version: 4.3.99.902
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 132
focus: window 0xa0000e, revert to PointerRoot
number of extensions: 29
BIG-REQUESTS
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RECORD
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-DRI
XFree86-Misc
XFree86-VidModeExtension
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1152x900 pixels (390x305 millimeters)
resolution: 75x75 dots per inch
depths (2): 24, 8
root window id: 0x2b
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x21
default number of colormap cells: 256
preallocated pixels: black 0, white 16711422
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0xda001f
KeyPressMask KeyReleaseMask ButtonPressMask
ButtonReleaseMask EnterWindowMask StructureNotifyMask
SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask
ColormapChangeMask
number of visuals: 2
default visual id: 0x27
visual:
visual id: 0x27
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
|
And in the console where X is started, this interesting one:
Code: |
Detected FFB1, Single-buffered.
|
Seems like double buffering isn't supported by the hardware. But shouldn't X provide the buffers in software (via the Load "dbe" in the XF86Config, below)?
/etc/X11/XF86Config (some of the commented stuff is for 2.6 kernels, running sparc-sources 2.4.25 right now):
Code: |
Section "ServerLayout"
Identifier "XFree86 Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
ModulePath "/usr/X11R6/lib/modules"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
FontPath "/usr/X11R6/lib/X11/fonts/CID/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
EndSection
Section "Module"
Load "dbe"
Load "dri"
Load "extmod"
Load "glx"
#Load "pex5" #problematic
Load "record"
#Load "xie" #problematic... ??? X refuses to start with this or pex5 enabled
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbKeycodes" "sun(type5)"
#Option "XkbTypes" "default"
#Option "XkbCompat" "default"
#Option "XkbSymbols" "sun/us(sun5)"
Option "XkbGeometry" "sun"
Option "XkbRules" "xfree86"
Option "XkbModel" "sun"
#Option "XkbLayout" "sun/us"
#Option "XkbRules" "xfree86"
#Option "XkbRules" "sun"
#Option "XkbModel" "type5"
#Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "BusMouse"
#Option "Protocol" "IMPS/2"
Option "Device" "/dev/sunmouse"
#Option "Device" "/dev/input/mice"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 31.5 - 64.3
VertRefresh 50.0 - 90.0
EndSection
Section "Device"
Identifier "Card0"
Driver "sunffb"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Depth 8
EndSubSection
SubSection "Display"
Depth 15
EndSubSection
SubSection "Display"
Depth 16
EndSubSection
SubSection "Display"
Depth 24
EndSubSection
EndSection
Section "DRI"
Mode 0666
EndSection
|
What gives?
Last edited by spam_ on Wed Apr 14, 2004 10:21 pm; edited 1 time in total |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Wed Apr 14, 2004 10:20 pm Post subject: |
|
|
I figured it out
I had the xfree DRI drivers (for xfree-4.1!) in the 2.4 kernel turned on. Disabled them, and now glxgears and friends run fine (~40fps in default size window, btw). |
|
Back to top |
|
|
GenTimJS Guru
Joined: 03 May 2003 Posts: 406 Location: NH, USA
|
Posted: Thu Apr 15, 2004 10:43 pm Post subject: |
|
|
So your saying all things being equal that the creator3d driver finally has working acceleration?
or that you applied the messy patch which wants you to hand-splice sparc assembler code, and it worked? _________________ -Tim Smith |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Thu Apr 15, 2004 11:03 pm Post subject: |
|
|
spam_, could please provide aa couple more lines describing just what
you did (did you comment out the
Code: |
CONFIG_DRM_NEW=y
CONFIG_DRM_FFB=y
|
lines, or something else)?
The messy patch is much less messy now, and it is incorporated in xfree-4.3.99.902-r2. I think this solution is a way around a completely
different bug (new with this snapshot), unfortunately, but it confrms my
suspicion that some libGL modules are "out of sync" with each other right
now in the case where acceleration is compiled into the kernel, but there is
no working dri module. (As ffb_dri.so is not).
Essentially, libGL+sunffb notice that acceleration should work, notice that
dri/ffb_dri.so cannot be loaded, and fall back to the (xfree) software version.
This software version has not kept up with the GL/glx code, because this
is only a snapshot (and thus not finished).
I'm glad to know that your fix works, though (but at some performance
expence). That is useful information. |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Fri Apr 16, 2004 12:34 am Post subject: |
|
|
Ferris wrote: | spam_, could please provide aa couple more lines describing just what
you did (did you comment out the
Code: |
CONFIG_DRM_NEW=y
CONFIG_DRM_FFB=y
|
lines, or something else)? |
Since I'm using a 2.4 kernel with a 4.3 XFree, the DRM in the kernel is not supposed to be compatible (at least that's what I've read). In make menuconfig, I disabled whatever the top-level XFree-drm driver config option was.
Ferris wrote: |
The messy patch is much less messy now, and it is incorporated in xfree-4.3.99.902-r2. I think this solution is a way around a completely
different bug (new with this snapshot), unfortunately, but it confrms my
suspicion that some libGL modules are "out of sync" with each other right
now in the case where acceleration is compiled into the kernel, but there is
no working dri module. (As ffb_dri.so is not). |
DRI was working OK but wouldn't allow GL apps to run, disabling it in the kernel forced XFree to disable its DRI which made things suddenly start working. I don't think it would have worked in 4.3.0 either, I remember xdpyinfo returning only 2 visuals which is what happened in 4.3.99 until I disabled DRI. Of course 4.3.0 had the sparc GL segfault bug so I can't tell without applying the patch (your patch, I believe) for it.
Ferris wrote: | Essentially, libGL+sunffb notice that acceleration should work, notice that
dri/ffb_dri.so cannot be loaded, and fall back to the (xfree) software version. |
In /var/log/XFree86.0.log, drawing acceleration is still enabled although DRI is disabled. Sounds like what you're saying it should be. I don't have a Creator3D card, only a Creator card, so I was only expecting software 3D.
Ferris wrote: | This software version has not kept up with the GL/glx code, because this
is only a snapshot (and thus not finished).
I'm glad to know that your fix works, though (but at some performance
expence). That is useful information. |
Actually the framebuffer drawing performance seems to be untouched. I was getting about 15fps average in Quake2, about 5 minimum (big firefight), and 30 maximum (looking at a wall in a low-poly room) with DRI on (this is with Quake2's software X11 driver). With DRI off, the figures are the same which makes me happy enough
One dangerous thing I did in building 4.3.99 is that I built with CFLAGS="-O3 -ffast-math -fomit-frame-pointer -mcpu=ultrasparc -pipe", that must provide a pretty good performance boost as it greatly speeds floating point which is what most of OpenGL uses. I checked, and the ebuild doesn't filter those flags, I saw the GL libraries build with -ffast-math.
I've actually rebuilt pretty much the whole OS (short of the kernel, which probably doesn't even use floats) with -ffast-math and no bad effects. Firefox seems to be noticably faster in rendering a webpage. Maybe I'm just lucky.
I toy with writing OpenGL programs and the software rendering feels 'fast enough', so far. If I start doing fancier stuff (fog, blending, lighting) I'll have to move to my better, but less interesting, P4 desktop (running Gentoo of course). I just really like the feel of the Sun type5c keyboard under my fingers |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Fri Apr 16, 2004 12:50 am Post subject: |
|
|
Thanks! That's very useful. Anything else you can pass on I'd greatly
appreciate. Do you have a reference for kernel-DRM not compatible with
xfree-4.3?
You can see a long history of some of this at bug 19776. The patch addresses
only why libGL wouldn't work at all. It doesn't address any of the GL
issues you brought up, because no one else has mentioned them (and
they don't figure into the seg fault problem).
Regards, |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Fri Apr 16, 2004 1:45 am Post subject: |
|
|
GenTimJS wrote: | So your saying all things being equal that the creator3d driver finally has working acceleration?
or that you applied the messy patch which wants you to hand-splice sparc assembler code, and it worked? |
Whoops, just noticed your post. Sorry for the late response.
No, the C3D does not have working 3d acceleration yet. I upgraded to xfree-4.3.99.902-r2, which incorporates a fix which gets rid of the sparc+GL segfault problem, which was the only thing I was trying to fix. All 3D is still done in software by Mesa, and I only have a 2D Creator anyway.
The problem was that for some reason the DRI drivers in the kernel were preventing GL apps from acquiring the RGB double-buffered visual they expect. Disabling the kernel drivers made things work.
Ferris wrote: |
Thanks! That's very useful. Anything else you can pass on I'd greatly
appreciate. Do you have a reference for kernel-DRM not compatible with
xfree-4.3?
|
I've read around and seen it several times, but the Gentoo DRI guide definitely states it:
Quote: |
Since the 2.4 kernels' Direct Rendering Manager (DRM) doesn't support XFree 4.3, the xfree-drm package is needed. If you're using a 2.6 kernel, its DRM supports XFree 4.3; Gentoo's XFree-DRM package is not yet working on 2.6 kernels.
|
The xfree-drm package only includes x86 card drivers, so basically this says sparc + kernel 2.4 + XFree 4.3.x + DRI is right out. It works for me using the kernel drivers though, except for OpenGL. There's no 2D performance difference, and without DRI OpenGL works correctly.
Ferris wrote: |
You can see a long history of some of this at bug 19776. The patch addresses
only why libGL wouldn't work at all. It doesn't address any of the GL
issues you brought up, because no one else has mentioned them (and
they don't figure into the seg fault problem).
|
I looked at the patch, and didn't want to do it for some reason, instead I went for the 4.3.99 version which in the last post in the bug report (IIRC, #42 seems to ring a bell, and I think you posted it too) is said to be fixed. I wanted to try xfree-4.3.99 anyway and this was a good excuse
I've been playing with the NeHe OpenGL lessons (the SDL/GL versions), and the ones I've tried so far work fine. It's more than I expected to get working. |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Wed Apr 28, 2004 12:35 pm Post subject: |
|
|
spam_,
You might want to try turning the kernel DRM back on and using xorg-x11. Only
problem I know of is that you will have to do this by hand:
Code: |
opengl-update xorg-x11
|
after the install. I know that a few people are using it quite successfully with Creator3D+kernel DRM (2.4, and I believe 2.6).
It should be more stable for you than 2.3.99-xxx is.
(Try
Code: |
ACCEPT_KEYWORDS='~sparc' emerge -vp xorg-x11
|
and if that looks reasonable (should mention 3 or 4 packages),
Code: |
emerge -C xfree
ACCEPT_KEYWORDS='~sparc' emerge -v xorg-x11
opengl-update xorg-x11
etc-update
|
) |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Wed Apr 28, 2004 9:01 pm Post subject: |
|
|
Ferris wrote: | spam_,
You might want to try turning the kernel DRM back on and using xorg-x11. Only
problem I know of is that you will have to do this by hand:
Code: |
opengl-update xorg-x11
|
after the install. I know that a few people are using it quite successfully with Creator3D+kernel DRM (2.4, and I believe 2.6).
It should be more stable for you than 2.3.99-xxx is. |
More stable? Heh, nothing bad has happened yet. No crashes yet, and well over 100 hours of uptime in X
Ferris wrote: |
(Try
Code: |
ACCEPT_KEYWORDS='~sparc' emerge -vp xorg-x11
|
and if that looks reasonable (should mention 3 or 4 packages),
Code: |
emerge -C xfree
ACCEPT_KEYWORDS='~sparc' emerge -v xorg-x11
opengl-update xorg-x11
etc-update
|
) |
OK, but that's going to take me a few days, U1E/200 remember
Can xfree-4.3.99 and xorg-x11 be installed at the same time without any problems? I'm thinking not, since xorg-x11 is just a fork, right?
On a side note, I just got hold of a 13W3->4BNC video cable, I have my sparc hooked into a 24" behemoth SiliconGraphics CRT. One word: WOW. |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Wed Apr 28, 2004 10:27 pm Post subject: |
|
|
Re: Both installed.
No, they both provide the virtual x11 stuff, and in fact, the libraries and binaries, etc., go
the same places with the same names. You can use something like this to backup xfree
before erasing it, though, if you want to try xorg-x11.
Code: |
PACKAGE=`qpkg -I -v -nc | egrep xfree | sed 's:\(.*\):/var/db/pkg/\1:'`
/usr/lib/portage/bin/quickpkg $PACKAGE
|
On the other hand, as long as xfree is working well for you, there's no compelling reason to
switch. |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Thu Apr 29, 2004 2:11 pm Post subject: |
|
|
Ferris wrote: |
On the other hand, as long as xfree is working well for you, there's no compelling reason to
switch. |
In that case I probably won't. The only thing that bothers me is sometimes if X has been running idle for a long period of time, parts of the framebuffer's memory get filled with garbage, giving me funky-colored lines over roughly half the screen (usually combinations of white and green). If I force X to redraw everything in the framebuffer's memory (switch to a text console and back), it all goes away. No stability problems though. Any ideas? |
|
Back to top |
|
|
Weeve Retired Dev
Joined: 30 Oct 2002 Posts: 641
|
Posted: Fri Apr 30, 2004 12:12 am Post subject: |
|
|
When this happens to me, I've noticed it's related to X's automatic screen blanking after 10 minutes or so of idle time. If I use an alternative screen saver or shut off screen blanking, this doesn't seem to happen. |
|
Back to top |
|
|
spam_ Tux's lil' helper
Joined: 14 Jan 2004 Posts: 105 Location: /dev/null
|
Posted: Fri Apr 30, 2004 7:31 pm Post subject: |
|
|
Weeve wrote: | When this happens to me, I've noticed it's related to X's automatic screen blanking after 10 minutes or so of idle time. If I use an alternative screen saver or shut off screen blanking, this doesn't seem to happen. |
I have screen blanking in X turned off. I think it's related to the kernel's screen blanking...
BTW, all the consoles except the console X is on sometimes become completely unusable because they're black as if blanked, but nothing brings them back to life, even a (blind!) restart of the X server. This doesn't happen when X isn't running. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|