Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote: On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 25/05/14 21:35, Jordan Justen wrote: On Sat, May 24, 2014 at 12:28 PM, Emil Velikov emil.l.veli...@gmail.com wrote: * Library dependencies, etc. (low priority) libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency, ship them in the zip or leave it to the user/dev ? Library: libgcc_s __emutls_get_address __udivdi3 __umoddi3 Options: - Static link libgcc_s, generally not bad idea sigh, a bit of a typo here - the above should read: - Static link libgcc_s - generally _a bad_ idea Doesn't gcc/binutils automatically do this when you compile/link? What are the licensing implications? That's possibly the main reason why I'm inclined to go with rework. I've never been good at the legal/licensing terms. I think libgcc would be covered by this exception, right? https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389 If so, it seems like static linking might not be a problem. IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no gpl-incompatible software is used during the Compilation Process, thus we are Eligible. It sounds they only mean to prevent non-GPL compatible code from getting into the internals of the GCC complication process. So, in other words, you can't have a proprietary GCC plugin, and also use the exception to link to libgcc, etc. But, it seems like even proprietary code could use the exception to link to libgcc as long as it was just being compiled by GCC. - or, rework waffle ? Split merged_version or move to (major 8 | minor) for the wcore_config_attrs_version_* helpers - will nuke the last two. No idea how to nuke __emutls_get_address. Suggestion: Split to separate major/minor. Library: libwinpthread-1 pthread_key_create pthread_mutex_lock pthread_mutex_unlock pthread_once pthread_setspecific Options: - Static link What are the licensing implications? It doesn't look as good as the libgcc case. The library is a combination of X/MIT and 3-clause BSD. Which afaics is rather vague on the topic of static linking the library and distribution of the final binary(ies). My guess is that we ought to be safe but IANAL. This wasn't my concern. I was concerned the library might have been GPL licensed, and thus the waffle DLL wouldn't be usable with a proprietary application. Chad, would you be okay with releasing the windows waffle DLL and noting that it is partially covered by X/MIT, 3-clause BSD and 2-clause BSD? If Waffle needs a stacked license to support Win32, that's ok with me. Liberal licenses in the BSD, MIT, and Apache family are all acceptable. I am not a lawyer either, so I do not know if statically linking the parts you speak of are safe to do so. I think you should make your initial decision based on its technical merits. Then, after the technical, decision is made but before you've invested too much time in it, all of us (you, Jordan, me, Jose) should analyze any license issues. FWIW, I prefer to avoid runtime dependency hell by statically linking small, problematic components. But my opinion is of limited value here, because I'm unfamiliar with the problem domain of mingw and MSVC. FWIW, my opinion is that we shouldn't get too distracted by licensing and what release binaries should look like. It is not something that needs to be decided now, or ever: ultimately, that decision can be pushed to the final user. They might prefer mingw, they might prefer msvc for easy of debugging, or because they want to statically link, etc. IMHO the most important is getting waffle to build and run on Windows on some form. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - On 31/05/14 19:59, Jose Fonseca wrote: - Original Message - On 24/05/14 20:28, Emil Velikov wrote: [snip] AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it allows the PixelFormat to be called prior to the creation of either window or context. Options: - Create a window, choose format, destroy window. No guarantee that the function will behave the same for another window/device_context. In practice, the odds of this happening are very low. I'd recommend creating an invisible window, do your things then, keep the window around, and then merely double check later that things are not busted. Still not sure which one of the two you are recommending: Create a invisible(dummy) window initially and create a new one at wfl_window_create. or This one. But I'm not 100% what is the best way. Whatever works really. Jose Create a invisible(dummy) window initially and bring it up/use it at wfl_window_create/wfl_window_show. ? Pardon if the above question sound rather dull :) Thanks Emil You can see in https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=EVvdAN6DpAMPSYORbM%2BCu4MTEMmLt5L7XFRXd%2Be9PvI%3D%0As=7d4dab293ed0b1192ad5e333f73785f2aa7efedbd4ea4ec656a41ff96078d8c3 how to create an invisible window (This is how Mesa implements pbuffers on Windows!.) Jose - or, create window, choose format, reuse window on waffle_window_create() Sanest solution. If windows is not created just make one (i.e. waffle_config_choose is not executed before waffle_window_create). - or, store the attributes, and invoke ChoosePixelFormat as waffle_window_create is executed. What if code-flow depends on waffle_config_choose's return value ? - or rework waffle API ... (no, please no) Suggestion: Cache the window, and reuse it on waffle_window_create. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message -
On 02/06/14 19:55, Chad Versace wrote:
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as
well.
The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either
window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
If I understand things correctly surface(egl)/drawable(glx) are not as
clearly
separated in wgl. At least not initially.
Redesign of Waffle's API sounds like an overkill imho, as the only thing we
need is an easier way get from context/config data to window. Otherwise
wcore_(context|config|window) will be dummies and everything will be stored
in
a wcore_display wrapper (wgl_display).
Perhaps the following rough flow illustrates things a bit better
Abstracting across many platforms is always complicated, and even more if we
can't run tests on all of them. So even if we end up redesigning, it might be
better to first get windows to work (even if that requires a few
hacks/assumptions) first, so we can run tests/examples.
glx (in the following example window is optional)
display glx create_context window gl*
wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
window create_context wgl/gl
Currently I shove everything in wgl_display, although a slightly cleaner
approach might be better.
-Emil
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On 04/06/14 21:18, Jose Fonseca wrote: - Original Message - On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote: On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 25/05/14 21:35, Jordan Justen wrote: On Sat, May 24, 2014 at 12:28 PM, Emil Velikov emil.l.veli...@gmail.com wrote: * Library dependencies, etc. (low priority) libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency, ship them in the zip or leave it to the user/dev ? Library: libgcc_s __emutls_get_address __udivdi3 __umoddi3 Options: - Static link libgcc_s, generally not bad idea sigh, a bit of a typo here - the above should read: - Static link libgcc_s - generally _a bad_ idea Doesn't gcc/binutils automatically do this when you compile/link? What are the licensing implications? That's possibly the main reason why I'm inclined to go with rework. I've never been good at the legal/licensing terms. I think libgcc would be covered by this exception, right? https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389 If so, it seems like static linking might not be a problem. IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no gpl-incompatible software is used during the Compilation Process, thus we are Eligible. It sounds they only mean to prevent non-GPL compatible code from getting into the internals of the GCC complication process. So, in other words, you can't have a proprietary GCC plugin, and also use the exception to link to libgcc, etc. But, it seems like even proprietary code could use the exception to link to libgcc as long as it was just being compiled by GCC. - or, rework waffle ? Split merged_version or move to (major 8 | minor) for the wcore_config_attrs_version_* helpers - will nuke the last two. No idea how to nuke __emutls_get_address. Suggestion: Split to separate major/minor. Library: libwinpthread-1 pthread_key_create pthread_mutex_lock pthread_mutex_unlock pthread_once pthread_setspecific Options: - Static link What are the licensing implications? It doesn't look as good as the libgcc case. The library is a combination of X/MIT and 3-clause BSD. Which afaics is rather vague on the topic of static linking the library and distribution of the final binary(ies). My guess is that we ought to be safe but IANAL. This wasn't my concern. I was concerned the library might have been GPL licensed, and thus the waffle DLL wouldn't be usable with a proprietary application. Chad, would you be okay with releasing the windows waffle DLL and noting that it is partially covered by X/MIT, 3-clause BSD and 2-clause BSD? If Waffle needs a stacked license to support Win32, that's ok with me. Liberal licenses in the BSD, MIT, and Apache family are all acceptable. I am not a lawyer either, so I do not know if statically linking the parts you speak of are safe to do so. I think you should make your initial decision based on its technical merits. Then, after the technical, decision is made but before you've invested too much time in it, all of us (you, Jordan, me, Jose) should analyze any license issues. FWIW, I prefer to avoid runtime dependency hell by statically linking small, problematic components. But my opinion is of limited value here, because I'm unfamiliar with the problem domain of mingw and MSVC. FWIW, my opinion is that we shouldn't get too distracted by licensing and what release binaries should look like. It is not something that needs to be decided now, or ever: ultimately, that decision can be pushed to the final user. They might prefer mingw, they might prefer msvc for easy of debugging, or because they want to statically link, etc. IMHO the most important is getting waffle to build and run on Windows on some form. Fair enough. Curious why did this get so much attention, perhaps the option leave it to the user/dev was not clear enough in my original email. -Emil Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote: On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 25/05/14 21:35, Jordan Justen wrote: On Sat, May 24, 2014 at 12:28 PM, Emil Velikov emil.l.veli...@gmail.com wrote: * Library dependencies, etc. (low priority) libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency, ship them in the zip or leave it to the user/dev ? Library: libgcc_s __emutls_get_address __udivdi3 __umoddi3 Options: - Static link libgcc_s, generally not bad idea sigh, a bit of a typo here - the above should read: - Static link libgcc_s - generally _a bad_ idea Doesn't gcc/binutils automatically do this when you compile/link? What are the licensing implications? That's possibly the main reason why I'm inclined to go with rework. I've never been good at the legal/licensing terms. I think libgcc would be covered by this exception, right? https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389 If so, it seems like static linking might not be a problem. IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no gpl-incompatible software is used during the Compilation Process, thus we are Eligible. It sounds they only mean to prevent non-GPL compatible code from getting into the internals of the GCC complication process. So, in other words, you can't have a proprietary GCC plugin, and also use the exception to link to libgcc, etc. But, it seems like even proprietary code could use the exception to link to libgcc as long as it was just being compiled by GCC. - or, rework waffle ? Split merged_version or move to (major 8 | minor) for the wcore_config_attrs_version_* helpers - will nuke the last two. No idea how to nuke __emutls_get_address. Suggestion: Split to separate major/minor. Library: libwinpthread-1 pthread_key_create pthread_mutex_lock pthread_mutex_unlock pthread_once pthread_setspecific Options: - Static link What are the licensing implications? It doesn't look as good as the libgcc case. The library is a combination of X/MIT and 3-clause BSD. Which afaics is rather vague on the topic of static linking the library and distribution of the final binary(ies). My guess is that we ought to be safe but IANAL. This wasn't my concern. I was concerned the library might have been GPL licensed, and thus the waffle DLL wouldn't be usable with a proprietary application. Chad, would you be okay with releasing the windows waffle DLL and noting that it is partially covered by X/MIT, 3-clause BSD and 2-clause BSD? If Waffle needs a stacked license to support Win32, that's ok with me. Liberal licenses in the BSD, MIT, and Apache family are all acceptable. I am not a lawyer either, so I do not know if statically linking the parts you speak of are safe to do so. I think you should make your initial decision based on its technical merits. Then, after the technical, decision is made but before you've invested too much time in it, all of us (you, Jordan, me, Jose) should analyze any license issues. FWIW, I prefer to avoid runtime dependency hell by statically linking small, problematic components. But my opinion is of limited value here, because I'm unfamiliar with the problem domain of mingw and MSVC. FWIW, my opinion is that we shouldn't get too distracted by licensing and what release binaries should look like. It is not something that needs to be decided now, or ever: ultimately, that decision can be pushed to the final user. They might prefer mingw, they might prefer msvc for easy of debugging, or because they want to statically link, etc. I thought we wanted to go ahead an provide a binary build for windows, and thus: 1. It should be buildable under Linux using mingw 2. The binary should have a reasonable license situation Didn't we already pretty much have this worked out anyhow? IMHO the most important is getting waffle to build and run on Windows on some form. Sure, if using mingw is holding Emil back, but I don't think it is. Right? -Jordan ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [GSOC2014] Current design/implementation + the infamous corruption
Hi all, Over the last few days I have been though some head-scratching and re-writing things, in order to resolve an interesting memory corruption to no avail :'( Before explaining more about the issue here is some info about the current design + where to get the patches. Let me know if you would like me to send them to the ML. Branch GSOC2014 over at https://github.com/evelikov/waffle Archlinux users can use the pkgbuild script in pkg/archlinux/mingw-w64-waffle. Design by example - gl_sample.c (i.e. how to use waffle) waffle_init() waffle_display_connect() + RegisterClass()// Registers the window class used as a template // by Windows to create the window waffle_config_choose(dpy...) + CreateWindow() // Create a window and prepend it to the // wgl_display::windows list. + ChoosePixelFormat() + SetPixelFormat() // Set the pixelformat and link the current window // to the wgl_config waffle_context_create(config...) + CreateContext(hDC... ) // At this point we need access to the wgl_window, // as hWnd/hDC (window_handle/device_context handle) // is essential. // This is where wgl_config::window comes into play. waffle_window_create(config, w, h) + wgl_window_resize()// Reuse the window, adjusting it's dimensions, as // w, h used at creation time are include the window // border. AFAICK there is no way to determine the // correct window dimensions prior to creation. ... waffle_window_create(config, w, h) + waffle_window_resize() // Reuse the window... and boom. Any suggestions on // how to resolve this, or should we mandate that // this is not a valid usage of waffle ? And now back to the memory corruption: When compiling the branch and running the gl_example demo, the resize, colors and possibly other variables gets (async) modified whenever gl calls are executed. gl_basic.exe --platform=wgl --api=gl DEBUG: draw:395 resize 0 DEBUG: draw:397 resize 0 DEBUG: draw:407 resize 0 DEBUG: draw:419 resize 0 DEBUG: draw:421 colors 9e90048 size 307200 DEBUG: draw:429 colors 9e90048 glReadPixels returned unexpected result DEBUG: draw:436 resize 0 DEBUG: draw:444 resize 0 DEBUG: draw:450 resize 0 DEBUG: draw:454 resize 0 DEBUG: draw:456 resize 0 DEBUG: draw:397 resize 0 DEBUG: draw:407 resize 0 DEBUG: draw:411 resize 151 Interesting DEBUG: draw:413 resize 120 ... DEBUG: draw:419 resize 216 ... DEBUG: draw:421 colors 9e90048 size 57600 DEBUG: draw:429 colors 411859 ... glReadPixels returned unexpected result DEBUG: draw:436 resize 3 DEBUG: draw:450 resize 255 gl_basic: error: WAFFLE_NO_ERROR The values that resize is set to are obviously related to the rgba arguments of glClearColor. Omitting calls results in a seemingly ok execution. Any suggestions as to what I'm doing wrong and/or what may be causing this corruption are greatly appreciated. Many thanks Emil ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
