Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - 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? Maybe I misinterpreted things. I always saw mingw as a mean to an end, to facilitate development and get things started (ie, without forcing Emil to obtain and learn to use use a completely new set of tools). And not the end itself (distribute
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- Original Message - - Original Message - 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? Maybe I misinterpreted things. I always saw mingw as a mean to an
Re: [waffle] [GSOC2014] Current design/implementation + the infamous corruption
On 05/06/14 03:19, Emil Velikov wrote:
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
// Create a default/root window, config and context
// as wglGetProcAddress needs to be executed under
// current context.
Missed case:
waffle_get_proc_address() // if (wglGetCurrentContext() == NULL) {
// using_display_context = true;
// wglMakeCurrent(display-hdc, display-hglrc)
// }
// ok = wglGetProcAddress()
// if (using_display_context == true)
// wglMakeCurrent(NULL, NULL)
// return ok;
// Unbinding the current context may be an
// overkill although will help with unintentional
// misuse of waffle's API.
// NOTE: Will need to change waffle's internals
// in order to get access to wcore_display.
// The API will need a change to include the
// display waffle_get_proc_address(dpy, glHam)
waffle_config_choose(dpy...)
+ CreateWindow() // Create a window and prepend it to the
// wgl_display::windows list.
Now that I look at it, I'm not entirely sure why I needed a list of all
windows in wgl_display. Seems like I can drop that.
+ 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 ?
There is no use case in piglit + waffle{examples/utils} where one would create
multiple windows for a single config. I might just add a lovely assert and
don't worry about this too much.
With the above resolved I will take a look at handling gl profiles and alike.
And now back to the memory corruption:
Resolved, thanks to Jon Turney.
The functions obtained by waffle_dl_sym() are part of the Windows API, which
uses different calling convention (stdcall vs cdecl) which causes the heap
corruption. Annotating properly makes the gl_basic test work like a charm.
AFAICS waffle_get_proc_address is in the same boat. Will need to test.
Cheers,
Emil
___
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 04, 2014 at 11:47:32PM -0700, Jose Fonseca wrote: 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? Maybe I misinterpreted things. I always saw mingw as a mean to an end, to facilitate development and get things started (ie, without forcing Emil to obtain and learn to use use a completely new set of tools). And not the end itself (distribute binaries to the world), because: - MinGW often generates bad code, I've seen it happening with Mesa and Apitrace [1]; so I while use MinGW debug binaries all the time, I don't trust MinGW to produce distributable release binaries - MinGW debug information is not understood by MSVC tools, so when an MSVC user debugs its code, it won't be able to get any symbols from waffle if waffle was build with MinGW IMHO, the best sort of binaries are .DLLs produced by MSVC (any version) with statically linked CRT (so no additional dependencies -- no need to ship MSVC redistributables installer). And they should be usable with applications built with anything (MSVC MinGW) Anyway, this is just a mere suggestion. I can always build my own binaries from source if needed. Jose, I had the same interpretation as you. Despite being useful for development, mingw was a mean to an end. ___ 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 04, 2014 at 01:24:38PM -0700, Jose Fonseca wrote:
- 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.
I totally agree. Let's focus on getting Windows working with the current
API, even if it requires imperfect hacks.
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.
This makes sense to me.
From my uninformed perspective, it seems that shoving the Win32
window/display/device/whatever into wgl_display is the best approach.
But you and Jose likely know better than me. Whatever you need to do to
get it to work.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 01/10] pkg/archlinux: Update to a dual (+multilib) package
On Sat, May 31, 2014 at 03:21:59AM +0100, Emil Velikov wrote: Include both 64bit and multilib binaries when building on x86-64 platform. This saves us deeping track of version numbers and interdependencies in case of a split package. v2: Rebase and bump pkgrel Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- pkg/archlinux/waffle-1.3.0/PKGBUILD | 86 +++-- 1 file changed, 73 insertions(+), 13 deletions(-) The x86_64 package shouldn't depend on lib32 packages. Not everyone needs or wants to enable the multilib repo, and waffle shouldn't force them to do that. If you're concerned about the lib32-waffle PKGBUILD drifting out-of-sync with the base waffle PKGBUILD, maybe you could cleverly use the bash 'source' directive and string substitution. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 02/10] cmake: reformat/update install targets
On Sat, May 31, 2014 at 03:22:00AM +0100, Emil Velikov wrote: Cleanup the formatting and add component for each build target. The latter will allow us to use CPack to create a component based installer for Windows. Additionally install wflinfo to CMAKE_INSTALL_BINDIR rather than hardcoding it to 'bin'. v2: Tag html documentation as htmldocs COMPONENT. Suggested by Chad. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
