RE: Windows build broken :/

At 07:14 PM 12/2/2003 +0000, Matt Sealey wrote:

> > -----Original Message-----
> > From: mesa3d-dev-admin <at> lists.sourceforge.net
> > [mailto:mesa3d-dev-admin <at> lists.sourceforge.net]On Behalf Of Keith
> > Harrison
> > Sent: 02 December 2003 13:41
> > To: mesa3d-dev <at> lists.sourceforge.net
> > Subject: Re: [Mesa3d-dev] Windows build broken :/
> >
> >
> >
> > ----- Original Message -----
> > From: "Karl Schultz" <k.w.schultz <at> comcast.net>
> > To: <matt <at> niblet.co.uk>; "Keith Whitwell" <keith <at> tungstengraphics.com>
> > Cc: <mesa3d-dev <at> lists.sourceforge.net>
> > Sent: Monday, December 01, 2003 6:43 PM
> > Subject: RE: [Mesa3d-dev] Windows build broken :/
> >
> >
> > > >We could just disable the assembler dispatch under Windows. Serves them
> > right.
> >
> > Grrrr. You're off my Christmas Card list. 
>
>:)
>
> > > We never used assembler dispatch under Windows as far as I know.
> >
> > Assembler dispatch on Windows used to work just fine, and made a big
> > difference to call-heavy apps. If it's broken in the current Mesa source
> > base then it's been broken somewhere down the line.
>
>Probably because of this cdecl/stdcall havoc :)

There's that, and I really don't think that it has been in Windows Mesa (as 
maintained in SourceForge) for quite awhile.  I've been baby-sitting the 
Windows code now for 2-3 years and I certainly don't remember any assembler 
dispatch code being in the Windows stuff.  Perhaps it was there before I 
knew about it, or maybe somebody (Keith H) is thinking about a modified 
snapshot that he was working with.  Keith mentioned hacking VC6 projects to 
use the asm dispatch, and I know that wasn't with the Mesa we have in 
SourceForge, because I just recently added VC projects.

>Certainly the external exported functions are all stdcall and all simply
>just, by default, call another function, and if it's cdecl, the compiler
>will handle this.

Yes.

>I would have to think we should weigh it up based on whether it makes
>Mesa internals more or less complexed: if all the insides are cdecl,
>then everything is a known thing. The dispatch code would have to either
>be made to convert from stdcall to cdecl manually (possibly better than
>the compiler could) or we just ignore it and let the compiler do it.

My feeling is that since the symbol is called GLAPIENTRY, it should really 
govern how the library entry points are defined, and not so much how the 
internal functions are defined.  So, that calls for removing GLAPIENTRY 
from all internal functions and then just letting the code in dispatch.c 
handle the conversion.  GLAPIENTRY would still be used to decorate the 
library entry points, and the entry points in the dispatch table would be 
undecorated and cdecl by default on Windows.  If the functions in the 
dispatch table are called directly by other entities (DRI on Linux, etc), 
it should still work because the dispatch table function prototypes will 
still force the correct linkage, although I suspect that GLAPIENTRY is "" 
on all but Windows platforms and it won't make a difference anyway.

I'll try this modification as an experiment and see how it works out.

>I wonder if we could do some speed tests on the standard Windows GL
>library and see if it has the same performance problem (if all of it's
>internal stuff and ICD/MCD stuff is cdecl?). If it does, it's not a
>big deal to leave this compiler-aided conversion, is it?

I don't think that it is a big deal.  I think part of the issue is 
comparing how a stdcall function calls another stdcall function with how a 
stdcall function calls a cdecl function.  In the first case, I'm not sure 
that the compiler would generate code that doesn't make a new stack frame 
and re-push the parms.  Hand-written asm could probably get around it.  So, 
I don't think that the stdcall->cdecl case is that more expensive than the 
stdcall->stdcall case, without hand optimization.  That is, if you are 
going to make a new stack frame and re-push the parms, the conversion 
doesn't matter as much.

I am in favor of isolating all this bother to the smallest area possible.

> > GLDirect utilised the asm dispatch code and X86, 3DNow and SSE asm
> > fastpaths. This code made a significant difference in Mesa performance in
> > the heaps of Win32 GL apps that SciTech and I tested with. OK, so it
> > required some voodoo incantations within my VC6 project files in order to
> > preprocess and compile the .S asm code, but it did actually work.
> >
> > Whomever wrote the asm code should receive the recognition that they
> > deserve. 
>
>I think the fastpaths will work regardless. It's just that dispatch
>code. I vote compiler-based, there's no need to have a whole other
>mismatching convention out there for different parts of Mesa. If
>any of the functions are in the loopback tables anyway, the compiler
>is going to have to convert from cdecl to stdcall anyway? And it'll
>sap speed regardless?

Yeah, and we can still have asm dispatch someday.  Isolating the conversion 
to dispatch.c may make that easier.  Also, most of the questions I handle 
on the Windows Mesa code are from people who aren't going to want to deal 
with this sort of stuff.  It's fine for those few that know what they're doing.

Karl

-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8