Re: GLX in bad state

Nadav Frum wrote:
> Are you going to include my patch in the CVS or is it a Transgaming 
> policy decision to keep the C4 Benchmark broken?  (Which means no pixel 
> shaders.)

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.

> Do you invite outsiders to provide patches and accept them only so long as 
> they do not expose inadequacies in WineX or your knowledge base?

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.

>>And when that's not the case, the extension may not provide the
>>performance boost, but it may still reduce memory requirements, which
>>can still be useful. And OpenGL has always been an API where
>>functionality and device independence is more important than
>>performance, so I wouldn't be surprised if this extension was designed
>>to function everywhere, even on hardware where there would be no gain
>>whatsoever, just so it would be possible to make it a standard OpenGL
>>feature in the future.
> 
> 
> "functionality and device independence is more important than performance" -
> Wow!  Is this your motto?

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

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

Take care,
  -Gav


-- 
Gavriel State
Co-CEO & CTO
TransGaming Technologies Inc.
[email protected]
http://www.transgaming.com

Let the games begin!