Re: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only
I didn't work on this patch, but I can add some answers to Mike's questions... On Sun, 30 Apr 2006 05:32:49 -0700, Mike Hearn wrote:
On Sat, 29 Apr 2006 14:46:33 -0700, Nick Burns wrote:
OpenGL dynamic loading -- Mac OSX does not need to dlsym every ogl entry point -- it handles that for you...
Hmm, well so do Windows and Linux ;) I think it's done that way because some of the GL functions are introduced in later versions of OpenGL so we need to test for them at runtime.
We can at least avoid any direct dlsym references on the Mac and simply use the glXGetProcAddress procedure. Also, for anything that is added to the OpenGL stack post 10.4.4 or whatever the first intel version of OS X was, it could avoid a huge amount of glXGetProcAddress's for the included opengl calls like glBegin, etc. Was there more to this you wanted to add, Nick?
Stack fudging -- mac requires 16 byte aligned stack windows does not -- this leads to illegal instructions (aligned wrongly)
This is an Intel Mac right?! Intel chips have never required alignment as far as I know, though it can help performance.
This is not a requirement by the processor, per se, but by the OS X ABI. When a windows function attempts to call into an OS X function, the ABI must be properly set up in order to work with the OS X ABI compliant code. 16 byte alignment is one requirement of OS X's ABI: <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ LowLevelABI/Articles/IA32.html>
GLX Root Window -- Wine uses the fact that a root window exists in x11 in many places... -- But no one wants to run the x11 root window on their mac (what the b&w checkerz are ugly?)
What stops you fixing the Mac X server to, well, not suck? I don't see why you need to hack Wine to fix this.
On systems that already have roots like the Window Server on OS X and the GDI root on Windows, your system then looks like Linux. This works fine and all, but it makes it so that Mac OS X and Windows apps don't show up side by side with the linux apps. In the end, I'm sure it would be most desirable to avoid X11 on the Mac completely because it's an optional install (albeit easily installable after the fact) and it just doesn't have an OS X feel to it, which is what people would desire who are running OS X. Chris
On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote:
We can at least avoid any direct dlsym references on the Mac and simply use the glXGetProcAddress procedure. Also, for anything that is added to the OpenGL stack post 10.4.4 or whatever the first intel version of OS X was, it could avoid a huge amount of glXGetProcAddress's for the included opengl calls like glBegin, etc.
Ah yes. We do this on Linux to avoid a hard OpenGL dependency, which not everybody will have. But you know users must have this on MacOS as the GUI is not optional.
This is not a requirement by the processor, per se, but by the OS X ABI.
I see. What a peculiar ABI. Well you can't possibly fix it the way you currently do, just force an aligned mmap for the stack when it's first allocated.
On systems that already have roots like the Window Server on OS X and the GDI root on Windows, your system then looks like Linux.
I don't understand. The root window doesn't have to be visible, as long as it exists for accounting purposes.
This is not a requirement by the processor, per se, but by the OS X ABI.
I see. What a peculiar ABI. Well you can't possibly fix it the way you currently do, just force an aligned mmap for the stack when it's first allocated.
The stack is allocated at least 16 byte aligned up front. The issue comes later when a function call occurs to OS X ABI from Windows ABI and the stack offset may not be 16 byte aligned. It needs to be realigned at this point. There is supposedly an attribute feature in the newest gcc that will allow this to occur in a robust manner and work wonders for wine's purposes when it becomes available: <http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01073.html>
On systems that already have roots like the Window Server on OS X and the GDI root on Windows, your system then looks like Linux.
I don't understand. The root window doesn't have to be visible, as long as it exists for accounting purposes.
It looks like Nick makes a button that he deals for reference instead of a root window, to query opengl limits and whatnot. This is because the OS X X11 simply does not allow a root window without covering up the nice composited window server. It doesn't look nice and you can't see any OS X native windows while the rooted mode is active. What I do know is that it would be nice in the long run to let users run Wine without X11, but of course that means more work for the Mac side of things. Best, Chris
On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote:
The stack is allocated at least 16 byte aligned up front. The issue comes later when a function call occurs to OS X ABI from Windows ABI and the stack offset may not be 16 byte aligned.
OK. You could fix this in winebuild as well.
This is because the OS X X11 simply does not allow a root window without covering up the nice composited window server.
Yes, that's what I meant ... just fix X11 on MacOS to not cover it up but still have a root window. Lots of X programs assume there is a root window and use it for communication, that's kind of a problem that needs to get fixed anyway. thanks -mike
Am Montag, 1. Mai 2006 01:10 schrieb Mike Hearn:
On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote:
The stack is allocated at least 16 byte aligned up front. The issue comes later when a function call occurs to OS X ABI from Windows ABI and the stack offset may not be 16 byte aligned.
OK. You could fix this in winebuild as well.
This is because the OS X X11 simply does not allow a root window without covering up the nice composited window server.
Yes, that's what I meant ... just fix X11 on MacOS to not cover it up but still have a root window. Lots of X programs assume there is a root window and use it for communication, that's kind of a problem that needs to get fixed anyway.
If Jesse Allen (or someone else) creates a DIB engine for this years SoC, shouldn't that make x11drv-replacements like a quartzdrv much easier to create? -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>
On Mon, 01 May 2006 01:59:54 +0200, Willie Sippel wrote:
If Jesse Allen (or someone else) creates a DIB engine for this years SoC, shouldn't that make x11drv-replacements like a quartzdrv much easier to create?
I don't see how, you still want to send drawing commands to the OS so it can be hardware accelerated. Though actually MacOS X does not hardware accelerate 2D primitives at all right now (unlike XGL/Xorg), and the window pixmaps are drawn client-side IIRC, so there might not be much real benefit for Mac users? thanks -mike
participants (3)
-
Chris Niederauer -
Mike Hearn -
Willie Sippel