Re: Windows build broken :/

At 09:54 AM 12/4/2003 -0700, Brian Paul wrote:
>Karl Schultz wrote:
>>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.
>
>So, what's the status of this issue?
>
>I'd like to release 5.1 before the end of the month.
>
>-Brian

I am going to try to remove GLAPIENTRY function decorations from the 
dispatch table, effectively removing it from most of the core, taking care 
of the basic issue.  If it works out, we'll have to regen a few of the 
python-generated files.

If it does not work out, I have some changes I can check in to make Windows 
build again, but this will just prolong the problem since functions will 
probably get added without the decoration, breaking the Windows build 
again.  I hope the first approach works.

I should have time this afternoon to try it;  If not, then tomorrow.

Karl

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click