On Mon, 30 Oct 2000, beef wrote:
> On Sat, 28 Oct 2000, Jon M. Taylor wrote:
>
> > I just committed a bunch of GGIMesa fixes to the Mesa CVS tree. It
> >_should_ all build just fine again, but I have weird libtool and autoconf
> >incompatibilities popping up which are preventing the final library
> >install so I can't test it over here. If someone else could test it for
> >me, that would be cool. Brian, I still have to merge those config file
> >patches you sent me - some of that stuff isn't strictly correct.
> >
> >Jon
>
> I have Mesa-HEAD-20001029, ggi-devel-20001028:
> see attachement for the bits i changed to build.
>
> It kindof works, but flickers horribly on the fbdev.
Argh! Why are you and Stefan getting this to work, when I get
segfaults???
> A 3rd party demo complained about 'too few' stencil bits. are there any?
Stencil buffers are not supported in GGIMesa at this time. I'll
look into it.
> what/where _could_ this doublebuffer problem be?
>
> --
> #berlin
> <stefan> bvc: I had hoped Jon would fix the double buffer problem as well...
> <stefan> bvc: mesa / ggi on /dev/fb flickers awefully
> <stefan> bvc: unfortunately, it appears Jon is the only person knowing
> MesaGGI. There is nobody else who can fix that. :(
OK, here's the whole story in detail. Way back in mid-1999, I was
working at Creative Labs on an accelerated KGIcon device driver for the S3
Savage4 chipset (this project died an ugly death when S3 bought STB and
became a competitior...). This meant that I needed to be able to handle
both software and hardware accelerations in the GGIMesa targets, including
soft/hard front and backbuffer mappings and page flipping. The
doublebuffer implementation in GGIMesa at the time was based on
malloc()ing a separate backbuffer, drawing into that and blitting it to
the frontbuffer (the ggi_visual) every flush(). This was not compatible
with the acceleration cut-in architecture I had in mind at the time - no
way to hook a separate buffer-mapping function and no possibility to use
hardware acceleration.
So, I did a QuickHack(tm) to work around the problem - I pointed
both buffers to the ggi_visual |->. This let me render to either the
front or back buffer, mapped to either hardware or software
front/backbuffers, with or without hardware acceleration for both drawing
triangles and the page flips. As you have seen it also causes horrible
flickering. But it "worked" and at the time that was all I was interested
in. The hack was never meant to be more than a stopgap until I figured
out how to do it all properly. Unfortunately, there wasn't much in the
way of buffer management API cut-ins in Mesa at the time, so it turned out
to be more work than I had anticipated, and a few weeks later my Savage4
driver project got canned and I stopped working on GGIMesa except for the
occasional build fixes to keep up with the changing Mesa internals.
I never implemented a better buffer-mamangement scheme, because I
was (and still am) unsure as to the best way to provide target hooks for
buffer-management and page flipping functions in the GGIMesa targets. I'm
going to try again - I'm a lot better at writing GGI extensions after my
work on LibXMI earlier this year and Mesa's internals have gotten a LOT
better recently. But in the meantime, I'm going to revert back to the
software-only double buffering scheme I threw away last year so people can
run on fbdev without horrible flickering. Note that it will still flicker
somewhat, because fbdev has no way to poll for VSYNC and thus the GGI
fbdev target has no way to synchronize ggiFlush() calls with the vertical
retrace.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
