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.

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

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).

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.

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.

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?

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.

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.