Re: [Mesa3d-dev] dynamic code generation with gcc

[Stephen J B. <sj...@li...>]

On 13 Mar 2001, Josh Vanderhoof wrote:

> "Stephen J Baker" <sj...@li...> writes:
> 
> > If it's for something like varying the Z buffer depth - then a large
> > overhead might be acceptable (although I still maintain that creating
> > a dependence on a C compiler is a disasterously bad decision).
> 
> I just want to make sure there isn't a misunderstanding here - the C
> compiler would only be used to compile special case functions.  There
> would always be a generic fallback, so Mesa would work (although more
> slowly) even without a compiler installed.
 
Yes - but (as an application author) I have to tell you that well over
half the support problems I have for my code are Mesa-related and many
of them are of the form "The program runs really slowly on this machine
and much faster on that one...why?"  - and this kind of nonsense makes
that kind of thing MUCH worse.

You are going to run into all kinds of practical problem - where the
compiler isn't set up right - or it comes up with unexpected messages
to stdout that mess up people who pipe the output of their programs
off somewhere else.  Some people have C compilers - but not gcc.

There are just too many variables to make this work in a stable manner.

> > If it's something like catering for a particular combination of (say)
> > blend mode, texture type, dither and fogging (the kind of thing that
> > the SGI OpenGL-for-Windoze appears to do) - then taking even a couple
> > of milliseconds at runtime when you first happen to see a polygon with
> > that combination of states would be completely unacceptable - even with
> > caching.
> 
> If it was just 20 milliseconds or so, I doubt most users would notice.
> The problem is, I can easily see the delay being 500 ms for a big
> function.
> 
> I can think of two workarounds:
> 
> 1. Make the cache persistent, then the delay would only happen the
>    first time you run your application.
> 
> 2. Run the compiler in the background at low priority (say 10% cpu).
>    You would have to make do with the generic fallback until the
>    compile completes, but there wouldn't be a 'hitch' when the
>    application exposes a different path.
> 
> Do you think that would be acceptable?
 
Well, I have to say that I don't (yet) make much use of software
rendering - but in my business (Flight Simulation), the worst case
frame time is all that matters.  Occasional glitches in frame rate
are just as bad (from our customer's point of view) as persistantly
bad frame times.

However, we only use hardware accellerated OpenGL - so it's not an
issue in this *specific* case.

SGI's OpenGL-for-Windoze can do this without using a compiler - so
should we.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1