Re: GLX in bad state

No confessions?

On Mon, 5 Apr 2004, Gavriel State wrote:

> We have internal code not yet in CVS that we're working with that implements
> real Pixel Shaders, so we have not really given very much thought to the
> patch.It's up to the engineer working on the Pixel Shader code to decide
> whether a stub should go into CVS in the meantime.He's considering it now.

> As we've stated in the past, we are very particular about the patches that
> we allow into CVS, and we don't like checking things in that have either
> known issues or that have known paths that might cause issues, unless there's
> a very compelling reason for it.
 
I think I know a bit about the WineX code.  If you have an invalid pointer 
to an unimplemented function, WineX will crash when that function is 
called.  Therefore, there are no negative issues with adding a stub.

Now perhaps you will come forward with some benchmark results.

> As Ove stated, this is the overall philosophy of the OpenGL design in
> general, not ours.Obviously performance is very important to us.

How is the overall philosophy of the OpenGL design (whatever it may be) 
relevant to this discussion?

> If you'd like to determine where there might be further performance issues
> with your updated video memorymanagement code, you might try doing a trace
> with +timestamp,+x11drv,+ddraw to narrow down what's actually taking up
> time.

This is a bad approach for the following reasons:

1.  This level of debugging will slow the performance to such an extent 
    that the overall analysis of performance will become irrelevant.
2.  The overall performance is an accumulation of routines which on their 
    own waste less CPU time than is measurable by the time stamp.
3.  The performance may be slow because the graphics card is used in an 
    inefficient way.  Such performance losses will occur when the video 
    card executes the command and not when the command is issued.
4.  The timestamps will also include time spent executing the game's 
    binaries and libraries other than x11drv and ddraw.
5.  The game's binary may be doing some excess computation in response to 
    unexpected feedback from WineX.  This will not be revealed.

A much better approach is a profiler like 'oprofile'.  It has the 
limitation, however, that it does not show what the video card and the 
games's binary is working on.  The information received from differently 
spec'ed systems would benefit such an analysis.

Nadav Frum
----------