Re: [waffle] [PATCH v2] wgl: don't use ARB_create_context with pre 3.2 contexts
On 15/04/16 23:48, Emil Velikov wrote:
Direct port of previous commit.
v2: The version should be 3.2 and not 3.0 as originally.
Cc: Jose Fonseca
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
---
src/waffle/wgl/wgl_config.c | 7 ---
src/waffle/wgl/wgl_context.c | 12 +++-
src/waffle/wgl/wgl_context.h | 15 +++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/src/waffle/wgl/wgl_config.c b/src/waffle/wgl/wgl_config.c
index 59a70a6..43bcfa5 100644
--- a/src/waffle/wgl/wgl_config.c
+++ b/src/waffle/wgl/wgl_config.c
@@ -32,6 +32,7 @@
#include "wcore_error.h"
#include "wgl_config.h"
+#include "wgl_context.h"
#include "wgl_display.h"
#include "wgl_error.h"
#include "wgl_platform.h"
@@ -73,11 +74,11 @@ wgl_config_check_context_attrs(struct wgl_display *dpy,
switch (attrs->context_api) {
case WAFFLE_CONTEXT_OPENGL:
-if (!wcore_config_attrs_version_eq(attrs, 10) &&
!dpy->ARB_create_context) {
+if (wgl_context_needs_arb_create_context(attrs) &&
+!dpy->ARB_create_context) {
wcore_errorf(WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM,
"WGL_ARB_create_context is required in order to "
- "request an OpenGL version not equal to the default
"
- "value 1.0");
+ "request an OpenGL version greater or equal than
3.2");
return false;
}
else if (wcore_config_attrs_version_ge(attrs, 32) &&
!dpy->ARB_create_context_profile) {
diff --git a/src/waffle/wgl/wgl_context.c b/src/waffle/wgl/wgl_context.c
index dd45f81..32b2e2d 100644
--- a/src/waffle/wgl/wgl_context.c
+++ b/src/waffle/wgl/wgl_context.c
@@ -152,7 +152,17 @@ wgl_context_create_native(struct wgl_config *config,
HGLRC real_share_ctx = share_ctx ? share_ctx->hglrc : NULL;
HGLRC hglrc;
-if (dpy->ARB_create_context) {
+// Use ARB_create_context when we have
+// - OpenGL version 1.0, or
+// - OpenGL version 3.2 or greater, or
+// - OpenGL with fwd_compat, or
+// - Debug context
+//
+// The first one of the four is optional, the remainder hard requirement
+// for the use of ARB_create_context.
+if (dpy->ARB_create_context &&
+(wcore_config_attrs_version_eq(&config->wcore.attrs, 10) ||
+ wgl_context_needs_arb_create_context(&config->wcore.attrs))) {
bool ok;
// Choose a large size to prevent accidental overflow.
diff --git a/src/waffle/wgl/wgl_context.h b/src/waffle/wgl/wgl_context.h
index c55ad58..28c25c9 100644
--- a/src/waffle/wgl/wgl_context.h
+++ b/src/waffle/wgl/wgl_context.h
@@ -27,6 +27,7 @@
#include
+#include "wcore_config_attrs.h"
#include "wcore_context.h"
#include "wcore_util.h"
@@ -51,3 +52,17 @@ wgl_context_create(struct wcore_platform *wc_plat,
bool
wgl_context_destroy(struct wcore_context *wc_self);
+
+static inline bool
+wgl_context_needs_arb_create_context(const struct wcore_config_attrs *attrs)
+{
+if (attrs->context_api == WAFFLE_CONTEXT_OPENGL &&
+(wcore_config_attrs_version_ge(attrs, 32) ||
+ attrs->context_forward_compatible))
+return true;
+
+if (attrs->context_debug)
+return true;
+
+return false;
+}
Reviewed-by: Jose Fonseca
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/3] glx: don't use ARB_create_context with pre 3.0 contexts
On 15/04/16 23:35, Emil Velikov wrote:
On 15 April 2016 at 20:04, Chad Versace wrote:
On 04/06/2016 02:12 AM, Jose Fonseca wrote:
On 05/04/16 22:45, Emil Velikov wrote:
This way if the user requests GL pre 3.0 context which lacks the
flags/extra bits which require ARB_create_context one can safely fall
back to the normal/legacy entry point.
This resolves piglits on non 3.0 capable drivers such as classic swrast,
nouveau_vieux and alike.
Cc: Jose Fonseca
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
+static inline bool
+glx_context_needs_arb_create_context(const struct wcore_config_attrs *attrs)
+{
+if (attrs->context_api == WAFFLE_CONTEXT_OPENGL &&
+(wcore_config_attrs_version_ge(attrs, 30) ||
+ attrs->context_forward_compatible))
+return true;
+
+if (attrs->context_debug)
+return true;
+
+return false;
+}
Looks good to me. Thanks.
Reviewed-by: Jose Fonseca
I reviewed the thread on the Piglit list, and I'm in favor of this change.
Jose and Emil, I believe the critical version should be 3.2, not 3.0. I don't
understand why this patch uses 3.0 as the cutoff version. The
GLX_ARB_create_context spec says:
The presence of an OpenGL 3.2 or later implementation determines whether or
not GLX_ARB_create_context_profile is required.
And the WGL spec contains the same text.
In other words, it never makes sense to request a 3.2 context without
GLX_ARB_create_context, because the availability of 3.2 mandates the
availability of GLX_ARB_create_context_profile.
Looking at another hunk from the spec makes me wonder:
created. Forward-compatible contexts are defined only for OpenGL
versions 3.0 and later.
So one cannot get a fwd compat context with 3.0 or 3.1, if they don't
support OpenGL 3.2.
Right, creating fwd compat context requires XXX_ARB_create_context, but
your patch has `|| attrs->context_forward_compatible` so it should be
alright.
Not sure I'm getting why they choose to make it
its way - there must be something subtle :-) Regardless, updated
patches coming in a second.
-Emil
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/3] glx: don't use ARB_create_context with pre 3.0 contexts
On 15/04/16 20:04, Chad Versace wrote:
On 04/06/2016 02:12 AM, Jose Fonseca wrote:
On 05/04/16 22:45, Emil Velikov wrote:
This way if the user requests GL pre 3.0 context which lacks the
flags/extra bits which require ARB_create_context one can safely fall
back to the normal/legacy entry point.
This resolves piglits on non 3.0 capable drivers such as classic swrast,
nouveau_vieux and alike.
Cc: Jose Fonseca
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
+static inline bool
+glx_context_needs_arb_create_context(const struct wcore_config_attrs *attrs)
+{
+if (attrs->context_api == WAFFLE_CONTEXT_OPENGL &&
+(wcore_config_attrs_version_ge(attrs, 30) ||
+ attrs->context_forward_compatible))
+return true;
+
+if (attrs->context_debug)
+return true;
+
+return false;
+}
Looks good to me. Thanks.
Reviewed-by: Jose Fonseca
I reviewed the thread on the Piglit list, and I'm in favor of this change.
Jose and Emil, I believe the critical version should be 3.2, not 3.0. I don't
understand why this patch uses 3.0 as the cutoff version. The
GLX_ARB_create_context spec says:
The presence of an OpenGL 3.2 or later implementation determines whether or
not GLX_ARB_create_context_profile is required.
And the WGL spec contains the same text.
In other words, it never makes sense to request a 3.2 context without
GLX_ARB_create_context, because the availability of 3.2 mandates the
availability of GLX_ARB_create_context_profile.
I somehow thought the requirement was introduced in 3.0, but it's indeed
3.2.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/3] glx: don't use ARB_create_context with pre 3.0 contexts
On 05/04/16 22:45, Emil Velikov wrote:
This way if the user requests GL pre 3.0 context which lacks the
flags/extra bits which require ARB_create_context one can safely fall
back to the normal/legacy entry point.
This resolves piglits on non 3.0 capable drivers such as classic swrast,
nouveau_vieux and alike.
Cc: Jose Fonseca
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
---
src/waffle/glx/glx_config.c | 7 ---
src/waffle/glx/glx_context.c | 12 +++-
src/waffle/glx/glx_context.h | 16
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/src/waffle/glx/glx_config.c b/src/waffle/glx/glx_config.c
index 7792aa0..5d02bc3 100644
--- a/src/waffle/glx/glx_config.c
+++ b/src/waffle/glx/glx_config.c
@@ -32,6 +32,7 @@
#include "wcore_error.h"
#include "glx_config.h"
+#include "glx_context.h"
#include "glx_display.h"
#include "glx_platform.h"
#include "glx_wrappers.h"
@@ -70,11 +71,11 @@ glx_config_check_context_attrs(struct glx_display *dpy,
switch (attrs->context_api) {
case WAFFLE_CONTEXT_OPENGL:
-if (!wcore_config_attrs_version_eq(attrs, 10) &&
!dpy->ARB_create_context) {
+if (glx_context_needs_arb_create_context(attrs) &&
+!dpy->ARB_create_context) {
wcore_errorf(WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM,
"GLX_ARB_create_context is required in order to "
- "request an OpenGL version not equal to the default
"
- "value 1.0");
+ "request an OpenGL version greater or equal than
3.0");
return false;
}
else if (wcore_config_attrs_version_ge(attrs, 32) &&
!dpy->ARB_create_context_profile) {
diff --git a/src/waffle/glx/glx_context.c b/src/waffle/glx/glx_context.c
index 1f9290b..8d532d3 100644
--- a/src/waffle/glx/glx_context.c
+++ b/src/waffle/glx/glx_context.c
@@ -169,7 +169,17 @@ glx_context_create_native(struct glx_config *config,
struct glx_display *dpy = glx_display(config->wcore.display);
struct glx_platform *platform = glx_platform(dpy->wcore.platform);
-if (dpy->ARB_create_context) {
+// Use ARB_create_context when we have
+// - OpenGL version 1.0, or
+// - OpenGL version 3.0 or greater, or
+// - OpenGL with fwd_compat, or
+// - Debug context
+//
+// The first one of the four is optional, the remainder hard requirement
+// for the use of ARB_create_context.
+if (dpy->ARB_create_context &&
+(wcore_config_attrs_version_eq(&config->wcore.attrs, 10) ||
+ glx_context_needs_arb_create_context(&config->wcore.attrs))) {
bool ok;
// Choose a large size to prevent accidental overflow.
diff --git a/src/waffle/glx/glx_context.h b/src/waffle/glx/glx_context.h
index bb2a4dd..b471b0e 100644
--- a/src/waffle/glx/glx_context.h
+++ b/src/waffle/glx/glx_context.h
@@ -29,6 +29,7 @@
#include
+#include "wcore_config_attrs.h"
#include "wcore_context.h"
#include "wcore_util.h"
@@ -55,3 +56,18 @@ glx_context_destroy(struct wcore_context *wc_self);
union waffle_native_context*
glx_context_get_native(struct wcore_context *wc_self);
+
+
+static inline bool
+glx_context_needs_arb_create_context(const struct wcore_config_attrs *attrs)
+{
+if (attrs->context_api == WAFFLE_CONTEXT_OPENGL &&
+(wcore_config_attrs_version_ge(attrs, 30) ||
+ attrs->context_forward_compatible))
+return true;
+
+if (attrs->context_debug)
+return true;
+
+return false;
+}
Looks good to me. Thanks.
Reviewed-by: Jose Fonseca
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH v3 2/3] wcore: rework non-compatible mutex initialization
On 27/03/15 23:28, Emil Velikov wrote:
C11 does not specify a static initializer, based on the idea that the
a mutex will be platform and/or implementation dependent. As such the
alternative solution is to initialize the mutex with call_once/mtx_init.
This will allow us to remove the transition hack, and in due time move
to the system's C11 threads implementation.
v2: Actually use call_once() to prevent the possibility of multiple
threads hitting the mtx_init() at the same time. Suggested by Jose.
v3: Do not destroy the mutex. Suggested by Chad.
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_display.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/waffle/core/wcore_display.c b/src/waffle/core/wcore_display.c
index 2feeeba..40f98cf 100644
--- a/src/waffle/core/wcore_display.c
+++ b/src/waffle/core/wcore_display.c
@@ -29,16 +29,25 @@
#include "wcore_display.h"
+static mtx_t mutex;
+
+static void
+wcore_display_init_once(void)
+{
+mtx_init(&mutex, mtx_plain);
+}
+
bool
wcore_display_init(struct wcore_display *self,
struct wcore_platform *platform)
{
static size_t id_counter = 0;
-static mtx_t mutex = _MTX_INITIALIZER_NP;
+static once_flag flag = ONCE_FLAG_INIT;
assert(self);
assert(platform);
+call_once(&flag, wcore_display_init_once);
mtx_lock(&mutex);
self->api.display_id = ++id_counter;
mtx_unlock(&mutex);
Reviewed-by: Jose Fonseca
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH v2 2/3] wcore: rework non-compatible mutex initialization
On 26/03/15 14:50, Chad Versace wrote:
Quoting Emil Velikov (2015-03-25 07:30:00)
On 24 March 2015 at 17:37, Jose Fonseca wrote:
Is wcore_display_teardown called only once, or when destroying each display?
If the latter, then it's not safe to call `mtx_destroy(&mutex)` on
`wcore_display_teardown`. Otherwise when wcore_display_init is called
next, wcore_display_init_once() will not be called a 2nd time, hence mutex
will stay invalid.
This should probably done at waffle_teardown.
Right. The mutex should be destroyed, if anywhere, in waffle_teardown().
But, we should probably not destroy it at all, because of my next
suggestion...
BTW, if the mutex was initialized at waffle_init, then once_flag wouldn't
even be necessary.
Technically correct, but I eventually want to deprecate waffle_init(),
moving its platform parameter to a new waffle_display_connect()
function. Using a once_flag in wcore_display_init() fits better with
that longterm goal. Let's keep Emil's once_flag in this patch.
If use a once_flag, then I believe there is no safe place to
destroy the mutex, because we can't re-initialize the mutex by calling
wcore_display_init_once() a second time.
Which leads to the question: Emil, what benefit do you expect from
destroying the mutex? If Waffle were continuously creating mutexes, then
Waffle would need to destroy them too to prevent leaks. But Waffle only
creates a small, fixed number of global mutexes during the process's
lifetime. And "leaking" them doesn't lead to ongoing memory loss.
Moreover, with pthreads... see my comments below.
Indeed you're bang on the spot. id_counter should be locked throughout
a series of display_{connect, disconnect}, thus we should push
mtx_{init,destroy} up to waffle_{init,teardown}. What worries me is
that none of the tests (ran in valgrind) point out any issues.
I could be wrong, but I believe pthread_mutex_create/destroy don't
allocate/free memory. They just initialize/reset the fields in the
pthread_mutex_t struct. (Otherwise, how would PTHREAD_MUTEX_INITIALIZER
work?). That may explain why you didn't see the expected Valgrind
errors, because no allocation took place.
I think it's fine to let it leak on destroy, but just FYI on Windows
mutex (ie, CriticalSections) may allocate/free memory on certain
configurations. IIRC, they can allocate memory for stack backtraces,
for debugging purposes.
The approach we use to statically initialize critical sections on
windows is unofficial. Read
http://locklessinc.com/articles/pthreads_on_windows/ for the gritty details.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH v2 2/3] wcore: rework non-compatible mutex initialization
Is wcore_display_teardown called only once, or when destroying each display?
If the latter, then it's not safe to call `mtx_destroy(&mutex)` on
`wcore_display_teardown`. Otherwise when wcore_display_init is called
next, wcore_display_init_once() will not be called a 2nd time, hence
mutex will stay invalid.
This should probably done at waffle_teardown.
BTW, if the mutex was initialized at waffle_init, then once_flag
wouldn't even be necessary.
Jose
On 24/03/15 16:56, Emil Velikov wrote:
C11 does not specify a static initializer, based on the idea that the
a mutex will be platform and/or implementation dependent. As such the
alternative solution is to initialize the mutex with call_once/mtx_init.
This will allow us to remove the transition hack, and in due time move
to the system's C11 threads implementation.
v2: Actually use call_once() to prevent the possibility of multiple
threads hitting the mtx_init() at the same time. Suggested by Jose.
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_display.c | 19 ++-
src/waffle/core/wcore_display.h | 9 ++---
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/waffle/core/wcore_display.c b/src/waffle/core/wcore_display.c
index 2feeeba..2cf0dcd 100644
--- a/src/waffle/core/wcore_display.c
+++ b/src/waffle/core/wcore_display.c
@@ -29,16 +29,25 @@
#include "wcore_display.h"
+static mtx_t mutex;
+
+static void
+wcore_display_init_once(void)
+{
+mtx_init(&mutex, mtx_plain);
+}
+
bool
wcore_display_init(struct wcore_display *self,
struct wcore_platform *platform)
{
static size_t id_counter = 0;
-static mtx_t mutex = _MTX_INITIALIZER_NP;
+static once_flag flag = ONCE_FLAG_INIT;
assert(self);
assert(platform);
+call_once(&flag, wcore_display_init_once);
mtx_lock(&mutex);
self->api.display_id = ++id_counter;
mtx_unlock(&mutex);
@@ -52,3 +61,11 @@ wcore_display_init(struct wcore_display *self,
return true;
}
+
+bool
+wcore_display_teardown(struct wcore_display *self)
+{
+assert(self);
+mtx_destroy(&mutex);
+return true;
+}
diff --git a/src/waffle/core/wcore_display.h b/src/waffle/core/wcore_display.h
index de6ca5e..6d95d98 100644
--- a/src/waffle/core/wcore_display.h
+++ b/src/waffle/core/wcore_display.h
@@ -56,10 +56,5 @@ wcore_display_init(struct wcore_display *self,
struct wcore_platform *platform);
-static inline bool
-wcore_display_teardown(struct wcore_display *self)
-{
-(void) self;
-assert(self);
-return true;
-}
+bool
+wcore_display_teardown(struct wcore_display *self);
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 2/3] wcore: rework non-compatible mutex initialization
On 19/03/15 22:26, Emil Velikov wrote:
C11 does not specify a static initializer, based on the idea that the
a mutex will be platform and/or implementation dependent. As such the
alternative solution is to initialize the mutex with mtx_init().
This will allow us to remove the transition hack, and in due time move
to the system's C11 threads implementation.
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_display.c | 6 +++---
src/waffle/core/wcore_display.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/waffle/core/wcore_display.c b/src/waffle/core/wcore_display.c
index 2feeeba..49aeae6 100644
--- a/src/waffle/core/wcore_display.c
+++ b/src/waffle/core/wcore_display.c
@@ -34,14 +34,14 @@ wcore_display_init(struct wcore_display *self,
struct wcore_platform *platform)
{
static size_t id_counter = 0;
-static mtx_t mutex = _MTX_INITIALIZER_NP;
IIUC, this mutex protecting the static id_counter above, not the
wcore_display object, or anything, so moving mtx to display seems incorrect.
The ideal solution here would be to use C11 atomics, but that's a bunch
of extra portibility code to maintain... The portable way of fixing
this with C11 threads is using once_flag.
Jose
assert(self);
assert(platform);
-mtx_lock(&mutex);
+mtx_init(&self->mutex, mtx_plain);
+mtx_lock(&self->mutex);
self->api.display_id = ++id_counter;
-mtx_unlock(&mutex);
+mtx_unlock(&self->mutex);
self->platform = platform;
diff --git a/src/waffle/core/wcore_display.h b/src/waffle/core/wcore_display.h
index de6ca5e..c4348c4 100644
--- a/src/waffle/core/wcore_display.h
+++ b/src/waffle/core/wcore_display.h
@@ -39,6 +39,7 @@ union waffle_native_display;
struct wcore_display {
struct api_object api;
struct wcore_platform *platform;
+mtx_t mutex;
};
static inline struct waffle_display*
@@ -59,7 +60,7 @@ wcore_display_init(struct wcore_display *self,
static inline bool
wcore_display_teardown(struct wcore_display *self)
{
-(void) self;
assert(self);
+mtx_destroy(&self->mutex);
return true;
}
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH] man: Fix typo in WAFFLE_CONTEXT_*_PROFILE.
--- man/waffle_config.3.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/waffle_config.3.xml b/man/waffle_config.3.xml index edfa37e..8dc2fae 100644 --- a/man/waffle_config.3.xml +++ b/man/waffle_config.3.xml @@ -337,8 +337,8 @@ struct waffle_config; The set of accepted values is -WAFFLE_CONTEXT_PROFILE_CORE and -WAFFLE_CONTEXT_PROFILE_COMPATIBILITY. +WAFFLE_CONTEXT_CORE_PROFILE and +WAFFLE_CONTEXT_COMPATIBILITY_PROFILE. -- 2.1.0 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: update minimum required MSVC version to 2013 Update 4
I see. Looks good.
It's funny that
if (${MSVC} AND ${MSVC_VERSION} LESS 1800)
used to work OK in piglit [1]. Probably by sheer luck...
Jose
[1]
http://cgit.freedesktop.org/piglit/commit/?id=306f6ba9a22f496daefa211082cefa1c9ffcf9ab
On 05/02/15 17:18, Emil Velikov wrote:
Currently we mix variable declarations and code, as allowed in the C99
standard. On the other hand, MSVC 2013 prior to Update 4, seems to have
problems with such code in some corner cases.
Considering it's a free update bump the requirement, and add an explicit
check in the build system. Latter of which shamelessly copied from piglit.
v2: Do not evaluate but check the MSVC variable. (Jose)
Reviewed-by: Jose Fonseca
Signed-off-by: Emil Velikov
---
CMakeLists.txt | 5 +
README.txt | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9bbe387..96fda82 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,11 @@ if(waffle_build_tests)
include(WaffleCMocka)
endif()
+# Require MSVC 2013 U4
+if (MSVC AND ${CMAKE_C_COMPILER_VERSION} VERSION_LESS 18.00.31101.0)
+message (FATAL_ERROR "Visual Studio 2013 Update 4 or later required")
+endif ()
+
find_package(PkgConfig)
#
--
diff --git a/README.txt b/README.txt
index c9ffee2..d37e109 100644
--- a/README.txt
+++ b/README.txt
@@ -120,7 +120,7 @@ Download and install the latest version CMake from the
official website:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=RBvFLv1P_C7r-jThSfQLGV4L1h32l9KC-3mJfpjLL6g&s=SCxCJShZIl_Lg0cRH6IfNYDZB7kY-pDbjYbtJXvwODg&e=
-Install Microsoft Visual Studio 2013* or later.
+Install Microsoft Visual Studio 2013 Update 4* or later.
Install 'Visual C++' feature.
Download OpenGL Core API and Extension Header Files.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: update minimum required MSVC version to 2013 Update 4
Emil,
After my piglit change, I had to fix it as
http://cgit.freedesktop.org/piglit/commit/?id=1dca1680c1b29cf1eb242cf8c51e157ca88c929d
otherwise CMake would complain about invalid syntax outside MSVC.
With that,
Reviewed-by: Jose Fonseca
Jose
On 05/02/15 16:48, Emil Velikov wrote:
Currently we mix variable declarations and code, as allowed in the C99
standard. On the other hand, MSVC 2013 prior to Update 4, seems to have
problems with such code in some corner cases.
Considering it's a free update bump the requirement, and add an explicit
check in the build system. Latter of which shamelessly copied from piglit.
Signed-off-by: Emil Velikov
---
CMakeLists.txt | 5 +
README.txt | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9bbe387..7b34160 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,11 @@ if(waffle_build_tests)
include(WaffleCMocka)
endif()
+# Require MSVC 2013 U4
+if (${MSVC} AND ${CMAKE_C_COMPILER_VERSION} VERSION_LESS 18.00.31101.0)
+ message (FATAL_ERROR "Visual Studio 2013 Update 4 or later required")
+endif ()
+
find_package(PkgConfig)
#
--
diff --git a/README.txt b/README.txt
index c9ffee2..d37e109 100644
--- a/README.txt
+++ b/README.txt
@@ -120,7 +120,7 @@ Download and install the latest version CMake from the
official website:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=nNtXnHzuAk5hPwtwGrgxfMXqC38r0N67lMvo2tVn4uI&s=EwNY6JADl8A6pX-r8HaPaKhzyAXhhacMFmSpzh_whB8&e=
-Install Microsoft Visual Studio 2013* or later.
+Install Microsoft Visual Studio 2013 Update 4* or later.
Install 'Visual C++' feature.
Download OpenGL Core API and Extension Header Files.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] wflinfo: Fix MSVC compilation error.
On 30/01/15 22:21, Emil Velikov wrote:
On 30/01/15 20:02, Jose Fonseca wrote:
On 30/01/15 16:25, Emil Velikov wrote:
On 30 January 2015 at 11:07, Jose Fonseca wrote:
Workaround what seems to be a bug in MSVC parser for C99.
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_waffle_2015-2DJanuary_000975.html&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=EOTSIhn-7yCkuKuQ-JCDhS7EtrWFaozBDxo228XaWso&s=0Bi5_OB7Grl7-w1RO8R0l0YtCyi9IkRu-lB9Jtt7Ono&e=
Should have spotted this a Frank sent out the patch. Sorry about this
Jose.
Reviewed-by: Emil Velikov
Wondering if we should (as a follow up commit) move the variable
declarations prior to the code to avoid such fun in the future ?
It's hard to say.
It looks like MSVC allows declarations in the middle of blocks, but the
parser gets into a wierd state some times.
From my earlier experience this issue happens as the variable type is a
typedef or a struct. For simple types such as int, float, etc. I've not
seen such problems. Or was it when the declaration is initialised
(with/wo a designated initializer) ?
I think the surer way long term would be to report the MSVC bug to
Microsoft. There have been positive experiences in the past [1] [2]
Good point. I'll put it on my list but I don't even have an live/msdn
account :\ I'm not sure when I'll get around to creating one, so if
anyone is interested the following mock-up should be able to visualise
the problem(s).
#include
#include
struct foo {
int i;
};
typedef int bar;
int
main(void)
{
struct foo foo1 = { .i = 1 };
printf("foo1 %d\n", foo1.i);
// ^^
// The preprocessor/compiler will throw an error here.
struct foo foo2 = { .i = 2 };
printf("foo2 %d\n", foo2.i);
// ^^
// The preprocessor/compiler will throw an error here.
bar bar1 = 1;
printf("bar1 %d\n", bar1);
return 0;
}
Cheers,
Emil
Thanks for isolating a test case Emil.
I have good news: MSVC 2013 Update 4 seems to have fixed the issue, so
we don't need to file a bug after all.
Given that waffle requires C99, it basically requires MSVC 2013. And
given that MSVC 2013 U4 is a free update it seems acceptable to require
it too. (This is what I'm proposing for piglit too BTW)
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] wflinfo: Fix MSVC compilation error.
On 30/01/15 16:25, Emil Velikov wrote: On 30 January 2015 at 11:07, Jose Fonseca wrote: Workaround what seems to be a bug in MSVC parser for C99. https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_waffle_2015-2DJanuary_000975.html&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=EOTSIhn-7yCkuKuQ-JCDhS7EtrWFaozBDxo228XaWso&s=0Bi5_OB7Grl7-w1RO8R0l0YtCyi9IkRu-lB9Jtt7Ono&e= Should have spotted this a Frank sent out the patch. Sorry about this Jose. Reviewed-by: Emil Velikov Wondering if we should (as a follow up commit) move the variable declarations prior to the code to avoid such fun in the future ? It's hard to say. It looks like MSVC allows declarations in the middle of blocks, but the parser gets into a wierd state some times. I think the surer way long term would be to report the MSVC bug to Microsoft. There have been positive experiences in the past [1] [2] Jose [1] https://bugs.freedesktop.org/show_bug.cgi?id=58718#c17 [2] https://randomascii.wordpress.com/2013/10/14/how-to-report-a-vc-code-gen-bug/ ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH] wflinfo: Fix MSVC compilation error.
Workaround what seems to be a bug in MSVC parser for C99.
http://lists.freedesktop.org/archives/waffle/2015-January/000975.html
---
src/utils/wflinfo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 5e173b7..30d04cd 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -1073,8 +1073,9 @@ main(int argc, char **argv)
error_get_gl_symbol("glGetIntegerv");
glGetString = waffle_dl_sym(opts.dl, "glGetString");
-if (!glGetString)
+if (!glGetString) {
error_get_gl_symbol("glGetString");
+}
const struct wflinfo_config_attrs config_attrs = {
.api = opts.context_api,
--
2.1.0
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] wflinfo: find glGetStringi on both Mali and WGL
On 26/01/15 23:25, Frank Henigman wrote:
Do the glGetStringi lookup after making context current so it works on WGL.
Remove an incorrect glGetStringi lookup, which returned NULL on Mali.
Signed-off-by: Frank Henigman
---
Not sure what happened but wflinfo is still broken on mali because of the
glGetStringi madness.
Chad put in a fix:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_waffle-2Dgl_waffle_commit_0543d0d12aa16e0daf361937619998c8995fd6fc&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=jj_3KkjKndz1s137tbSUUg5KMJt2V9GA1zfYN2FD3NM&s=MqMB3pPMPv0XARCwxF4eXGARoUaWTUMgtf36lr6r18k&e=
and ten days before that Emil had moved the offending
waffle_get_proc_address("glGetStringi") down about 20 lines:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_waffle-2Dgl_waffle_commit_6ae99a4701bd5117a182c2e555a0c0a2061254d3&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=jj_3KkjKndz1s137tbSUUg5KMJt2V9GA1zfYN2FD3NM&s=nva4AmJVhqxaYMvR3ci1RRFczSckPxLwyQrku1kjGkg&e=
It looks like both changes to that line got in, because after Chad's change
successfully sets the address the old, wrong line later sets it to null.
Sorry but I'm not able to test on Windows.
src/utils/wflinfo.c | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 5a9195c..5e173b7 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -1076,6 +1076,25 @@ main(int argc, char **argv)
if (!glGetString)
error_get_gl_symbol("glGetString");
+const struct wflinfo_config_attrs config_attrs = {
+.api = opts.context_api,
+.profile = opts.context_profile,
+.major = opts.context_major,
+.minor = opts.context_minor,
+.forward_compat = opts.context_forward_compatible,
+.debug = opts.context_debug,
+};
After this change, MSVC 2013 started to fail with:
[1/3] Building C object src\utils\CMakeFiles\wflinfo.dir\wflinfo.c.obj
FAILED: C:\PROGRA~2\MICROS~2.0\VC\bin\cl.exe /nologo /DWIN32
/D_WINDOWS /W3 /MT /O1 /Ob1 /D NDEBUG -I..\include -I..\include\waffle
-I..\src -I..\third_party\threads -I..\third_party\getopt /showIncludes
-DWAFFLE_HAS_WGL -DWINVER=0x0601 -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_SECURE_NO_WARNINGS -D_WIN32_WINNT=0x0601
/Fosrc\utils\CMakeFiles\wflinfo.dir\wflinfo.c.obj
/Fdsrc\utils\CMakeFiles\wflinfo.dir/ /FS -c ..\src\utils\wflinfo.c
..\src\utils\wflinfo.c(1079) : error C2143: syntax error : missing ';'
before 'const'
..\src\utils\wflinfo.c(1088) : error C2065: 'config_attrs' : undeclared
identifier
..\src\utils\wflinfo.c(1088) : error C2440: 'function' : cannot convert
from 'int' to 'wflinfo_config_attrs'
..\src\utils\wflinfo.c(1088) : warning C4024: 'wflinfo_create_context' :
different types for formal and actual parameter 2
But this change makes MSVC happy:
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 5e173b7..30d04cd 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -1073,8 +1073,9 @@ main(int argc, char **argv)
error_get_gl_symbol("glGetIntegerv");
glGetString = waffle_dl_sym(opts.dl, "glGetString");
-if (!glGetString)
+if (!glGetString) {
error_get_gl_symbol("glGetString");
+}
const struct wflinfo_config_attrs config_attrs = {
.api = opts.context_api,
That is, there's a bug in MSVC 2013 C99 grammar/parser...
Jose
+
+wflinfo_create_context(dpy, config_attrs, &ctx, &config);
+
+window = waffle_window_create(config, WINDOW_WIDTH, WINDOW_HEIGHT);
+if (!window)
+error_waffle();
+
+ok = waffle_make_current(dpy, window, ctx);
+if (!ok)
+error_waffle();
+
// Retrieving GL functions is tricky. When glGetStringi is supported, here
// are some boggling variations as of 2014-11-19:
// - Mali drivers on EGL 1.4 expose glGetStringi statically from
@@ -1099,27 +1118,6 @@ main(int argc, char **argv)
glGetStringi = waffle_get_proc_address("glGetStringi");
}
-const struct wflinfo_config_attrs config_attrs = {
-.api = opts.context_api,
-.profile = opts.context_profile,
-.major = opts.context_major,
-.minor = opts.context_minor,
-.forward_compat = opts.context_forward_compatible,
-.debug = opts.context_debug,
-};
-
-wflinfo_create_context(dpy, config_attrs, &ctx, &config);
-
-window = waffle_window_create(config, WINDOW_WIDTH, WINDOW_HEIGHT);
-if (!window)
-error_waffle();
-
-ok = waffle_make_current(dpy, window, ctx);
-if (!ok)
-error_waffle();
-
-glGetStringi = waffle_get_proc_address("glGetStringi");
-
ok = print_wflinfo(&opts);
if (!ok)
error_waffle();
___
waffle mailing list
waffle@lists.freedesktop.org
http:/
Re: [waffle] [PATCH 3/3] wgl: Verify the client area size matches the required size on window creation too.
On 29/12/14 22:01, Emil Velikov wrote: On 29/12/14 16:22, Jose Fonseca wrote: From: José Fonseca By default, Windows will limit windows too large to theu desktop size, and windows too small to be big enough for the titlebar. Waffle's windows don't get affected as their style is WS_POPUPWINDOW, which doesn't include the WS_CAPTION style. This is one of the hacks that I've added in waffle (please be gentle), which I want to cleanup as waffle_window_create2 lands. My rough idea is to feed WS_POPUPWINDOW on -auto piglits and WS_CAPTION otherwise into waffle_window_create2. The principle is analogous to the "don't capture input" approach as seen with glx. Afaict the idea of waffle is to avoid nasty things/assumptions when possible and the above idea should help. How does it sound ? I haven't looked closely at `waffle_window_create2` code and how it interacts. I do know that it's possible to get WS_CAPTION windows larger than the desktop if one handles the WM_GETMINMAXINFO message, like done in https://github.com/apitrace/apitrace/blob/master/retrace/glws_wgl.cpp#L75 However this trick doesn't work for tiny WS_CAPTION windows, not matter how much I tried. There is a more comprehensive solution though: make the OpenGL drawable a child window instead of the top window, so that even if the parent can't become tiny due to the title bar, the child window (hence the OpenGL drawble) can be as tiny as we want. I haven't implemented this on apitrace yet, but that is my hope. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 3/4] cmake: Add the installed package files to the registry on windows
On 29/12/14 17:07, Dylan Baker wrote:
On Monday, December 29, 2014 11:35:20 AM Jose Fonseca wrote:
On 22/12/14 22:36, Dylan Baker wrote:
This adds the locations of the package files to the registry on windows,
which should allow them to be auto detected by cmake on windows when
linking against waffle in other projects.
Signed-off-by: Dylan Baker
---
This patch is completely untested (I don't have access to a windows
development machine, nor do I want to maintain one), I've sent this as a
courtesy to windows users, and hopefully it can point an interested part
in the correct direction.
Note that this installs into the local machine registry, and there is
also the option of using local user registry instead, and that can be
done by changing waffle to use export(), though I'm not exactly sure how
that works either
CMakeLists.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 729ebc1..0ac2d4b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -182,6 +182,16 @@ install(
COMPONENT Devel
)
+# If running on windows add waffle to the registry so it can be auto detected
+# by consuming projects
+if (WIN32)
This will break cross-compiling from Linux to Windows (via MinGW),
because "WIN32" is true.
Replacing it with
if (WIN32 AND NOT CMAKE_CROSSCOMPILING)
should do the trick.
+execute_process(
+COMMAND "REG ADD HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\Waffle
/v Waffle-1 /t REG_SZ /d ${ConfigPackageLocation} /f"
I suspect this will fail when there are spaces in the path (e.g., when
waffle is in "C:\Program Files\..."
+ERROR_QUIET
+OUTPUT_QUIET
+)
+endif ()
Also I believe execute_process() will execute the command when
configuring -- not when building --, or even better, not when installing.
I'm not sure this is a great idea overall. Are any other packages doing
anything like this? It all seems very non-standard, so I wonder if this
will really simplify things or be too surprising.
I can't say whether it is a good idea or not, it's suggested by the
cmake documentation as the "right" way to do things on windows. I don't
have a strong opinion either way, and, like you, I doubt this works
correctly in it's current form. I provided mostly as a way to say "hey,
you can do this if you want", but I no problem dropping it.
Thanks. I actually forgot to say in my reply that I appreciate you
taking the time and energy to looking into this.
If CMake documentation recommends, then it might be possible to find a
more comprehensive example in some open source project that does this,
that we can use as reference. I confess I never came across one, but my
sampling universe is limited.
http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry explains some
of this, but doesn't actually explain how to set. My guess is that the
registry key is typically set by full-blown Windows pakcages installers
like Windows Installer or NSIS, but we don't use them here.
We could though, as cpack supports NSIS --
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS --, so we
could produce a NSIS installer for waffle, which would set the registry
key enabling waffle consumers to automatically pick up the right locations.
In short, I think there might be some merit in this idea, but there a
few open issues. In the meanwhile we should hold on.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 2/3] examples/gl_basic: Add option for window size.
From: José Fonseca
Useful to test huge/tiny windows.
---
examples/gl_basic.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/examples/gl_basic.c b/examples/gl_basic.c
index fb62d52..69418c8 100644
--- a/examples/gl_basic.c
+++ b/examples/gl_basic.c
@@ -68,6 +68,7 @@ static const char *usage_message =
" [--forward-compatible]\n"
" [--debug]\n"
" [--resize-window]\n"
+" [--window-size=WIDTHxHEIGHT]\n"
"\n"
"examples:\n"
"gl_basic --platform=glx --api=gl\n"
@@ -96,6 +97,7 @@ enum {
OPT_DEBUG,
OPT_FORWARD_COMPATIBLE,
OPT_RESIZE_WINDOW,
+OPT_WINDOW_SIZE,
};
static const struct option get_opts[] = {
@@ -106,6 +108,7 @@ static const struct option get_opts[] = {
{ .name = "debug", .has_arg = no_argument, .val =
OPT_DEBUG },
{ .name = "forward-compatible", .has_arg = no_argument, .val =
OPT_FORWARD_COMPATIBLE },
{ .name = "resize-window", .has_arg = no_argument, .val =
OPT_RESIZE_WINDOW },
+{ .name = "window-size",.has_arg = required_argument, .val =
OPT_WINDOW_SIZE },
{ 0 },
};
@@ -190,8 +193,8 @@ enum {
GL_CONTEXT_FLAG_DEBUG_BIT = 0x0002,
};
-#define WINDOW_WIDTH 320
-#define WINDOW_HEIGHT 240
+static int window_width = 320;
+static int window_height = 240;
#ifndef _WIN32
#define APIENTRY
@@ -348,6 +351,15 @@ parse_args(int argc, char *argv[], struct options *opts)
case OPT_RESIZE_WINDOW:
opts->resize_window = true;
break;
+case OPT_WINDOW_SIZE: {
+int match_count;
+match_count = sscanf(optarg, "%dx%d", &window_width,
&window_height);
+if (match_count != 2) {
+usage_error_printf("'%s' is not a valid window geometry",
+ optarg);
+}
+break;
+}
default:
abort();
loop_get_opt = false;
@@ -389,8 +401,8 @@ draw(struct waffle_window *window, bool resize)
{
bool ok;
unsigned char *colors;
-int width = WINDOW_WIDTH;
-int height = WINDOW_HEIGHT;
+int width = window_width;
+int height = window_height;
#if !defined(_WIN32)
static const struct timespec sleep_time = {
@@ -616,7 +628,7 @@ main(int argc, char **argv)
if (!ctx)
error_waffle();
-window = waffle_window_create(config, WINDOW_WIDTH, WINDOW_HEIGHT);
+window = waffle_window_create(config, window_width, window_height);
if (!window)
error_waffle();
--
2.1.0
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 1/3] test/gl_basic_test: Address gcc format mismatch warning.
From: José Fonseca
---
tests/functional/gl_basic_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/functional/gl_basic_test.c b/tests/functional/gl_basic_test.c
index 03692e0..0e932e3 100644
--- a/tests/functional/gl_basic_test.c
+++ b/tests/functional/gl_basic_test.c
@@ -1129,7 +1129,7 @@ run_testsuite(void (*testsuite)(void))
}
else {
fprintf(stderr, "gl_basic_test: error: get thread exit status"
-" failed (%d)\n", GetLastError());
+" failed (%lu)\n", GetLastError());
abort();
}
}
--
2.1.0
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 3/3] wgl: Verify the client area size matches the required size on window creation too.
From: José Fonseca By default, Windows will limit windows too large to theu desktop size, and windows too small to be big enough for the titlebar. Waffle's windows don't get affected as their style is WS_POPUPWINDOW, which doesn't include the WS_CAPTION style. This change adds more assertion, just in case this ever changes, as many piglit tests rely on large/tiny windows to have the requested size. Also replace `#ifdef DEBUG` with `#ifndef NDEBUG`, as NDEBUG is the define that controls assert macro. That said, I wonder if we should call `waffle_errorf(WAFFLE_ERROR_INTERNAL, ...)` and verify this on release builds too. --- src/waffle/wgl/wgl_window.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/waffle/wgl/wgl_window.c b/src/waffle/wgl/wgl_window.c index a557c2f..7c3932f 100644 --- a/src/waffle/wgl/wgl_window.c +++ b/src/waffle/wgl/wgl_window.c @@ -127,6 +127,16 @@ wgl_window_priv_create(struct wcore_platform *wc_plat, if (!self->hWnd) goto error; +#ifndef NDEBUG +// Verify the client area size matches the required size. + +GetClientRect(self->hWnd, &rect); +assert(rect.left == 0); +assert(rect.top == 0); +assert(rect.right - rect.left == width); +assert(rect.bottom - rect.top == height); +#endif + self->hDC = GetDC(self->hWnd); if (!self->hDC) goto error; @@ -178,7 +188,7 @@ wgl_window_resize(struct wcore_window *wc_self, rect.bottom - rect.top, SWP_NOMOVE|SWP_NOZORDER|SWP_NOACTIVATE); -#ifdef DEBUG +#ifndef NDEBUG // Verify the client area size matches the required size. GetClientRect(self->hWnd, &rect); -- 2.1.0 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] wgl: Fix requirements for creation of ES2 context
Sorry for the delay. I flagged this email, but then forgot about it, to
only find it again now.
Patch looks good and builds fine.
Reviewed-by: Jose Fonseca
Jose
On 06/12/14 00:52, Chad Versace wrote:
To create an ES2 context, Waffle required
WGL_EXT_create_context_es2_profile. Fix Waffle to require either
WGL_EXT_create_context_es_profile *or*
WGL_EXT_create_context_es2_profile, because
WGL_EXT_create_context_es_profile is an updated variant of
WGL_EXT_create_context_es2_profile that supercedes it.
Cc: José Fonseca
Cc: Emil Velikov
Fixes #23:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_waffle-2Dgl_waffle_issues_23&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=5fmQ5w_Dy43fhC0ykaKcKMty48N6X7EEst9KKscTJ1U&s=zIqRdTM0gI7dO2XWOAEibdFaoaP5T2VvvujYr9jX8Vs&e=
Signed-off-by: Chad Versace
---
Totally untested. I don't have MinGW setup right now. Windows people, please
let know if this patch compiles.
src/waffle/wgl/wgl_config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/waffle/wgl/wgl_config.c b/src/waffle/wgl/wgl_config.c
index 9dea991..59a70a6 100644
--- a/src/waffle/wgl/wgl_config.c
+++ b/src/waffle/wgl/wgl_config.c
@@ -118,8 +118,10 @@ wgl_config_check_context_attrs(struct wgl_display *dpy,
assert(attrs->context_major_version == 2);
assert(!attrs->context_forward_compatible);
-if (!dpy->EXT_create_context_es2_profile) {
+if (!dpy->EXT_create_context_es2_profile
+&& !dpy->EXT_create_context_es_profile) {
wcore_errorf(WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM,
+ "WGL_EXT_create_context_es_profile or "
"WGL_EXT_create_context_es2_profile is required "
"to create an OpenGL ES2 context");
return false;
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 3/4] cmake: Add the installed package files to the registry on windows
On 22/12/14 22:36, Dylan Baker wrote:
This adds the locations of the package files to the registry on windows,
which should allow them to be auto detected by cmake on windows when
linking against waffle in other projects.
Signed-off-by: Dylan Baker
---
This patch is completely untested (I don't have access to a windows
development machine, nor do I want to maintain one), I've sent this as a
courtesy to windows users, and hopefully it can point an interested part
in the correct direction.
Note that this installs into the local machine registry, and there is
also the option of using local user registry instead, and that can be
done by changing waffle to use export(), though I'm not exactly sure how
that works either
CMakeLists.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 729ebc1..0ac2d4b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -182,6 +182,16 @@ install(
COMPONENT Devel
)
+# If running on windows add waffle to the registry so it can be auto detected
+# by consuming projects
+if (WIN32)
This will break cross-compiling from Linux to Windows (via MinGW),
because "WIN32" is true.
Replacing it with
if (WIN32 AND NOT CMAKE_CROSSCOMPILING)
should do the trick.
+execute_process(
+COMMAND "REG ADD HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\Waffle
/v Waffle-1 /t REG_SZ /d ${ConfigPackageLocation} /f"
I suspect this will fail when there are spaces in the path (e.g., when
waffle is in "C:\Program Files\..."
+ERROR_QUIET
+OUTPUT_QUIET
+)
+endif ()
Also I believe execute_process() will execute the command when
configuring -- not when building --, or even better, not when installing.
I'm not sure this is a great idea overall. Are any other packages doing
anything like this? It all seems very non-standard, so I wonder if this
will really simplify things or be too surprising.
FWIW, IMO the best way of finding things with CMake on Windows is using
the `-C` cmake option.
For example, this is part of my MSVC Cmake cache:
$ cat msvc32/Cache.cmake
set (CMAKE_ASM_MASM_COMPILER "${CMAKE_CURRENT_LIST_DIR}/masm/ml.exe"
CACHE FILEPATH "" FORCE)
set (GLEXT_INCLUDE_DIR "H:/noarch/glext" CACHE PATH "" FORCE)
set (GLEW_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/glew/include" CACHE
PATH "" FORCE)
set (GLEW_glew_LIBRARY "${CMAKE_CURRENT_LIST_DIR}/glew/lib/glew32.lib"
CACHE FILEPATH "" FORCE)
set (GLFW_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/glfw/include" CACHE
PATH "" FORCE)
set (GLFW_LIBRARY "${CMAKE_CURRENT_LIST_DIR}/glfw/lib/glfw32.lib" CACHE
FILEPATH "" FORCE)
set (GLUT_INCLUDE_DIR "H:/msvc32/freeglut/include" CACHE PATH "" FORCE)
set (GLUT_glut_LIBRARY "H:/msvc32/freeglut/lib/freeglut.lib" CACHE
FILEPATH "" FORCE)
set (PNG_PNG_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/libpng/include"
CACHE PATH "" FORCE)
set (PNG_LIBRARY "${CMAKE_CURRENT_LIST_DIR}/libpng/lib/libpng.lib" CACHE
FILEPATH "" FORCE)
set (ZLIB_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/zlib/include" CACHE
PATH "" FORCE)
set (ZLIB_LIBRARY "${CMAKE_CURRENT_LIST_DIR}/zlib/lib/zlib.lib" CACHE
FILEPATH "" FORCE)
[...]
So all I need to do when building any Cmake project is to pass -C
/path/to/Cache.cmake and it will find everything I need. All this is in
a network share so it can be used both from my Windows development
machines and build slaves.
Of course, this only works if the cmake project is not too smart for its
own good.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: Find and set include path for wglext.h
On 03/12/14 18:52, Chad Versace wrote: On 11/26/2014 04:01 AM, Jose Fonseca wrote: On 26/11/14 11:33, Emil Velikov wrote: Thanks for the reminder Jose. The general consensus in #cmake (halfway though the GSoC) was that find_package(OpenGL REQUIRED) for Windows development is (should) not be needed, thus I've dropped it ages ago. Actually I added that line by mistake. You mean, basically OpenGL is guaranteed to be supported on Windows, as it's part of the Window SDKs (or MinGW headers). Never thought of that, but yeah, makes sense. This line is probably better left out then. Jose, do you want me to remove the line +find_package(OpenGL REQUIRED) before committing or leave it in? Please remove it. Thanks. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: Find and set include path for wglext.h
On 26/11/14 11:33, Emil Velikov wrote:
Thanks for the reminder Jose.
The general consensus in #cmake (halfway though the GSoC) was that
find_package(OpenGL REQUIRED) for Windows development is (should) not be
needed, thus I've dropped it ages ago.
Actually I added that line by mistake.
You mean, basically OpenGL is guaranteed to be supported on Windows, as
it's part of the Window SDKs (or MinGW headers). Never thought of that,
but yeah, makes sense.
This line is probably better left out then.
Either way the commit looks good imho.
Reviewed-by: Emil Velikov
Thanks
Jose
On 26/11/14 10:24, Jose Fonseca wrote:
It would be nice if you could include this on waffle 1.5.0.
Without this, one is forced to download and put the Khronos wglext.h
into the same folder MSVC/MinGW system headers are (a bad idea because
it just masks away problem like this), or modify waffle locally.
Jose
On 23/11/14 09:32, jfons...@vmware.com wrote:
From: José Fonseca
GL/*glext.h is not provided by the system (be it MinGW or MSVC), so its
path must be specified separately.
I used GLEXT_INCLUDE_DIR, which is the name also used for Piglit, so
that existing CMake initial caches might already provide it.
---
cmake/Modules/WaffleFindDependencies.cmake | 6 ++
src/waffle/CMakeLists.txt | 1 +
2 files changed, 7 insertions(+)
diff --git a/cmake/Modules/WaffleFindDependencies.cmake
b/cmake/Modules/WaffleFindDependencies.cmake
index 9245772..1c617f7 100644
--- a/cmake/Modules/WaffleFindDependencies.cmake
+++ b/cmake/Modules/WaffleFindDependencies.cmake
@@ -80,3 +80,9 @@ if(waffle_on_linux)
waffle_pkg_config(gbm gbm)
waffle_pkg_config(libudev libudev)
endif()
+
+
+if(waffle_on_windows)
+find_package(OpenGL REQUIRED)
+find_path(GLEXT_INCLUDE_DIR NAMES GL/wglext.h DOC "Include for
GL/wglext.h")
+endif()
diff --git a/src/waffle/CMakeLists.txt b/src/waffle/CMakeLists.txt
index 5c63c47..aef0952 100644
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -23,6 +23,7 @@ include_directories(
${egl_INCLUDE_DIRS}
${gbm_INCLUDE_DIRS}
${gl_INCLUDE_DIRS}
+${GLEXT_INCLUDE_DIR}
${libudev_INCLUDE_DIRS}
${wayland-client_INCLUDE_DIRS}
${wayland-egl_INCLUDE_DIRS}
___
waffle mailing list
waffle@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_waffle&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=q5gMrzL7EKsbh6mmCqBVoGfLPuiMZ3AXGUFsDr8VbbI&s=TBINvx4lselLchkslkAZwPqLz8F43se-BKrP867i1VI&e=
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: Find and set include path for wglext.h
It would be nice if you could include this on waffle 1.5.0.
Without this, one is forced to download and put the Khronos wglext.h
into the same folder MSVC/MinGW system headers are (a bad idea because
it just masks away problem like this), or modify waffle locally.
Jose
On 23/11/14 09:32, jfons...@vmware.com wrote:
From: José Fonseca
GL/*glext.h is not provided by the system (be it MinGW or MSVC), so its
path must be specified separately.
I used GLEXT_INCLUDE_DIR, which is the name also used for Piglit, so
that existing CMake initial caches might already provide it.
---
cmake/Modules/WaffleFindDependencies.cmake | 6 ++
src/waffle/CMakeLists.txt | 1 +
2 files changed, 7 insertions(+)
diff --git a/cmake/Modules/WaffleFindDependencies.cmake
b/cmake/Modules/WaffleFindDependencies.cmake
index 9245772..1c617f7 100644
--- a/cmake/Modules/WaffleFindDependencies.cmake
+++ b/cmake/Modules/WaffleFindDependencies.cmake
@@ -80,3 +80,9 @@ if(waffle_on_linux)
waffle_pkg_config(gbm gbm)
waffle_pkg_config(libudev libudev)
endif()
+
+
+if(waffle_on_windows)
+find_package(OpenGL REQUIRED)
+find_path(GLEXT_INCLUDE_DIR NAMES GL/wglext.h DOC "Include for
GL/wglext.h")
+endif()
diff --git a/src/waffle/CMakeLists.txt b/src/waffle/CMakeLists.txt
index 5c63c47..aef0952 100644
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -23,6 +23,7 @@ include_directories(
${egl_INCLUDE_DIRS}
${gbm_INCLUDE_DIRS}
${gl_INCLUDE_DIRS}
+${GLEXT_INCLUDE_DIR}
${libudev_INCLUDE_DIRS}
${wayland-client_INCLUDE_DIRS}
${wayland-egl_INCLUDE_DIRS}
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
Hi Emil, I went through the new patches and they look good AFAICT. Thanks for doing this. While going through "wgl: fully support ARB_create_context and EXT_create_context_es_profile." again I noticed a couple of issues with the usage of WGL_EXT_create_context_es2_profile that I hadn't noticed before because I wasn't familiar with the extension: - WGL_EXT_create_context_es_profile ignored the opengl version, but WGL_EXT_create_context_es2_profile will create any version requested in. - I believe one must set WGL_CONTEXT_MAJOR_VERSION_ARB/WGL_CONTEXT_MINOR_VERSION_ARB when requesting ES contexts or one will always get a ES 1.0 context. - It's OK to assume that WGL_EXT_create_context_es2_profile then WGL_EXT_create_context_es_profile is supported, but not the other way around. This is because WGL_EXT_create_context_es_profile ignored the version See "Revision History" at the bottom of https://www.opengl.org/registry/specs/EXT/wgl_create_context_es2_profile.txt for details. Anyway, this is nor urgent -- it can be fixed in a follow on patch. Jose From: waffle on behalf of Emil Velikov Sent: 09 November 2014 22:58 To: waffle@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: [waffle] [PULL] WGL support Hello Chad, As mentioned earlier here is a rebase of all the wgl work so far on top of origin/master. NOTE: The origin/master branch lacks the first patch in the series, yet it is present in origin/next. I would suspect that other patches may be in such state but I haven't checked. What's new: - Patch 06/53: wgl: implement display management Drop "we use the root GL context as a fallback context in waffle_get_proc_address..." from the commit message. - Patch 08/53: wgl: wire-up waffle_get_proc_address() No more ABI/API break. Infortunatelly this does not give us any additional cleanups, as we still need to have a GL context in order to choose the config... lovely WGL. - Patch 13/53: wgl: provide static GLES* symbols (dlsym) via opengl32.dll The name says it all, this handles the second ABI/API break that I had initially and is now withdrawn. - Patch 46/53: cmake: Set default location for all artifacts to top-level directories Version 2 of your patch, updated to work under Windows. There is no rpath in there so one needs to put the dll (considered RUNTIME object) alongside the executables that use it. - Patch 47/53: cmake: ensure waffle-static name differs from the shared one Or there will be name collision with the shared waffle objects and all hell will break loose. - Patch 48/53: wflinfo: call get_proc_address after make_current - Patches 49-53/53 are some spelling/grammar fixes. And a pull request below, considering there aren't any issues with the series Thank Emil P.S. Handling multiple locations where the waffle version number is stored is going to be a pain in the a** when releasing waffle. Any ideas how to handle it ? The following changes since commit f16fe1afaa0ecca217d5f90d9f2255ffd570f63a: Merge branch 'maint-1.4' (2014-11-08 11:50:52 -0800) are available in the git repository at: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_evelikov_waffle.git&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=EGM6H4ulpFPwVnDDH3iPVGd98lc14c_lhS09jYVF5xw&s=lxQxEL2eOi4ZT2UgL4Ip5ZgShVo5gsGwfiGr2SODtgE&e= for-chad/wgl-pull for you to fetch changes up to 8afea079f19ce86e209b5e61158d8890ad187b03: man: spelling fix (2014-11-09 22:44:09 +) Emil Velikov (53): cmake: include the CPACK module pkg/archlinux: add mingw-w64-waffle package README: Add notes when building Waffle for Windows. wgl: add skeleton implementation wgl: fill up the dl_* hooks wgl: implement display management wgl: wire-up wgl_window and wgl_config hooks wgl: wire-up waffle_get_proc_address() wgl: add context hooks wgl: check for various WGL extensions and fetch their funcptrs wgl: use wglChoosePixelFormatARB when available wgl: fully support ARB_create_context and EXT_create_context_es_profile. wgl: provide static GLES* symbols (dlsym) via opengl32.dll cmake: set most compiler flags/defines in a single location cmake: drop the waffle library prefix on Windows wgl: restrict exported symbols via module-definition file wgl: avoid using container_of and DEFINE_CONTAINER_CAST_FUNC macros tests: do not force gcc compiler flags onto msvc tests/gl_basic_test: don't include posix headers when building for win32 core: wcore_error_unittest include c99_compat.h examples/gl_basic: use native sleep functions core: use compiler specific (noreturn) attribute examples/gl_basic: use compiler specific (noreturn) attribute utils/wflinfo: use compiler specific (noreturn) attribute
Re: [waffle] Hopes and plans for waffle-next
Hi Emil,
I see you moved on!
Yes, I'd like to see WGL support in waffle all the way through, so we
can use it in piglit.
Could you summarize exactly what's missing?
Jose
On 26/08/14 19:09, Emil Velikov wrote:
Hello list,
Following my GSoC, I would like to list a couple of things that I think would
be great to have and hope to get in for waffle-2 (or whatever the next version
might be).
* WGL support for core Waffle, tests de-duplication and WGL support.
* Linking - drop LINK_INTERFACE_LIBRARIES hack, avoid over-linking.
* Start of "Don't explicitly link to libraries" - github issue 9.
* Add waffle_finish() to complement waffle_init(), suggested by Chad - TODO
* Add make check-{func-,}valgrind, suggested by Chad - TODO.
The patches listed/linked below are bit short on review, so I would greatly
appreciate if anyone can spare a few minutes and check them out :)
Jose, Brian,
Do you think you can help out, even though the GSoC program is over ?
Thanks
Emil
[1] Linking cleanup (3 patch series). This series should be safe to go in
master as-is.
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/waffle/2014-August/000664.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0A&s=1598850fc0079a8ab9813764c70507b9dffbc7c3ecf938408b6c33f7f88fef30
[2] Do not link but dlopen libEGL (3 patch series)
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/waffle/2014-August/000668.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0A&s=e6c60f71a59f4dcaaea54362e434d1451850d5f80312da28b5fdcf43ea10e906
[3] Prevent heap corruption (2 patch series)
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/waffle/2014-August/000643.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0A&s=5cea761368c587f1e6153002d852c6c09b0f763cb6c02eed08457b13c111244b
[4] Unconditionally use opengl32 to provide GL and GLES* static symbols.
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/waffle/2014-August/000659.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0A&s=69a62cc1572404fbab4db0f5df82503298d9af7317439f151cb9cb1802a6c3eb
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Final (GSoCwise) waffle WGL release
On 21/08/14 00:15, Chad Versace wrote: On 08/20/2014 06:55 AM, Emil Velikov wrote: waffle works like a champ with WGL, even piglit approves :P With branches 'yet-another-round-of-msvc-fixes-1.2' [1] and 'waffle-WGL-1.2' I can run piglit+waffle+wgl on my Windows 7 machine and even crash the drivers on a non-concurrent run :) Below is a summary of my piglit run. [15023/15023] crash: 24, fail: 1401, pass: 8323, skip: 5274, warn: 1 Woo! Great job Emil! Jose I neglected to observe that you've spammed the Piglit list too :) I will take a look at it. There are still some small bits that needs picking (one of which is the final API/ABI change which I'm trying to convince Chad is a good idea), but those will happen in due time. Meanwhile head over to the github release page [3] if you like to give it a try. Emil, start sending pull requests! Except for the one patch we're still arguing about... ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/4] wgl: attempt to fix the final test
On 19/08/14 18:44, Emil Velikov wrote:
On 19 August 2014 16:51, Jose Fonseca wrote:
On 19/08/14 16:41, Jose Fonseca wrote:
On 19/08/14 14:43, Emil Velikov wrote:
On 19/08/14 14:34, Emil Velikov wrote:
On 19/08/14 13:42, Jose Fonseca wrote:
On 12/08/14 16:37, Emil Velikov wrote:
MSVC helps us out with the final test by undicating that we're
corrupting the stack, which begs the question - at which point are we
messing up with the calling conventions. This patch attempts to
resolve
that yet the bug still persists :'(
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_error_unittest.c | 4
third_party/threads/threads.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/waffle/core/wcore_error_unittest.c
b/src/waffle/core/wcore_error_unittest.c
index 5176031..8b9b334 100644
--- a/src/waffle/core/wcore_error_unittest.c
+++ b/src/waffle/core/wcore_error_unittest.c
@@ -148,7 +148,11 @@ struct thread_arg {
};
/// The start routine given to threads in test
wcore_error.thread_local.
+#if !defined(_WIN32)
static bool
+#else
+static bool __stdcall
+#endif
thread_start(struct thread_arg *a)
{
static const enum waffle_error error_codes[NUM_THREADS] = {
diff --git a/third_party/threads/threads.h
b/third_party/threads/threads.h
index 4e7dba2..eb024dd 100644
--- a/third_party/threads/threads.h
+++ b/third_party/threads/threads.h
@@ -117,7 +117,7 @@ typedef pthread_once_t once_flag;
/* types */
typedef void (*tss_dtor_t)(void*);
-typedef int (*thrd_start_t)(void*);
+typedef int (__stdcall *thrd_start_t)(void*);
struct xtime {
time_t sec;
Sorry, I've been on PTO and I haven't caught up with email.
What is the problem here again?
We end up with stack corruption in test_wcore_error_thread_local().
The documentation indicates [1] that the function pointer passed to
_beginthreadex (in our third_party/threads code) should use __stdcall
calling
convention. I'm not entirely sure which/how many pieces we need to
annotate
due to the amount of function pointers passed around :'(
Actually _beginthreadex() is correctly setup, yet pack.func(pack.arg)
(from
impl_thrd_routine) may not be. So many functions passing around func
pointers
is making my head spin.
You should be able to reproduce by building waffle and giving 'make
check'* a try.
I will try to repro.
But this patch doesn't look right, because we don't call beginthreadex
with the thrd_start_t pointer. Instead we call _beginthreadex(
impl_thrd_routine), which does have the __stdcall already.
BTW, this code is being used in llvmpipe's multi-threaded rasterized and
it is known to work.
I suspect the problem is elsewhere.
This is the problem:
thrd_join(threads[i], (int *) &exit_codes[i]);
a bool takes one byte, where as int takes four.
If the cast wasn't here the compiler would have warned about the type
mismtach.
Indeed that's the one. Which begs the question why we don't crash on
linux
I'm sure it overflows on Linux too. valgrind might complain.
But MSVC emits code to check for stack overflow -- some sort of canary.
There is no "crash" per se -- but an error dialog.
> but I'll leave that one for some other time.
There seems to be another booger a few lines above
a->thread_id = i;
The former is int, while the latter is intptr_t.
Right, it will be truncated. There should be no overflow here though.
Thank you Jose, I owe you one :)
-Emil
You're welcome!
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/4] wgl: attempt to fix the final test
On 19/08/14 16:41, Jose Fonseca wrote:
On 19/08/14 14:43, Emil Velikov wrote:
On 19/08/14 14:34, Emil Velikov wrote:
On 19/08/14 13:42, Jose Fonseca wrote:
On 12/08/14 16:37, Emil Velikov wrote:
MSVC helps us out with the final test by undicating that we're
corrupting the stack, which begs the question - at which point are we
messing up with the calling conventions. This patch attempts to
resolve
that yet the bug still persists :'(
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_error_unittest.c | 4
third_party/threads/threads.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/waffle/core/wcore_error_unittest.c
b/src/waffle/core/wcore_error_unittest.c
index 5176031..8b9b334 100644
--- a/src/waffle/core/wcore_error_unittest.c
+++ b/src/waffle/core/wcore_error_unittest.c
@@ -148,7 +148,11 @@ struct thread_arg {
};
/// The start routine given to threads in test
wcore_error.thread_local.
+#if !defined(_WIN32)
static bool
+#else
+static bool __stdcall
+#endif
thread_start(struct thread_arg *a)
{
static const enum waffle_error error_codes[NUM_THREADS] = {
diff --git a/third_party/threads/threads.h
b/third_party/threads/threads.h
index 4e7dba2..eb024dd 100644
--- a/third_party/threads/threads.h
+++ b/third_party/threads/threads.h
@@ -117,7 +117,7 @@ typedef pthread_once_t once_flag;
/* types */
typedef void (*tss_dtor_t)(void*);
-typedef int (*thrd_start_t)(void*);
+typedef int (__stdcall *thrd_start_t)(void*);
struct xtime {
time_t sec;
Sorry, I've been on PTO and I haven't caught up with email.
What is the problem here again?
We end up with stack corruption in test_wcore_error_thread_local().
The documentation indicates [1] that the function pointer passed to
_beginthreadex (in our third_party/threads code) should use __stdcall
calling
convention. I'm not entirely sure which/how many pieces we need to
annotate
due to the amount of function pointers passed around :'(
Actually _beginthreadex() is correctly setup, yet pack.func(pack.arg)
(from
impl_thrd_routine) may not be. So many functions passing around func
pointers
is making my head spin.
You should be able to reproduce by building waffle and giving 'make
check'* a try.
I will try to repro.
But this patch doesn't look right, because we don't call beginthreadex
with the thrd_start_t pointer. Instead we call _beginthreadex(
impl_thrd_routine), which does have the __stdcall already.
BTW, this code is being used in llvmpipe's multi-threaded rasterized and
it is known to work.
I suspect the problem is elsewhere.
This is the problem:
thrd_join(threads[i], (int *) &exit_codes[i]);
a bool takes one byte, where as int takes four.
If the cast wasn't here the compiler would have warned about the type
mismtach.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/4] wgl: attempt to fix the final test
On 19/08/14 14:43, Emil Velikov wrote:
On 19/08/14 14:34, Emil Velikov wrote:
On 19/08/14 13:42, Jose Fonseca wrote:
On 12/08/14 16:37, Emil Velikov wrote:
MSVC helps us out with the final test by undicating that we're
corrupting the stack, which begs the question - at which point are we
messing up with the calling conventions. This patch attempts to resolve
that yet the bug still persists :'(
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_error_unittest.c | 4
third_party/threads/threads.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/waffle/core/wcore_error_unittest.c
b/src/waffle/core/wcore_error_unittest.c
index 5176031..8b9b334 100644
--- a/src/waffle/core/wcore_error_unittest.c
+++ b/src/waffle/core/wcore_error_unittest.c
@@ -148,7 +148,11 @@ struct thread_arg {
};
/// The start routine given to threads in test wcore_error.thread_local.
+#if !defined(_WIN32)
static bool
+#else
+static bool __stdcall
+#endif
thread_start(struct thread_arg *a)
{
static const enum waffle_error error_codes[NUM_THREADS] = {
diff --git a/third_party/threads/threads.h b/third_party/threads/threads.h
index 4e7dba2..eb024dd 100644
--- a/third_party/threads/threads.h
+++ b/third_party/threads/threads.h
@@ -117,7 +117,7 @@ typedef pthread_once_t once_flag;
/* types */
typedef void (*tss_dtor_t)(void*);
-typedef int (*thrd_start_t)(void*);
+typedef int (__stdcall *thrd_start_t)(void*);
struct xtime {
time_t sec;
Sorry, I've been on PTO and I haven't caught up with email.
What is the problem here again?
We end up with stack corruption in test_wcore_error_thread_local().
The documentation indicates [1] that the function pointer passed to
_beginthreadex (in our third_party/threads code) should use __stdcall calling
convention. I'm not entirely sure which/how many pieces we need to annotate
due to the amount of function pointers passed around :'(
Actually _beginthreadex() is correctly setup, yet pack.func(pack.arg) (from
impl_thrd_routine) may not be. So many functions passing around func pointers
is making my head spin.
You should be able to reproduce by building waffle and giving 'make check'* a
try.
I will try to repro.
But this patch doesn't look right, because we don't call beginthreadex
with the thrd_start_t pointer. Instead we call _beginthreadex(
impl_thrd_routine), which does have the __stdcall already.
BTW, this code is being used in llvmpipe's multi-threaded rasterized and
it is known to work.
I suspect the problem is elsewhere.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/4] wgl: attempt to fix the final test
On 12/08/14 16:37, Emil Velikov wrote:
MSVC helps us out with the final test by undicating that we're
corrupting the stack, which begs the question - at which point are we
messing up with the calling conventions. This patch attempts to resolve
that yet the bug still persists :'(
Signed-off-by: Emil Velikov
---
src/waffle/core/wcore_error_unittest.c | 4
third_party/threads/threads.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/waffle/core/wcore_error_unittest.c
b/src/waffle/core/wcore_error_unittest.c
index 5176031..8b9b334 100644
--- a/src/waffle/core/wcore_error_unittest.c
+++ b/src/waffle/core/wcore_error_unittest.c
@@ -148,7 +148,11 @@ struct thread_arg {
};
/// The start routine given to threads in test wcore_error.thread_local.
+#if !defined(_WIN32)
static bool
+#else
+static bool __stdcall
+#endif
thread_start(struct thread_arg *a)
{
static const enum waffle_error error_codes[NUM_THREADS] = {
diff --git a/third_party/threads/threads.h b/third_party/threads/threads.h
index 4e7dba2..eb024dd 100644
--- a/third_party/threads/threads.h
+++ b/third_party/threads/threads.h
@@ -117,7 +117,7 @@ typedef pthread_once_t once_flag;
/* types */
typedef void (*tss_dtor_t)(void*);
-typedef int (*thrd_start_t)(void*);
+typedef int (__stdcall *thrd_start_t)(void*);
struct xtime {
time_t sec;
Sorry, I've been on PTO and I haven't caught up with email.
What is the problem here again?
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 02/18] pkg/archlinux: add mingw-w64-waffle package
No, I only peruse the excellent Archlinux's wiki sometimes, but I'm not
familiar with the actual distro, so I can't help.
Jose
From: Chad Versace
Sent: 31 July 2014 04:06
To: Emil Velikov; waffle@lists.freedesktop.org; Jose Fonseca
Subject: Re: [waffle] [PATCH 02/18] pkg/archlinux: add mingw-w64-waffle package
Emil, I can't get this PKGBUILD to build. What am I doing wrong?
I'm probably doing a lot wrong, because I've never used mingw before.
I installed all the dependencies listed in the PKGBUILD. Below
is a bash log that shows the build failures.
Jose, do you use Archlinux? Did you have any luck with this PKGBUILD?
On 07/22/2014 08:31 PM, Emil Velikov wrote:
> - Remove explicit build options (waffle has autodetection).
> - Correct the destination directories.
> - Bump mingw64-crt requirement 3.1.0-3 (fixes the strerror_s issue).
> - Build twice - once for cross-builds and second time for win32 usage.
>
> TODO:
> - Get CPack to amend the install prefix - fix the "build twice" issue.
> - Strip some/all of the binaries ?
> - Current package works of a local git repo. Rename to -git or
> convert to a release one ?
>
> Signed-off-by: Emil Velikov
> ---
> pkg/archlinux/mingw-w64-waffle/PKGBUILD | 80
> +
> 1 file changed, 80 insertions(+)
> create mode 100644 pkg/archlinux/mingw-w64-waffle/PKGBUILD
>
> diff --git a/pkg/archlinux/mingw-w64-waffle/PKGBUILD
> b/pkg/archlinux/mingw-w64-waffle/PKGBUILD
> new file mode 100644
> index 000..a2ebde5
> --- /dev/null
> +++ b/pkg/archlinux/mingw-w64-waffle/PKGBUILD
> @@ -0,0 +1,80 @@
> +# Maintainer: Chad Versace
> +
> +pkgname='mingw-w64-waffle'
> +pkgver='1.3.0'
> +pkgrel=1
> +pkgdesc='a library for choosing window system and OpenGL API at runtime
> (mingw-w64)'
> +arch=('any')
> +url='https://urldefense.proofpoint.com/v1/url?u=http://waffle-gl.github.io/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=szKb4hF2Ik5O%2FxpnFqwbR6XKOzdStURP37Ybmzik3Ng%3D%0A&s=a4d4d029b55bb3233c81f3316508d61c0ae85f648aa22b842aeeb07b0a6c580f'
> +license=('BSD')
> +
> +depends=(
> + 'mingw-w64-crt>=3.1.0-3'
> + )
> +makedepends=(
> + 'mingw-w64-cmake'
> +
> + # For building the docs.
> +# XXX: Add as soon as we enable docs/manpages
> +# 'libxslt'
> +# 'docbook-xsl'
> +
> + )
> +
> +options=('!strip' '!buildflags' 'staticlibs')
> +_architectures="i686-w64-mingw32 x86_64-w64-mingw32"
> +
> +srcroot=${HOME}/development/waffle
> +build() {
> + unset LDFLAGS
> + cd "${srcroot}"
> + msg "Building mingw-w64-waffle for cross-building"
> + for _arch in ${_architectures}; do
> +mkdir -p build-${_arch} && pushd build-${_arch}
> +${_arch}-cmake .. \
> + -DCMAKE_INSTALL_PREFIX=/usr/${_arch} \
> + -DCMAKE_INSTALL_LIBDIR=/usr/${_arch}/lib \
> + -DCMAKE_BUILD_TYPE=Release \
> + \
> + -Dwaffle_build_tests=0 \
> + -Dwaffle_build_manpages=0 \
> + -Dwaffle_build_htmldocs=0 \
> + -Dwaffle_build_examples=1
> +make
> +popd
> + done
> +
> + # There should be a better way to do this
> + msg "Building mingw-w64-waffle for native builds"
> + for _arch in ${_architectures}; do
> +mkdir -p "build-${_arch}-win" && pushd "build-${_arch}-win"
> +${_arch}-cmake .. \
> + -DCMAKE_INSTALL_PREFIX="" \
> + -DCMAKE_INSTALL_LIBDIR="lib" \
> + -DCMAKE_BUILD_TYPE=Release \
> + \
> + -Dwaffle_build_tests=0 \
> + -Dwaffle_build_manpages=0 \
> + -Dwaffle_build_htmldocs=0 \
> + -Dwaffle_build_examples=1
> +make
> +popd
> + done
> +}
> +
> +package() {
> + for _arch in ${_architectures}; do
> +cd "${srcroot}/build-${_arch}"
> +make DESTDIR="${pkgdir}" install
> +#${_arch}-strip --strip-unneeded "$pkgdir"/usr/${_arch}/bin/*.dll
> +#${_arch}-strip -g "$pkgdir"/usr/${_arch}/lib/*.a
> + done
> +
> + for _arch in ${_architectures}; do
> +cd "${srcroot}/build-${_arch}-win"
> +# Create Windows zip archives
> +make package
> + done
> +}
> +
> +# vim:set ts=2 sw=2 et:
Chad's build errors
$ git checkout evelikov/for-upstream-WGL
$ git log -1 --format=%H
ed2164dfb4ae6d957ef853c054357202ba60f883
$ cd pkg/archlinux/mingw-w64-waffle
$
$ # Do a mingw sanity test. It fails :(
$ cat sanity.c
int
main()
Re: [waffle] [PATCH 16/33] third_party/threads: import c11 threads emulation wrappers
On 21/07/14 17:45, Emil Velikov wrote: On 17/07/14 05:40, Chad Versace wrote: Emil, I'm finished reviewing for today, and am stopping here at patch 16. I'll resume reviewing tomorrow. I see that you're collecting reviewed-by tags and cleanups on versioned brancehs (for-upstream-3.*). I will defer cherry-picking patches off the mailing list onto master; and instead will wait for you to send merge requests, because I assume that was your intended workflow. If you want to do things differently, let me know. Hi Chad, I do not mind either way (cherry-picking or sending pull requests), I mostly work this way to have a form of an incremental build-up based on the feedback received. Changes in for-upstream-3.2: - addressed your initial comments - dropped patch 10 (add -fPIC for the whole of waffle) - updated patch 17 (introduce third_party/threads) to build with PIC - squashed two warnings in the threads library (separate commits so that I can get them back in mesa) - cleaned/simplified up the cmocka build to make it possible to make it buildable in cross-builds and/or windows A bit more work on separate branches - cleaned up a few cmocka warnings, sent the fixes upstream - not merged yet - de-duplicated the platform specific tests in gl_basic_test, having fun with porting run_testsuite() - fork(), waitpid()... to win32 - moved libEGL from link dependency to dlopen() at runtime - got bored of reading MS documents - added basic wgl support for piglit - might not be as straight forward as I expected, see below for more Brian, Jose, Short summary at my next obstacle and my current ideas/possible solutions piglit, glut and waffle: 1) waffle abstracts windows and gl management and is capable of returning the native objects (window, ctx...) 2) but does not do any input -> piglit + waffle uses linux (posix/unix?) specific input code. 1) My present WGL code does not have the *.get_native() hooks. Currently beating them into shape. 2) AFAICS there are ways to address the input issue a) rip out the glut completely and write Windows specific code for the input handling. I have close to zero experience in this area, any suggestions ? What would happen with other platforms using glut like MacOS ? Is it even possible to do that today ? b) rip out the glut GL parts but keep the input code in. Seems slightly messy and I'm not sure it will even work. Any ideas/suggestions on point 2 above ? I think that mixing GLUT with other stuff is a bad idea. Otherwise -- whether to add some input support to waffle or not -- is a design choice that Chad needs to make. On one hand most similar frameworks (GLUT, GLFW) tend to have input too. One the other hand. For GL testing (piglit/apitrace) probably it doesn't make much difference either way. At least for piglit/apitrace input is not really a must: in the "-auto" input is ignored, and in the non "-auto" mode we could simply put a Sleep() function instead of a wait-for-key, which would probably be good enough for most cases. (We could also read input from stdin, which can be done with portable C) Last but not least - which approach would be the best for getting the WGL code integrated upstream ? 1) one big code blob 2) commit one - empty skeleton, two - widows_create, three - window_show... 3) keep the series as is - small and gradual changes 4) other ? I'm leaning towards the third option, yet we're talking about ~25 commits. Perhaps the second would be a reasonable compromise ? Small and gradual changes are indeed nice to review. To commit them as is or squash is up to Chad -- I'm fine either way. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 00/18] Up-streaming the WGL support for waffle
On 23/07/14 04:31, Emil Velikov wrote: Hello all, I believe the title says it all - hopefully this series will be reasonably clean of hacks to be considered for inclusion. In summary: Patches 01-03: Add CPack module (for tarballs), Archlinux PKGBUILD script (ease building) and some documentation about building for Windows. Patches 04-13: The core of this series adding the WGL support. Patches 14-18: A collection of MSVC centric fixes. These can be applied before, after or interleaved with my earlier MSVC (inspired) fixes. Note: patches 08 and 13 break API/ABI in a non-backwards compatible way. Take a look and please shout if I was day-dreaming at some point and completely lost the plot :P The series is based on top of the for-upstream-3.2-pull branch and is available at the for-upstream-WGL branch in my repo. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=TCO1PBP8c3pcGqe6YQf9EOKYdi1A2hySr957beMziYA%3D%0A&s=1fdb53b6c56b1f15306be5f99b2c71192c3eacfd2b0eda1d5fd9da322b8883ae Other that the remarks I made separately, series looks good to me FWIW. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 06/18] wgl: implement display management
On 23/07/14 16:25, Jose Fonseca wrote:
On 23/07/14 04:31, Emil Velikov wrote:
Unlike GLX and EGL, WGL(Windows) does not have the concept of a display
in the sense used in waffle.
The 'root primitive' for WGL is a window with it's device context
which encapsulates the properties and capabilities of the device
doing the actual rendering (CPU or GPU).
As such we first need to create a unique window class that will be
used for all waffle windows, and then create the 'root' window.
The windows itself is disabled (cannot grab the input) and of zero
width and height.
While we're here make sure that we create a context, which will be
needed in a variety of cases - when we query the WGL extensions, as a
fallback context in waffle_get_proc_address...
v2: Bail out if we're using the GDI renderer.
Signed-off-by: Emil Velikov
---
src/waffle/wgl/wgl_display.c | 121
+-
src/waffle/wgl/wgl_display.h | 5 ++
src/waffle/wgl/wgl_platform.c | 41 ++
src/waffle/wgl/wgl_platform.h | 3 ++
4 files changed, 168 insertions(+), 2 deletions(-)
diff --git a/src/waffle/wgl/wgl_display.c b/src/waffle/wgl/wgl_display.c
index a51e538..e5317aa 100644
--- a/src/waffle/wgl/wgl_display.c
+++ b/src/waffle/wgl/wgl_display.c
@@ -25,25 +25,126 @@
#include
+#include
+#include
#include "wcore_error.h"
#include "wgl_display.h"
+#include "wgl_dl.h"
+#include "wgl_platform.h"
bool
wgl_display_destroy(struct wcore_display *wc_self)
{
struct wgl_display *self = wgl_display(wc_self);
-bool ok;
+bool ok = true;
if (!self)
return true;
-ok = wcore_display_teardown(wc_self);
+if (self->hWnd) {
+if (self->hglrc) {
+ok &= wglDeleteContext(self->hglrc);
+}
+
+if (self->hDC)
+ok &= ReleaseDC(self->hWnd, self->hDC);
+
+ok &= DestroyWindow(self->hWnd);
+}
+
+ok &= wcore_display_teardown(wc_self);
free(self);
return ok;
}
+static bool
+wgl_display_create_window(struct wgl_platform *plat, struct
wgl_display *dpy)
+{
+dpy->hWnd = CreateWindow(plat->class_name, NULL,
+ WS_POPUPWINDOW|WS_DISABLED,
+ 0, 0, 0, 0, NULL, NULL, NULL, NULL);
+if (!dpy->hWnd)
+return false;
+
+dpy->hDC = GetDC(dpy->hWnd);
+if (!dpy->hDC)
+return false;
+
+return true;
+}
+
+static bool
+wgl_display_choose_config(struct wgl_display *dpy)
+{
+// XXX: Is there a move common/approapriate pixelformat ?
approapriate -> appropriate
+PIXELFORMATDESCRIPTOR pfd = {
+sizeof(PIXELFORMATDESCRIPTOR),
+1,
+PFD_SUPPORT_OPENGL |
+PFD_DRAW_TO_WINDOW |
+PFD_DOUBLEBUFFER,
+PFD_TYPE_RGBA,
+32,
+0, 0, 0, 0, 0, 0,
+0,
+0,
+0,
+0, 0, 0, 0,
+16,
+0,
+0,
+PFD_MAIN_PLANE,
+0,
+0, 0, 0,
It's hard to interpret this like this. memset(0) and then writing the
fiels would make the code smaller and easier to read.
You should ensure that cStencilBits is not zero, otherwise you might not
get a stencil buffer, which will cause problems.
I now see this is only used for initialization. So I suppose it doesn't
really matter.
Jose
See
https://urldefense.proofpoint.com/v1/url?u=https://github.com/apitrace/apitrace/blob/master/retrace/glws_wgl.cpp%23L218&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=tyTB22tb8qXxlAjtC9yppkPcm8bpett7KDrGHrMprfc%3D%0A&s=b8108e8bcaaa6738b851b786ed1d5baf2a4c13aef3362da9e1801016fda7
for reference.
+};
+bool ok;
+
+dpy->pixel_format = ChoosePixelFormat(dpy->hDC, &pfd);
+if (!dpy->pixel_format)
+return false;
+
+ok = SetPixelFormat(dpy->hDC, dpy->pixel_format, &pfd);
+if (!ok)
+return false;
+
+return true;
+}
+
+static bool
+wgl_display_hardware_render(struct wgl_display *dpy)
+{
+#ifndef GL_RENDERER
+#define GL_RENDERER 0x1F01
+#endif
+typedef unsigned int GLenum;
+typedef unsigned char GLubyte;
+typedef const GLubyte * (__stdcall *PFNGLGETSTRINGPROC)(GLenum
name);
+
+PFNGLGETSTRINGPROC glGetString_func;
+const GLubyte *gl_renderer;
+bool ok;
+
+glGetString_func = wgl_dl_sym(dpy->wcore.platform,
WAFFLE_DL_OPENGL, "glGetString");
+if (!glGetString_func)
+return false;
+
+ok = wglMakeCurrent(dpy->hDC, dpy->hglrc);
+if (!ok)
+return false;
+
+gl_renderer = glGetString_func(GL_RENDERER);
+ok = wglMakeCurrent(NULL, NULL);
+if (!ok)
+return false;
+
+// Bail out if we cannot retrieve the renderer string or if we're
using GDI
+if (!gl_renderer || strcasecmp((const
Re: [waffle] [PATCH 06/18] wgl: implement display management
On 23/07/14 04:31, Emil Velikov wrote:
Unlike GLX and EGL, WGL(Windows) does not have the concept of a display
in the sense used in waffle.
The 'root primitive' for WGL is a window with it's device context
which encapsulates the properties and capabilities of the device
doing the actual rendering (CPU or GPU).
As such we first need to create a unique window class that will be
used for all waffle windows, and then create the 'root' window.
The windows itself is disabled (cannot grab the input) and of zero
width and height.
While we're here make sure that we create a context, which will be
needed in a variety of cases - when we query the WGL extensions, as a
fallback context in waffle_get_proc_address...
v2: Bail out if we're using the GDI renderer.
Signed-off-by: Emil Velikov
---
src/waffle/wgl/wgl_display.c | 121 +-
src/waffle/wgl/wgl_display.h | 5 ++
src/waffle/wgl/wgl_platform.c | 41 ++
src/waffle/wgl/wgl_platform.h | 3 ++
4 files changed, 168 insertions(+), 2 deletions(-)
diff --git a/src/waffle/wgl/wgl_display.c b/src/waffle/wgl/wgl_display.c
index a51e538..e5317aa 100644
--- a/src/waffle/wgl/wgl_display.c
+++ b/src/waffle/wgl/wgl_display.c
@@ -25,25 +25,126 @@
#include
+#include
+#include
#include "wcore_error.h"
#include "wgl_display.h"
+#include "wgl_dl.h"
+#include "wgl_platform.h"
bool
wgl_display_destroy(struct wcore_display *wc_self)
{
struct wgl_display *self = wgl_display(wc_self);
-bool ok;
+bool ok = true;
if (!self)
return true;
-ok = wcore_display_teardown(wc_self);
+if (self->hWnd) {
+if (self->hglrc) {
+ok &= wglDeleteContext(self->hglrc);
+}
+
+if (self->hDC)
+ok &= ReleaseDC(self->hWnd, self->hDC);
+
+ok &= DestroyWindow(self->hWnd);
+}
+
+ok &= wcore_display_teardown(wc_self);
free(self);
return ok;
}
+static bool
+wgl_display_create_window(struct wgl_platform *plat, struct wgl_display *dpy)
+{
+dpy->hWnd = CreateWindow(plat->class_name, NULL,
+ WS_POPUPWINDOW|WS_DISABLED,
+ 0, 0, 0, 0, NULL, NULL, NULL, NULL);
+if (!dpy->hWnd)
+return false;
+
+dpy->hDC = GetDC(dpy->hWnd);
+if (!dpy->hDC)
+return false;
+
+return true;
+}
+
+static bool
+wgl_display_choose_config(struct wgl_display *dpy)
+{
+// XXX: Is there a move common/approapriate pixelformat ?
approapriate -> appropriate
+PIXELFORMATDESCRIPTOR pfd = {
+sizeof(PIXELFORMATDESCRIPTOR),
+1,
+PFD_SUPPORT_OPENGL |
+PFD_DRAW_TO_WINDOW |
+PFD_DOUBLEBUFFER,
+PFD_TYPE_RGBA,
+32,
+0, 0, 0, 0, 0, 0,
+0,
+0,
+0,
+0, 0, 0, 0,
+16,
+0,
+0,
+PFD_MAIN_PLANE,
+0,
+0, 0, 0,
It's hard to interpret this like this. memset(0) and then writing the
fiels would make the code smaller and easier to read.
You should ensure that cStencilBits is not zero, otherwise you might not
get a stencil buffer, which will cause problems.
See
https://github.com/apitrace/apitrace/blob/master/retrace/glws_wgl.cpp#L218
for reference.
+};
+bool ok;
+
+dpy->pixel_format = ChoosePixelFormat(dpy->hDC, &pfd);
+if (!dpy->pixel_format)
+return false;
+
+ok = SetPixelFormat(dpy->hDC, dpy->pixel_format, &pfd);
+if (!ok)
+return false;
+
+return true;
+}
+
+static bool
+wgl_display_hardware_render(struct wgl_display *dpy)
+{
+#ifndef GL_RENDERER
+#define GL_RENDERER 0x1F01
+#endif
+typedef unsigned int GLenum;
+typedef unsigned char GLubyte;
+typedef const GLubyte * (__stdcall *PFNGLGETSTRINGPROC)(GLenum name);
+
+PFNGLGETSTRINGPROC glGetString_func;
+const GLubyte *gl_renderer;
+bool ok;
+
+glGetString_func = wgl_dl_sym(dpy->wcore.platform, WAFFLE_DL_OPENGL,
"glGetString");
+if (!glGetString_func)
+return false;
+
+ok = wglMakeCurrent(dpy->hDC, dpy->hglrc);
+if (!ok)
+return false;
+
+gl_renderer = glGetString_func(GL_RENDERER);
+ok = wglMakeCurrent(NULL, NULL);
+if (!ok)
+return false;
+
+// Bail out if we cannot retrieve the renderer string or if we're using GDI
+if (!gl_renderer || strcasecmp((const char *)gl_renderer, "GDI Generic")
== 0)
+return false;
+
+return true;
+}
struct wcore_display*
wgl_display_connect(struct wcore_platform *wc_plat,
@@ -60,6 +161,22 @@ wgl_display_connect(struct wcore_platform *wc_plat,
if (!ok)
goto error;
+ok = wgl_display_create_window(wgl_platform(wc_plat), self);
+if (!ok)
+goto error;
+
+ok = wgl_display_choose_config(self);
+if (!ok)
+goto error;
+
+self->hglrc = wglCreateContext(self->hDC);
+if (!self->hglrc)
+goto error;
+
+ok = wgl_display_hardware_render(s
Re: [waffle] [PATCH 15/18] cmake: prefix the waffle dll with "lib" similar to other platforms
On 23/07/14 04:31, Emil Velikov wrote:
XXX: What about the static library (waffle-1.lib) ?
Signed-off-by: Emil Velikov
---
src/waffle/CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/waffle/CMakeLists.txt b/src/waffle/CMakeLists.txt
index 9507398..d348cb6 100644
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -183,6 +183,7 @@ target_link_libraries(${waffle_libname} ${waffle_libdeps})
set_target_properties(${waffle_libname}
PROPERTIES
+ PREFIX "lib"
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
SOVERSION ${waffle_soversion}
VERSION
${waffle_soversion}.${waffle_minor_version}.${waffle_patch_version}
This may be consistent with other platforms, but it is not very
consistent with Windows platform normal practice, which IMO is a more
important consistency. That said, it would not be the first or last
time that a project uses the lib prefix on Windows dlls. So no a big
deal either way.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 03/18] README_WIN: add some notes about configuring and building WGL
On 23/07/14 04:31, Emil Velikov wrote:
TODO:
- Fill in the missing sections.
- Move to a better place.
- Double-check for typos and thinkos.
Signed-off-by: Emil Velikov
---
README_WIN.txt | 157 +
1 file changed, 157 insertions(+)
create mode 100644 README_WIN.txt
diff --git a/README_WIN.txt b/README_WIN.txt
new file mode 100644
index 000..3665259
--- /dev/null
+++ b/README_WIN.txt
@@ -0,0 +1,157 @@
+Build Requirements
+==
+
+Windows
+---
+
+Cross-building under Linux
+--
+
+Waffle uses CMake for it build system.
+
+Archlinux: pacman -S cmake
+Fedora 17: yum install cmake
+Debian: apt-get install cmake
+
+The MinGW-W64 cross-build toolchain is recommended and its CMake wrapper.
+
+Archlinux: pacman -S mingw-w64-gcc mingw-w64-cmake (latter is in AUR)
+Fedora 17: yum install FINISHME
+Debian: apt-get install FINISHME
+
+
+Native builds
+-
+
+Waffle is heavily requires on the C99 standard. As such only reasonable
+compiler (at the time of writing) from the Microsoft Visual Compiler
+series is MSVC 2013. Building with older versions is likely to be broken.
+
+Waffle is not tested to build under CYGWIN. The build is likely to be
+broken. Patches addressing it are more than welcome.
+
+
+Installing
+==
+
+For full details on configuring, building, and installing Waffle, see
+/doc/building.txt. What follows is a quick how-to.
+
+
+0. Be in the correct directory
+--
+
+git clone git://github.com/waffle-gl/waffle
+cd waffle
+
+or
+
+tar xvf waffle-0.0.0.tar.xz
+cd waffle-0.0.0
+
+
+1. Configure
+
+
+Currently tests are known to be broken. Make sure to pass the following
+cofigure option to avoid building them `-Dwaffle_build_tests=0`
+
+Cross-building under Linux
+--
+
+_architectures="i686-w64-mingw32 x86_64-w64-mingw32"
+unset LDFLAGS
+for _arch in ${_architectures}; do
+ _install_prefix=/usr/${_arch}
+ mkdir -p build-${_arch} && pushd build-${_arch}
+ ${_arch}-cmake .. \
+-DCMAKE_INSTALL_PREFIX=${_install_prefix} \
+-DCMAKE_INSTALL_LIBDIR=${_install_prefix}/lib \
+-DCMAKE_BUILD_TYPE=Release \
+\
+-Dwaffle_build_tests=0 \
+-Dwaffle_build_manpages=0 \
+-Dwaffle_build_htmldocs=0 \
+-Dwaffle_build_examples=1
+ make
+ popd
+done
+
+Make sure to adjust _install_prefix to "" if the resulting library will
+not be used for further cross-building.
+
+
+Native builds
+-
+
+@if "%VS120COMNTOOLS%"=="" exit /b 127
+call "%VS120COMNTOOLS%\..\..\VC\vcvarsall.bat" x86
This is unnecessary when using "Visual Studio 12" or ""Visual Studio 12
Win64" generators -- cmake will call this batch file internally already.
+
+cmake -G "Visual Studio 12" -H%CD% -B%CD%\build\msvc32
-DCMAKE_INSTALL_PREFIX=""
+@if %errorlevel% neq 0 exit /b %errorlevel%
+
+call "%VS120COMNTOOLS%\..\..\VC\vcvarsall.bat" x64
+
+cmake -G "Visual Studio 12" -H%CD% -B%CD%\build\msvc64
-DCMAKE_INSTALL_PREFIX=""
+@if %errorlevel% neq 0 exit /b %errorlevel%
"Visual Studio 12" -> "Visual Studio 12 Win64"
+
+If building a Windows XP compatible library make sure to add
+`-T "v120_xp"` after the generator. For example:
+cmake -G "Visual Studio 12" -T "v120_xp" -H%CD% ...
+
+
+3. Build and Install
+
+
+
+Cross-building under Linux
+--
+
+_architectures="i686-w64-mingw32 x86_64-w64-mingw32"
+unset LDFLAGS
+for _arch in ${_architectures}; do
+ pushd build-${_arch}
+ make
+ make install
+ popd
+done
+
+Note: Running tests (make check and make check-func) are not tested but
+may work if the approapriate environment is setup via wine.
+
+
+
+Native builds
+-
+
+@if "%VS120COMNTOOLS%"=="" exit /b 127
+call "%VS120COMNTOOLS%\..\..\VC\vcvarsall.bat" x86
+
+cmake --build %CD%\build\msvc32 --config Debug %*
+@if %errorlevel% neq 0 exit /b %errorlevel%
+
+call "%VS120COMNTOOLS%\..\..\VC\vcvarsall.bat" x64
+
+cmake --build %CD%\build\msvc64 --config Debug %*
+@if %errorlevel% neq 0 exit /b %errorlevel%
Isn't this duplicate info?
Instead of breaking things into "build" "install" and "package", I'd
first break things into platform, and then, internally split into build
install package. Otherwise people need to jump back forth alot
unnecessarily. Plus there's a lof of duplication.
+
+4. Package
+--
+
+Cross-building under Linux
+--
+
+_architectures="i686-w64-mingw32 x86_64-w64-mingw32"
+unset LDFLAGS
+for _arch in ${_architectures}; do
+ pushd build-${_arch}
+ make package
+ popd
+done
+
+
+Native builds
+-
+
+ WRITE ME
_
Re: [waffle] [PATCH 10/33] cmake: build with fPIC when possible
On 17/07/14 05:22, Chad Versace wrote:
On 07/15/2014 07:44 AM, Jose Fonseca wrote:
On 07/07/14 18:28, Emil Velikov wrote:
Some of our third_party libraries may be build without it thus we'll
fail at
link tim.
Signed-off-by: Emil Velikov
---
cmake/Modules/WaffleDefineCompilerFlags.cmake | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmake/Modules/WaffleDefineCompilerFlags.cmake
b/cmake/Modules/WaffleDefineCompilerFlags.cmake
index 4d149c8..96a7a10 100644
--- a/cmake/Modules/WaffleDefineCompilerFlags.cmake
+++ b/cmake/Modules/WaffleDefineCompilerFlags.cmake
@@ -50,6 +50,8 @@ if(waffle_on_linux)
waffle_add_c_flag("-Werror=missing-prototypes"
WERROR_MISSING_PROTOTYPES)
endif()
+waffle_add_c_flag("-fPIC" WITH_FPIC)
+
waffle_check_thread_local_storage()
if(waffle_has_tls)
Another way of fixing this is doing like in Apitrace:
-
https://urldefense.proofpoint.com/v1/url?u=https://github.com/apitrace/apitrace/blob/master/cmak/ConvenienceLibrary.cmake&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=ZXpgDERxJiJIOkLmgiWyvvdFCmOYeacV64waeZuyXto%3D%0A&s=550e80c43976ae6b7767b413f4500e1b92725f7ba8c82a921682e3c4913c2e04
-
https://urldefense.proofpoint.com/v1/url?u=https://github.com/apitrace/apitrace/commit/c56b9acc6abcae465b916f6ebafa3a282d1f36fc&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=ZXpgDERxJiJIOkLmgiWyvvdFCmOYeacV64waeZuyXto%3D%0A&s=3c0e0609776f678836fd6485f5485299a1ae228c092c74abfbecdbb67c434c5d
This gives more control. For example, unlike a blanket -FPIC flag,
executables won't be needlessly compiled with FPIC.
Jose, your add_convenience_library() function may be unneeded. See the
manpage quote below.
You're right. Setting POSITION_INDEPENDENT_CODE property is much
simpler/cleaner. (Though I still find it convienent to have a
add_convenience_library for the time being, as there are a bunch of such
libraries in apitrace so it provides me a centralized place for these
tweaks):
https://github.com/apitrace/apitrace/commit/d99553937cc53b82965421da1ca950c17f16a324
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Some new and old fixes
On 15/07/14 18:14, Emil Velikov wrote: On 15/07/14 17:30, Jose Fonseca wrote: On 15/07/14 17:22, Emil Velikov wrote: On 15/07/14 15:35, Jose Fonseca wrote: On 07/07/14 18:28, Emil Velikov wrote: Hi all, After respinning the latest changes (and ripping out WGL as it requires some api/abi changes) here is a lovely list of fixes that gets us closer to building waffle with mingw/msvc. The first four patches are old (three cgl fixes that Chad would like to test prior to pushing them + a patch from Chad). Then a few misc fixes (not related to win32/mingw/msvc) followed by the addition of c99_compat header (inspired by mesa) and a couple of third_party util libs. The last 13 or so patches cover msvc quirks where it should work but instead it dies agony. Please give the series a look and/or bash. Currently is available at https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=27d08d81fd336f9617452db8811cafefdc23443a9858d65d0981c3248160b538 in the for-upstream-3 branch. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=b976daaa17d48cd129ecda15d09768b1a9d4196151bd4a92da50a2a6fa28af73 I tried to build this branch with mingw/msvc but I get CMake Error at cmake/Modules/WaffleDefineOS.cmake:31 (message): Unrecognized CMAKE_SYSTEM_NAME="Windows" Is that expected? Jose Yes that is expected as these patches (the branch) do _not_ include WGL support but are generic fixes. I would like to get the WGL in soon after this yet that will require version bump as I have introduced a couple API changes. Meanwhile if you're around I would appreciate if you can give me some tips on how to get msvc 2013 non *_xp platform working. This is why I wanted to build it myself -- so I can try to repro whatever problems you're having. As mentioned previously the problem is not specific to waffle. A blank Hello World C project exhibits the same issue. The patches + wgl can be found at branch temp - note it's very messy in there :\ IMO, it would be better the patches to enable building with MSVC are commited before, and not after, the generic patches. So that people other than yourself can try build it, and verify that your patches do what's expected. Ack. Will take a look at squashing WGL into a few commits and getting those in as well ASAP. I have installed the following (in the exact order) * Win 7 64bit Professional * MSVC 2013 Ultimate * Microsoft Visual Studio 2013 SDK I'm not sure what this "Visual Studio 2013 SDK" is, but I doubt it's necessary. AFAIK the package provides of the basic windows sdk. Without it there is not even a single core header/import library (windows.h, kernel.lib...) present on my harddrive. And obviously no C programs that rely on those manage to build. Very weird. I made a very simple cmake hello world and uploaded to http://people.freedesktop.org/~jrfonseca/cmake-msvc/ . Run build.cmd. http://people.freedesktop.org/~jrfonseca/cmake-msvc/build.log is what I got here. MFC seems to work, I'm assuming that .NET works as well _without_ the sdk :\ The normal (v120) platform toolkit complains about missing headers (including windows.h) and import libraries. I have yet to find any useful information on the web about MSVC 2013, and all the "fixes" are not helping - "copy everything from the xp profile to the normal one" or "format and reinstall everything including windows". If you know a certain setup (the non-ultimate compiler ?)/install order or other way of resolving this I'm all ears. I've spend 3+ days on this already :\ I have Visual Studio Ultimate 2013 and it works fine. I would appreciate if you can find out where SDKDDKVer.h and windows.h are located for the v120 toolset and which program provided them. Here it is: > call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\\..\..\VC\vcvarsall.bat" x86 > echo INCLUDE=%INCLUDE% INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE;C:\Program Files (x 86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt; > dir "c:\Program Files (x86)\Windows Kits\8.1\Include\um\windows.h" Volume in drive C has no label. Volume Serial Number is 2E86-CC19 Directory of c:\Program Files (x86)\Windows Kit
Re: [waffle] Some new and old fixes
On 15/07/14 17:22, Emil Velikov wrote: On 15/07/14 15:35, Jose Fonseca wrote: On 07/07/14 18:28, Emil Velikov wrote: Hi all, After respinning the latest changes (and ripping out WGL as it requires some api/abi changes) here is a lovely list of fixes that gets us closer to building waffle with mingw/msvc. The first four patches are old (three cgl fixes that Chad would like to test prior to pushing them + a patch from Chad). Then a few misc fixes (not related to win32/mingw/msvc) followed by the addition of c99_compat header (inspired by mesa) and a couple of third_party util libs. The last 13 or so patches cover msvc quirks where it should work but instead it dies agony. Please give the series a look and/or bash. Currently is available at https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=27d08d81fd336f9617452db8811cafefdc23443a9858d65d0981c3248160b538 in the for-upstream-3 branch. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=b976daaa17d48cd129ecda15d09768b1a9d4196151bd4a92da50a2a6fa28af73 I tried to build this branch with mingw/msvc but I get CMake Error at cmake/Modules/WaffleDefineOS.cmake:31 (message): Unrecognized CMAKE_SYSTEM_NAME="Windows" Is that expected? Jose Yes that is expected as these patches (the branch) do _not_ include WGL support but are generic fixes. I would like to get the WGL in soon after this yet that will require version bump as I have introduced a couple API changes. Meanwhile if you're around I would appreciate if you can give me some tips on how to get msvc 2013 non *_xp platform working. This is why I wanted to build it myself -- so I can try to repro whatever problems you're having. IMO, it would be better the patches to enable building with MSVC are commited before, and not after, the generic patches. So that people other than yourself can try build it, and verify that your patches do what's expected. I have installed the following (in the exact order) * Win 7 64bit Professional * MSVC 2013 Ultimate * Microsoft Visual Studio 2013 SDK I'm not sure what this "Visual Studio 2013 SDK" is, but I doubt it's necessary. The normal (v120) platform toolkit complains about missing headers (including windows.h) and import libraries. I have yet to find any useful information on the web about MSVC 2013, and all the "fixes" are not helping - "copy everything from the xp profile to the normal one" or "format and reinstall everything including windows". If you know a certain setup (the non-ultimate compiler ?)/install order or other way of resolving this I'm all ears. I've spend 3+ days on this already :\ I have Visual Studio Ultimate 2013 and it works fine. Thanks Emil Which cmake version are you using? Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Some new and old fixes
On 15/07/14 15:35, Jose Fonseca wrote: On 07/07/14 18:28, Emil Velikov wrote: Hi all, After respinning the latest changes (and ripping out WGL as it requires some api/abi changes) here is a lovely list of fixes that gets us closer to building waffle with mingw/msvc. The first four patches are old (three cgl fixes that Chad would like to test prior to pushing them + a patch from Chad). Then a few misc fixes (not related to win32/mingw/msvc) followed by the addition of c99_compat header (inspired by mesa) and a couple of third_party util libs. The last 13 or so patches cover msvc quirks where it should work but instead it dies agony. Please give the series a look and/or bash. Currently is available at https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=27d08d81fd336f9617452db8811cafefdc23443a9858d65d0981c3248160b538 in the for-upstream-3 branch. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=b976daaa17d48cd129ecda15d09768b1a9d4196151bd4a92da50a2a6fa28af73 I tried to build this branch with mingw/msvc but I get CMake Error at cmake/Modules/WaffleDefineOS.cmake:31 (message): Unrecognized CMAKE_SYSTEM_NAME="Windows" Is that expected? Jose ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=YJhITSIo0uXhla76OWwW3MvMqY%2By%2B%2FdnBUwx2AJ8Yzk%3D%0A&s=74e7919dffab8644485f15fc31efda736dabd5df8d20c9707f9408543fe8760e Anyway, patches look good to me AFAICT. Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 10/33] cmake: build with fPIC when possible
On 07/07/14 18:28, Emil Velikov wrote:
Some of our third_party libraries may be build without it thus we'll fail at
link tim.
Signed-off-by: Emil Velikov
---
cmake/Modules/WaffleDefineCompilerFlags.cmake | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmake/Modules/WaffleDefineCompilerFlags.cmake
b/cmake/Modules/WaffleDefineCompilerFlags.cmake
index 4d149c8..96a7a10 100644
--- a/cmake/Modules/WaffleDefineCompilerFlags.cmake
+++ b/cmake/Modules/WaffleDefineCompilerFlags.cmake
@@ -50,6 +50,8 @@ if(waffle_on_linux)
waffle_add_c_flag("-Werror=missing-prototypes" WERROR_MISSING_PROTOTYPES)
endif()
+waffle_add_c_flag("-fPIC" WITH_FPIC)
+
waffle_check_thread_local_storage()
if(waffle_has_tls)
Another way of fixing this is doing like in Apitrace:
-
https://github.com/apitrace/apitrace/blob/master/cmak/ConvenienceLibrary.cmake
-
https://github.com/apitrace/apitrace/commit/c56b9acc6abcae465b916f6ebafa3a282d1f36fc
This gives more control. For example, unlike a blanket -FPIC flag,
executables won't be needlessly compiled with FPIC.
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Some new and old fixes
On 07/07/14 18:28, Emil Velikov wrote: Hi all, After respinning the latest changes (and ripping out WGL as it requires some api/abi changes) here is a lovely list of fixes that gets us closer to building waffle with mingw/msvc. The first four patches are old (three cgl fixes that Chad would like to test prior to pushing them + a patch from Chad). Then a few misc fixes (not related to win32/mingw/msvc) followed by the addition of c99_compat header (inspired by mesa) and a couple of third_party util libs. The last 13 or so patches cover msvc quirks where it should work but instead it dies agony. Please give the series a look and/or bash. Currently is available at https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=27d08d81fd336f9617452db8811cafefdc23443a9858d65d0981c3248160b538 in the for-upstream-3 branch. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0A&s=b976daaa17d48cd129ecda15d09768b1a9d4196151bd4a92da50a2a6fa28af73 I tried to build this branch with mingw/msvc but I get CMake Error at cmake/Modules/WaffleDefineOS.cmake:31 (message): Unrecognized CMAKE_SYSTEM_NAME="Windows" Is that expected? Jose ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC2014] Current design/implementation + the infamous corruption
- Original Message -
> On 06/06/14 14:00, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> 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://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=a2j0YKhUfDCeKnrHMRWtbX2GGkBhvFdRuL%2BmYYiIN7g%3D%0A&s=653132e086e89788df300b121854441a78291782135936411a4a6254e6959c6a
> >>>
> >>> 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
> &g
Re: [waffle] [GSOC2014] Current design/implementation + the infamous corruption
- Original Message -
> 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://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=a2j0YKhUfDCeKnrHMRWtbX2GGkBhvFdRuL%2BmYYiIN7g%3D%0A&s=653132e086e89788df300b121854441a78291782135936411a4a6254e6959c6a
> >
> > 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.
Good catch.
> Annotating properly makes the gl_basic test work like a charm.
That's great progres!
>
> AFAICS waffle_get_proc_address is in the same boat. Will need to test.
>
> Cheers,
> 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
- Original Message - > > > - Original Message - > > On Wed, Jun 4, 2014 at 1:18 PM, 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 > > >> > > > >> > wrote: > > >> > > On 25/05/14 21:35, Jordan Justen wrote: > > >> > >> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov > > >> > >> 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.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=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 > > >> > >> > > >
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 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 > >> > wrote: > >> > > On 25/05/14 21:35, Jordan Justen wrote: > >> > >> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov > >> > >> 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.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=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).
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
- 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.c&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=EVvdAN6DpAMPSYORbM%2BCu4MTEMmLt5L7XFRXd%2Be9PvI%3D%0A&s=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 Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote: > > On Sun, May 25, 2014 at 2:43 PM, Emil Velikov > > wrote: > > > On 25/05/14 21:35, Jordan Justen wrote: > > >> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov > > >> 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.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=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 -
>
>
> - 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.
> >
> > > 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.
Just to be clear. This assumption will break when there are multiple GPUs on
the system (each CPU connected to a different display). Anyway, getting OpenGL
to work across multiple GPU (if you move the window from one display to another
bad things will probably happen.)
The reason that wglGetProcAddress requires window/context is because only then
will OPENGL32.DLL know which ICD DLL to load.
Jose
>
> 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.
>
> 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.c&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0wQO1piBosOhNBZDdl%2BT8GwfFTwzNeXzcfSU4blnn3Y%3D%0A&s=3fda70fe594796e7a321251f57a9109fdadb56f13a9ded7a1a56aed7010779a3
> 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.
> > >
> > I'm planning to give the "cache the windows" a stab soon, although
> > I would greatly appreciate if anyone has an opinion/comment.
> >
> > >
> > > * CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
> > >
> > >
> > > * Thread-safe and Co.
> > > AFAICS it's used to provide thread independent waffle error info. Have I
> > > missed something ?
> > >
> > >- strerror_r is depreciated in favour of strerror_s. MS claims that
> > >the
> > > former is not TS, while *nix man page disagrees.
> > >
> > >- Current mingw-w64 build does not work on Win XP - missing
> > >strerror_s.
> > > Fix landed in mingw-w64 trunk ~a few weeks ago.
> > >
> > >- Back-port commit and build things with custom mingw_w64
> > >- or, port the commit over to waffle ?
> > >
> > > Suggestion:
> > > Port over to waffle.
> > >
> > The commit addressing strerror_s + mingw-w64 + WinXP has been backported to
> > the stable branch of mingw-w64. We can mandate that version (to be
> > released)
> > as the minimum requirement in the readme/build-scripts.
> >
> > >
> > > * 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
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
- 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.
>
> > 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.
You can see in
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
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.
> >
> I'm planning to give the "cache the windows" a stab soon, although
> I would greatly appreciate if anyone has an opinion/comment.
>
> >
> > * CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
> >
> >
> > * Thread-safe and Co.
> > AFAICS it's used to provide thread independent waffle error info. Have I
> > missed something ?
> >
> >- strerror_r is depreciated in favour of strerror_s. MS claims that the
> > former is not TS, while *nix man page disagrees.
> >
> >- Current mingw-w64 build does not work on Win XP - missing strerror_s.
> > Fix landed in mingw-w64 trunk ~a few weeks ago.
> >
> >- Back-port commit and build things with custom mingw_w64
> >- or, port the commit over to waffle ?
> >
> > Suggestion:
> > Port over to waffle.
> >
> The commit addressing strerror_s + mingw-w64 + WinXP has been backported to
> the stable branch of mingw-w64. We can mandate that version (to be released)
> as the minimum requirement in the readme/build-scripts.
>
> >
> > * 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
> > - 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.
> >
> As spotted by Jordan, there should be no implications of static linking with
> libgcc[1]. I've added a couple of lines to the build and so far it works like
> a charm.
>
> [1]
> https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=nPzAHYznyFhyA6Bn%2FXHt2AeHO%2FNhVm9VWwNYkwnEmIc%3D%0A&s=f1ea3aad8cc771542f8ab3be427e2335d4486e0516e7e738e83019b3457a475c
>
> >
> > Library:
> > libwinpthread-1
> >pthread_key_
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
Sorry for the late reply. I missed you first email somehow.
- Original Message -
> Hi all,
>
> Another round of interesting bits and bulbs.
>
> 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.
>
> Options:
> - Create a window, choose format, destroy window.
> No guarantee that the function will behave the same for another
> window/device_context.
>
> - 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.
>
>
> * CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
>
>
> * Thread-safe and Co.
> AFAICS it's used to provide thread independent waffle error info. Have I
> missed something ?
>
>- strerror_r is depreciated in favour of strerror_s. MS claims that the
> former is not TS, while *nix man page disagrees.
>
>- Current mingw-w64 build does not work on Win XP - missing strerror_s.
> Fix landed in mingw-w64 trunk ~a few weeks ago.
>
>- Back-port commit and build things with custom mingw_w64
>- or, port the commit over to waffle ?
>
> Suggestion:
> Port over to waffle.
>
>
> * 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
I personally use --static-libgcc and -static-libstdc++ to avoid DLL
dependencies on MINGW. But for example the MinGW binaries for Qt depend on
them. It's probably not a big issue either way. We could put an CMAKE option
to control this.
> Options:
> - Static link libgcc_s, generally not bad idea
> - 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
> - or, rebuild mingw-w64-gcc with --enable-threads=win32
> - or, rework current code (open to suggestions)?
I'm pretty disapointed MinGW introduced this dependency. I actually reverted
my MinGW compilers to gcc-4.6 to avoid getting caught by this.
Either way, I wouldn't worry too much about this. Sooner or later somebody
will manage to get MSVC builds.
At very least we must provide MSVC import libaries, as MSVC linker can't link
to DLL directly.
> Suggestion:
> The above list states my order of preference.
>
>
> Any feedback would be great. Meanwhile I will send out a few misc/cleanup
> patches :)
>
> Cheers,
> Emil
>
Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/8] Move WAFFLE_API out of the public header + misc patches
The Windows specifc change (patch 7) looks good. The rest looks sensible too FWIW, but I'm not the best person to comment, as I'm not yet familiar with the code base. Jose - Original Message - > Hi all, > > Here is a small selection of patches - mostly bugfixes, while going > though waffle's existing implementations and working on wgl. > > The series is available in the for-upstream branch at my github repo > https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0A&s=f2626a50efbe287b107032398cfe8476bdd29d71fac039eebfec609cd9f97b2f > > Comments, tips and suggestions are greatly appreciated. > > Cheers, > Emil > ___ > waffle mailing list > waffle@lists.freedesktop.org > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/waffle&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0A&s=bf956564e315c2ca8e8da1e6e0c16a7758a2c1e8ef7bb1b9c3bfcdf84825b038 > ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Windows library is almost up
- Original Message - > Hi guys, > > A bit of update + a couple of questions: > > 1. Modified cmake build. Now we have a windows libraries (cross-compiled > with > mingw-w64). > > - Why do we use absolute paths for the install targets ? I believe that > (cmake guys confirmed) one should normally use relative ones. Yes, I suppose that for things like producing windows zip packages relative paths will be needed. > - To the best of my knowledge one should not define symbols such as > WAFFLE_API/restrict in public headers. Is that intentional or am I missing > something ? > > 2. Fully stubbed the windows library, added the dlopen/dlsym[2]. > - Windows supports ANSI and Unicode versions of most functions. Considering > the use-case I'm going with ANSI. Objections/suggestions ? Ansi should be fine for our uses, as the names of the libraries we want to load are ANSI. > > TODO: > - Test it. > - dlopen/LoadLibraryEx has a flag DONT_RESOLVE_DLL_REFERENCES, which might > be > interesting. Experiment with it. I wouldn't use DONT_RESOLVE_DLL_REFERENCES -- it seems something somebody would use for example, to read debugging/resource information, but not actually running any code from a DLL. LoadLibraryA is what you want. Jose > > And last but not least: > Should I keep these emails out of the waffle ML? > > Cheers, > Emil > ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
