Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Friday 16 December 2005 23:07, Aric Cyr wrote:
> Last time I checked gcc doesn't enable optimizations unless a -O option is
> specified explicitly (don't know if this has changed though).
I realize it is a moot point wrt the topic, but as you may know, there's an
easy way to check. Running
sh$ echo 'main () {}' > bloated.c
sh$ gcc -v -Q $CFLAGS bloated.c
will, amongst other things, dump exactly what optimizations (in terms of
atomic gcc command-line optimizations) are used given the current setup and
CFLAGS environment variable.
My 3.4.4 does indeed do exactly the same thing with "-g" and "-g -O0".
--
gmt
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On 12/17/05, Lionel Ulmer <[EMAIL PROTECTED]> wrote: > On Wed, Dec 14, 2005 at 03:53:12AM +, Aric Cyr wrote: > > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get > > crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d > > everything works fine, but then wined3d is still dependent on glx. > > The answer is easy (did not read the complete thread in details to know if > you found out the solution or not): basically, 'wglGetProcAddress' returns > functions as expected by Win32 applications, so using the 'stdcall' calling > convention whereas 'glXGetProcAddress' returns them in the standard Unix > calling convention 'cdecl'. > > So you basically have the same problem with GL extensions that you had with > direct linking to OpenGL32.DLL instead of to libGL.so => all the calls going > through function pointers that you retrieved via 'wglGetProcAddress' will go > through thunks to change the calling convention (at the price of a slight > performance hit). That's exactly right. That's the conclusion I came to as well. It's all buried in my previous reply somewhere :) > Moreover, you will have a nice 'header' head-ache as you won't be able to > rely on the Linux distribution's version of 'glext.h' but on a version > compatible with Windows that adds the proper 'STDCALL' types to the function > pointer prototypes. Actually the header 'ache' doesn't hurt so much. The standard (official) glext.h from SGI defines APIENTRY, which we can just define to WINAPI (or __stdcall) before including glext.h. By default, on Linux anyways, APIENTRY is defined as nothing so there shouldn't be any problems. I have this all working already, and managed to get rid of all those horrible copy&paste #defines in wined3d_gl.h and a few other places as well. All-in-all things look a lot cleaner both in dlls/opengl32 and dlls/wined3d. The only catch is to watch out for what should be WINAPI and what should not, but it seems I got it all under control so far. Looking forward to your comments once I start sending the patches in. Regards, Aric -- Aric Cyr (http://acyr.net)
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Wed, Dec 14, 2005 at 03:53:12AM +, Aric Cyr wrote: > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get > crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d > everything works fine, but then wined3d is still dependent on glx. The answer is easy (did not read the complete thread in details to know if you found out the solution or not): basically, 'wglGetProcAddress' returns functions as expected by Win32 applications, so using the 'stdcall' calling convention whereas 'glXGetProcAddress' returns them in the standard Unix calling convention 'cdecl'. So you basically have the same problem with GL extensions that you had with direct linking to OpenGL32.DLL instead of to libGL.so => all the calls going through function pointers that you retrieved via 'wglGetProcAddress' will go through thunks to change the calling convention (at the price of a slight performance hit). Moreover, you will have a nice 'header' head-ache as you won't be able to rely on the Linux distribution's version of 'glext.h' but on a version compatible with Windows that adds the proper 'STDCALL' types to the function pointer prototypes. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr wrote: Now everything works fine, except this brings up another issue with wglGetProcAddress. The problem is that all gl extensions function pointers are declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is expected to return. However for extensions that are not registered in opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would return a non-WINAPI function pointer. After the first call to such a function we would have corrupted the stack. There doesn't seem to be a nice way to fix this that I can think of. wglGetProcAddress should never return a non-WINAPI function though, as that is just asking for trouble. Better to return NULL instead of falling back to glXGetProcAddressARB. Maybe it'd be possible to make a wrapper function -- a WINAPI function pointer that just does a call to this glXGetProcAddressARB ? (Just me thinking aloud ;-) )
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Sat, 2005-12-17 at 07:07 +, Aric Cyr wrote: > > Thanks for the suggestion, but I already have wine compiled with only "-g". > Last time I checked gcc doesn't enable optimizations unless a -O option is > specified explicitly (don't know if this has changed though). > > Anyways, I think I finally figured this all out. As I thought it turned out > to > be stack corruption, due to differing calling conventions. It just required > fixing up my function pointers to be WINAPI (which I believe becomes stdcall) > for all the wgl functions. I think you're right IIRC. I think all win32 calls are stdcall (or sometimes pascal, which is more or less the same thing I think, where the function cleans up the stack and not the caller, as opposed to cdecl, where the opposite happens) Calling conventions are a lot of fun, aren't they? :) > > Now everything works fine, except this brings up another issue with > wglGetProcAddress. The problem is that all gl extensions function pointers > are > declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is > expected to return. However for extensions that are not registered in > opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would > return a non-WINAPI function pointer. After the first call to such a function > we would have corrupted the stack. There doesn't seem to be a nice way to fix > this that I can think of. wglGetProcAddress should never return a non-WINAPI > function though, as that is just asking for trouble. Better to return NULL > instead of falling back to glXGetProcAddressARB. I agree here as well. The whole idea here is to avoid glx and use the WGL layer to abstract it, right? It would be a really bad idea to trust glXGetProcAddressARB because you can't really know for sure if the calling convention is right, and that issue becomes a problem with any shared library on any platform, precisely because of the problems you were experiencing with the stack. > > As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d > are now passed through the thunks. It is only one extra function call so the > impact should be minimal (too bad we can't inline these!), but I thought I > should mention it anyways. Good work! ;-) > > After cleaning up everything I've worked on I think I'll start submitting > patches. First some pre-requisite patches for dlls/opengl32 and include/ and > then the changes for dlls/wined3d. All together it is quite a large change, > but > I should be able to break it up into manageable pieces (hopefully!). Great! I'd really like to see this kind of thing come to fruition. I think it would be especially good to see wined3d run on windows for testing purposes. > > Regards, > Aric > > >
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On 12/17/05, Segin <[EMAIL PROTECTED]> wrote: > Aric Cyr wrote: > James Liggett cox.net> writes: > > > > Hi Aric, > If you see stack corruption like this, you might want to try compiling > with optimization turned off. put the -O0 (a capital letter O followed > by a zero) flag in your CFLAGS when you run configure. I had a similar > situation where gcc was using fuzzy math when working with structures, > and turning off optimization helped. > > Thanks for the suggestion, but I already have wine compiled with only "-g". > Last time I checked gcc doesn't enable optimizations unless a -O option is > specified explicitly (don't know if this has changed though). > > > Wine uses -O2 by default even if you don't tell it to optimize. -Os will > product buggy code, and -mfpmath=sse,387 (yes only when you ask for BOTH sse > and 387) will problems occur (big one at that) > If you run configure with no other options "-g -O2" is default, however I run it as "CFLAGS=-g CXXFLAGS=-g ./configure"... so I'm positive (verified by make output) that there is no -O2 or any other options besides -g anywhere. Anyways it turned out not to be a compiler bug, so this is not too important now, but thanks for the suggestions. - Aric -- Aric Cyr (http://acyr.net)
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr wrote: James Liggett cox.net> writes: Hi Aric, If you see stack corruption like this, you might want to try compiling with optimization turned off. put the -O0 (a capital letter O followed by a zero) flag in your CFLAGS when you run configure. I had a similar situation where gcc was using fuzzy math when working with structures, and turning off optimization helped. Thanks for the suggestion, but I already have wine compiled with only "-g". Last time I checked gcc doesn't enable optimizations unless a -O option is specified explicitly (don't know if this has changed though). Anyways, I think I finally figured this all out. As I thought it turned out to be stack corruption, due to differing calling conventions. It just required fixing up my function pointers to be WINAPI (which I believe becomes stdcall) for all the wgl functions. Now everything works fine, except this brings up another issue with wglGetProcAddress. The problem is that all gl extensions function pointers are declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is expected to return. However for extensions that are not registered in opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would return a non-WINAPI function pointer. After the first call to such a function we would have corrupted the stack. There doesn't seem to be a nice way to fix this that I can think of. wglGetProcAddress should never return a non-WINAPI function though, as that is just asking for trouble. Better to return NULL instead of falling back to glXGetProcAddressARB. As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d are now passed through the thunks. It is only one extra function call so the impact should be minimal (too bad we can't inline these!), but I thought I should mention it anyways. After cleaning up everything I've worked on I think I'll start submitting patches. First some pre-requisite patches for dlls/opengl32 and include/ and then the changes for dlls/wined3d. All together it is quite a large change, but I should be able to break it up into manageable pieces (hopefully!). Regards, Aric Wine uses -O2 by default even if you don't tell it to optimize. -Os will product buggy code, and -mfpmath=sse,387 (yes only when you ask for BOTH sse and 387) will problems occur (big one at that)
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
James Liggett cox.net> writes: > Hi Aric, > If you see stack corruption like this, you might want to try compiling > with optimization turned off. put the -O0 (a capital letter O followed > by a zero) flag in your CFLAGS when you run configure. I had a similar > situation where gcc was using fuzzy math when working with structures, > and turning off optimization helped. Thanks for the suggestion, but I already have wine compiled with only "-g". Last time I checked gcc doesn't enable optimizations unless a -O option is specified explicitly (don't know if this has changed though). Anyways, I think I finally figured this all out. As I thought it turned out to be stack corruption, due to differing calling conventions. It just required fixing up my function pointers to be WINAPI (which I believe becomes stdcall) for all the wgl functions. Now everything works fine, except this brings up another issue with wglGetProcAddress. The problem is that all gl extensions function pointers are declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is expected to return. However for extensions that are not registered in opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would return a non-WINAPI function pointer. After the first call to such a function we would have corrupted the stack. There doesn't seem to be a nice way to fix this that I can think of. wglGetProcAddress should never return a non-WINAPI function though, as that is just asking for trouble. Better to return NULL instead of falling back to glXGetProcAddressARB. As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d are now passed through the thunks. It is only one extra function call so the impact should be minimal (too bad we can't inline these!), but I thought I should mention it anyways. After cleaning up everything I've worked on I think I'll start submitting patches. First some pre-requisite patches for dlls/opengl32 and include/ and then the changes for dlls/wined3d. All together it is quite a large change, but I should be able to break it up into manageable pieces (hopefully!). Regards, Aric
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Fri, 2005-12-16 at 02:08 +, Aric Cyr wrote:
> Aric Cyr gmail.com> writes:
>
> >
> > I debugged it more last night and I found the offending call. If I comment
> > out
> > just that one (probably unneeded from what I can tell) function everything
> > works
> > great.
>
> Replying to myself again...
>
> Okay so I think this whole problem might turn out to be a compiler bug. I
> reverted all changes to drawprim.c I made to track down this bug, then I
> tried a
> something different. Since I was crashing in glDrawArrays() I was thinking
> that
> the vertex array or normal array was not properly set for some reason. Out of
> the 4 demos I test with, one of them is unaffected by my bug, and running with
> WINEDEBUG=d3d_draw I can see that the glDrawArrays path is not taken. So that
> narrowed the problem down to the glDrawArrays code path for me. In checking
> the
> glVertexPointer function call I changed the VTRACE message from
>
> /* Note dwType == float3 or float4 == 2 or 3 */
> VTRACE(("glVertexPointer(%ld, GL_FLOAT, %ld, %p)\n",
> sd->u.s.position.dwStride,
> sd->u.s.position.dwType + 1,
> sd->u.s.position.lpData));
>
> to
>
> /* Note dwType == float3 or float4 == 2 or 3 */
> VTRACE(("glVertexPointer(%u, %u, %ld, %p)\n",
> WINED3D_ATR_SIZE(position),
> WINED3D_ATR_GLTYPE(position),
> sd->u.s.position.dwStride,
> sd->u.s.position.lpData));
>
> After making this change everything started working... this is silly though
> since VTRACE is just a macro around TRACE(). So either there is stack
> corruption somewhere or the compiler is wonky. Since it is gcc-4.0.2 I'm
> guessing the compiler is buggy (Ubuntu breezy's standard gcc is 4.0.2 now).
> I'll try recompiling with gcc-3.3 later and see if the original code is
> working.
>
> Still interested in any comments though :)
>
>
>
Hi Aric,
If you see stack corruption like this, you might want to try compiling
with optimization turned off. put the -O0 (a capital letter O followed
by a zero) flag in your CFLAGS when you run configure. I had a similar
situation where gcc was using fuzzy math when working with structures,
and turning off optimization helped.
James
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr gmail.com> writes:
>
> I debugged it more last night and I found the offending call. If I comment
> out
> just that one (probably unneeded from what I can tell) function everything
> works
> great.
Replying to myself again...
Okay so I think this whole problem might turn out to be a compiler bug. I
reverted all changes to drawprim.c I made to track down this bug, then I tried a
something different. Since I was crashing in glDrawArrays() I was thinking that
the vertex array or normal array was not properly set for some reason. Out of
the 4 demos I test with, one of them is unaffected by my bug, and running with
WINEDEBUG=d3d_draw I can see that the glDrawArrays path is not taken. So that
narrowed the problem down to the glDrawArrays code path for me. In checking the
glVertexPointer function call I changed the VTRACE message from
/* Note dwType == float3 or float4 == 2 or 3 */
VTRACE(("glVertexPointer(%ld, GL_FLOAT, %ld, %p)\n",
sd->u.s.position.dwStride,
sd->u.s.position.dwType + 1,
sd->u.s.position.lpData));
to
/* Note dwType == float3 or float4 == 2 or 3 */
VTRACE(("glVertexPointer(%u, %u, %ld, %p)\n",
WINED3D_ATR_SIZE(position),
WINED3D_ATR_GLTYPE(position),
sd->u.s.position.dwStride,
sd->u.s.position.lpData));
After making this change everything started working... this is silly though
since VTRACE is just a macro around TRACE(). So either there is stack
corruption somewhere or the compiler is wonky. Since it is gcc-4.0.2 I'm
guessing the compiler is buggy (Ubuntu breezy's standard gcc is 4.0.2 now).
I'll try recompiling with gcc-3.3 later and see if the original code is working.
Still interested in any comments though :)
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr gmail.com> writes:
>
> Raphael club-internet.fr> writes:
>
> >
> > On Wednesday 14 December 2005 04:53, Aric Cyr wrote:
> > > 1) should the thunks returned from wglGetProcAddress be causing crashes at
> > > all? Note that they don't crash right away, but "eventually" usually
> > > during
> > > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT).
> >
> > The real problem here is "why it crash ?"
> > It shouldn't as wine gl* calls are only "decorators" calls
> > Maybe we have a declaration error...
>
> Yes that was what I was thinking as well. I haven't looked into it very much
> yet, but I'll double check the definitions, although since opengl_ext.c is
> autogenerated I can't imagine why there would be a problem (unless
> include/wine/wined3d_gl.h has the wrong definitions... I'll have to check that
> out)
>
> Also I'm not sure if calling conventions matter, or what is the correct way to
> define a function. I'm referring to the WINAPI vs APIENTRY (vs stdcall?)
> function pointer prefixes. Any pointers (no pun intended) in this area would
> be much appreciated.
>
> > Can you provide more informations:
> > - WINEDEBUG=+opengl log + winedbg crash log
I debugged it more last night and I found the offending call. If I comment out
just that one (probably unneeded from what I can tell) function everything works
great.
The code is in dlls/wined3d/drawprim.c (about halfway down):
if (GL_SUPPORT(EXT_SECONDARY_COLOR)) {
glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT);
checkGLcall("glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)");
GL_EXTCALL(glSecondaryColor3fEXT)(0, 0, 0);
checkGLcall("glSecondaryColor3fEXT(0, 0, 0)");
} else {
/* Missing specular color is not critical, no warnings */
VTRACE(("Specular colour is not supported in this GL
implementation\n"));
}
If I comment out the GL_EXTCALL(glSecondaryColor3fEXT)(0,0,0); line everything
works perfectly (well, the four dx9 demos I have been using). I tried debugging
it (put a breakpoint in wine_glSecondaryColor3fEXT) but the function seems to
work fine. It is only after this function is called, followed shortly by
glDrawArrays() that the actual segfault occurs (inside glDrawArrays there is a
NULL dereference it seems). I would blame ATI's drivers but as I said using
glXGetProcAddress instead of wglGetProcAddress works without commenting this
line.
The only other thing I can think of is that the calling conventions are messed
up somehow, either due to mismatched function declarations (which I thoroughly
checked, but still could have missed something...) or some weird wine thing I
don't understand.
Also other GL_EXTCALL functions were not affected. For example,
glPointParameter...EXT() calls are frequently made and don't seem to cause any
problems at all.
Any help or tips would be much appreciated, as I am running out of things to try
and debug.
- Aric
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Raphael club-internet.fr> writes: > > On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > > all? Note that they don't crash right away, but "eventually" usually during > > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). > > The real problem here is "why it crash ?" > It shouldn't as wine gl* calls are only "decorators" calls > Maybe we have a declaration error... Yes that was what I was thinking as well. I haven't looked into it very much yet, but I'll double check the definitions, although since opengl_ext.c is autogenerated I can't imagine why there would be a problem (unless include/wine/wined3d_gl.h has the wrong definitions... I'll have to check that out) Also I'm not sure if calling conventions matter, or what is the correct way to define a function. I'm referring to the WINAPI vs APIENTRY (vs stdcall?) function pointer prefixes. Any pointers (no pun intended) in this area would be much appreciated. > Can you provide more informations: > - WINEDEBUG=+opengl log + winedbg crash log Will do when I get home tonight, but there wasn't any useful info in there. I went through it many times. Also wine doesn't cleanly crash (if there is such a thing), instead it hangs on the backtrace and all I see is the first bt entry like: 1) memcpy I can kill it with a ctrl-c just fine though. > > 2) what is the reason for wglGetProcAddress to check opengl32.dll before > >libGL.so? Would the reverse logic still be a resonable solution? > > No Ya kinda didn't think so :) Thanks, Aric
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > Hello all, Hi, > As I mentinoed in a recent post, I have almost completed the GLX->WGL > conversion. Last night I tracked down my last bug that was causing most of > my demo apps to fail. > > It seems that the problem was the conversion from glXGetProcAddress to > using wglGetProcAddress. wined3d uses glXGetProcAddress to get the OpenGL > extension function pointers, which is what wglGetProcAddress also does. > However wglGetProcAddress _first_ checks opengl32.dll for the extension and > returns the thunk function pointer if it exists, and only then falls back > to libGL.so by calling glXGetProcAddress. > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I > get crashes in most D3D9 applications. If I use glXGetProcAddress in > wined3d everything works fine, but then wined3d is still dependent on glx. > > So my questions: > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > all? Note that they don't crash right away, but "eventually" usually during > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). The real problem here is "why it crash ?" It shouldn't as wine gl* calls are only "decorators" calls Maybe we have a declaration error... Can you provide more informations: - WINEDEBUG=+opengl log + winedbg crash log > 2) what is the reason for wglGetProcAddress to check opengl32.dll before >libGL.so? Would the reverse logic still be a resonable solution? No > Regards, > Aric Regards, Raphael pgpGDEQLxHLaE.pgp Description: PGP signature
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Stefan Dösinger wrote: Am Freitag, 25. November 2005 18:00 schrieb Jakob Eriksson: Aric Cyr wrote: All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time. ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers. So, I don't think that they would benefit much. They would, but they don't know it. :-) It's quite conceivable for ReactOS to run on hardware where there is OpenGL support, but no vendor DirectX drivers. regards, Jakob
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > If wines WGL implementation is fully implemented then it may be a good idea > > switching to wgl, a wgl implemenatation would also make debugging much > > easier because wined3d can be run under windows to isolate problems. > Wasn't there also the idea of running WineD3D in Vista to allow the new 3D > Desktop to run with full OpenGL support? I think Oliver mentioned this > somewhere. So long as the dll doesn't need to be signed (or we can find someone to sign it!) that's still a possiblity. Oliver > Stefan > > > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
> >All in all I think it would be worth while, but I'd still like to hear > > from others so as not to waste (a lot!) of my time. > > ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers. So, I don't think that they would benefit much.
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Am Freitag, 25. November 2005 18:00 schrieb Jakob Eriksson: > Aric Cyr wrote: > >All in all I think it would be worth while, but I'd still like to hear > > from others so as not to waste (a lot!) of my time. > > ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers. So, I don't think that they would benefit much.
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr wrote: All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time. ReactOS would benefit as well from your approach. regards, Jakob
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
> If wines WGL implementation is fully implemented then it may be a good idea > switching to wgl, a wgl implemenatation would also make debugging much > easier because wined3d can be run under windows to isolate problems. Wasn't there also the idea of running WineD3D in Vista to allow the new 3D Desktop to run with full OpenGL support? I think Oliver mentioned this somewhere. Stefan
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On 11/25/05, Oliver Stieber <[EMAIL PROTECTED]> wrote: > > --- Aric Cyr <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > A while back I had started to work on, and mostly completed, converting > > wined3d > > to using WGL instead of directly accessing glX functions. That was a few > > months > > ago, and it was a pretty big change, but not too difficult as WGL and GLX > > are > > very similar. > > > > However, my patch is now greatly out of date thanks to the excellent work > > progressing in wined3d. I was just interested in getting some feedback on > > whether anyone thinks this is something worth me continuing to pursue, or > > just > > drop it? > > > > As I see it, there are a few merits to having wined3d on wgl instead of glx. > > The biggest one being that all the glX code won't be duplicated in multiple > > places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes > > maintainability and consistency as all glX code would only exist in one > > place > > and would be shared by all, applications and wined3d alike. Work-arounds > > for the > > various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be > > localized to a single dll. > > > > Of course, on the down side, we take a hit of one extra layer of > > indirection by > > going through WGL. However as WGL/glX functions are rarely called, this > > should > > be a minimal of a performance hit. > > > > All in all I think it would be worth while, but I'd still like to hear from > > others so as not to waste (a lot!) of my time. > > If wines WGL implementation is fully implemented then it may be a good idea > switching to wgl, a > wgl implemenatation would also make debugging much easier because wined3d can > be run under windows > to isolate problems. Wine's WGL is well implemented, and probably more correct than what is in wined3d currently (well, last time I checked anyways). > Nick Burns also started work on a wgl version of wined3d that I haven't got > around to fully > merging yet, I can send you the patch. Sure send me the patch (off list is fine). I was planning on restarting from scratch anyways, so I'd like to see what Nick had in mind and build on it. Regards, Aric -- Aric Cyr (http://acyr.net)
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
--- Aric Cyr <[EMAIL PROTECTED]> wrote: > Hi all, > > A while back I had started to work on, and mostly completed, converting > wined3d > to using WGL instead of directly accessing glX functions. That was a few > months > ago, and it was a pretty big change, but not too difficult as WGL and GLX are > very similar. > > However, my patch is now greatly out of date thanks to the excellent work > progressing in wined3d. I was just interested in getting some feedback on > whether anyone thinks this is something worth me continuing to pursue, or just > drop it? > As I see it, there are a few merits to having wined3d on wgl instead of glx. > The biggest one being that all the glX code won't be duplicated in multiple > places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes > maintainability and consistency as all glX code would only exist in one place > and would be shared by all, applications and wined3d alike. Work-arounds for > the > various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be > localized to a single dll. > > Of course, on the down side, we take a hit of one extra layer of indirection > by > going through WGL. However as WGL/glX functions are rarely called, this > should > be a minimal of a performance hit. > > All in all I think it would be worth while, but I'd still like to hear from > others so as not to waste (a lot!) of my time. If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems. Nick Burns also started work on a wgl version of wined3d that I haven't got around to fully merging yet, I can send you the patch. Oliver. > Regards, > Aric > > > > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
