Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] XFree 4.3.99, GLX: no double buffered visuals?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc
View previous topic :: View next topic  
Author Message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Wed Apr 14, 2004 2:26 am    Post subject: [SOLVED] XFree 4.3.99, GLX: no double buffered visuals? Reply with quote

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
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Wed Apr 14, 2004 10:20 pm    Post subject: Reply with quote

I figured it out :D

I had the xfree DRI drivers (for xfree-4.1!) in the 2.4 kernel turned on. :oops: Disabled them, and now glxgears and friends run fine (~40fps in default size window, btw).
Back to top
View user's profile Send private message
GenTimJS
Guru
Guru


Joined: 03 May 2003
Posts: 406
Location: NH, USA

PostPosted: Thu Apr 15, 2004 10:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ferris
Retired Dev
Retired Dev


Joined: 13 Jan 2003
Posts: 426
Location: N. Virginia (USA)

PostPosted: Thu Apr 15, 2004 11:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Fri Apr 16, 2004 12:34 am    Post subject: Reply with quote

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 :D
Back to top
View user's profile Send private message
Ferris
Retired Dev
Retired Dev


Joined: 13 Jan 2003
Posts: 426
Location: N. Virginia (USA)

PostPosted: Fri Apr 16, 2004 12:50 am    Post subject: Reply with quote

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
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Fri Apr 16, 2004 1:45 am    Post subject: Reply with quote

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
View user's profile Send private message
Ferris
Retired Dev
Retired Dev


Joined: 13 Jan 2003
Posts: 426
Location: N. Virginia (USA)

PostPosted: Wed Apr 28, 2004 12:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Wed Apr 28, 2004 9:01 pm    Post subject: Reply with quote

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 :D

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 :lol:

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
View user's profile Send private message
Ferris
Retired Dev
Retired Dev


Joined: 13 Jan 2003
Posts: 426
Location: N. Virginia (USA)

PostPosted: Wed Apr 28, 2004 10:27 pm    Post subject: Reply with quote

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. :wink:
Back to top
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Thu Apr 29, 2004 2:11 pm    Post subject: Reply with quote

Ferris wrote:

On the other hand, as long as xfree is working well for you, there's no compelling reason to
switch. :wink:


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
View user's profile Send private message
Weeve
Retired Dev
Retired Dev


Joined: 30 Oct 2002
Posts: 641

PostPosted: Fri Apr 30, 2004 12:12 am    Post subject: Reply with quote

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
View user's profile Send private message
spam_
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jan 2004
Posts: 105
Location: /dev/null

PostPosted: Fri Apr 30, 2004 7:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc All times are GMT
Page 1 of 1

 
Jump to:  
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