Re: [waffle] [PATCH v2] wgl: don't use ARB_create_context with pre 3.2 contexts

[Jose Fonseca]

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 <jfons...@vmware.com>
Cc: Ilia Mirkin <imir...@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>
---
  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(>wcore.attrs, 10) ||
+ wgl_context_needs_arb_create_context(>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 <jfons...@vmware.com>
___
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

[Jose Fonseca]

On 15/04/16 23:35, Emil Velikov wrote:

On 15 April 2016 at 20:04, Chad Versace <chad.vers...@intel.com> 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 <jfons...@vmware.com>
Cc: Ilia Mirkin <imir...@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>





+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 <jfons...@vmware.com>


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

[Jose Fonseca]

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 <jfons...@vmware.com>
Cc: Ilia Mirkin <imir...@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>





+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 <jfons...@vmware.com>


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 v3 2/3] wcore: rework non-compatible mutex initialization

[Jose Fonseca]

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 jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
  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 jfons...@vmware.com
___
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

[Jose Fonseca]

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 jfons...@vmware.com 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 2/3] wcore: rework non-compatible mutex initialization

[Jose Fonseca]

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 emil.l.veli...@gmail.com
---
  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.

[Jose Fonseca]

---
 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
 
-constantWAFFLE_CONTEXT_PROFILE_CORE/constant and
-constantWAFFLE_CONTEXT_PROFILE_COMPATIBILITY/constant.
+constantWAFFLE_CONTEXT_CORE_PROFILE/constant and
+constantWAFFLE_CONTEXT_COMPATIBILITY_PROFILE/constant.
   /para
 /listitem
   /varlistentry
-- 
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

[Jose Fonseca]

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 jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
  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=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=RBvFLv1P_C7r-jThSfQLGV4L1h32l9KC-3mJfpjLL6gs=SCxCJShZIl_Lg0cRH6IfNYDZB7kY-pDbjYbtJXvwODge=

-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

[Jose Fonseca]

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 jfons...@vmware.com

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 emil.l.veli...@gmail.com
---
  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=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=nNtXnHzuAk5hPwtwGrgxfMXqC38r0N67lMvo2tVn4uIs=EwNY6JADl8A6pX-r8HaPaKhzyAXhhacMFmSpzh_whB8e=

-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.

[Jose Fonseca]

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 jfons...@vmware.com 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.htmld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=EOTSIhn-7yCkuKuQ-JCDhS7EtrWFaozBDxo228XaWsos=0Bi5_OB7Grl7-w1RO8R0l0YtCyi9IkRu-lB9Jtt7Onoe=


Should have spotted this a Frank sent out the patch. Sorry about this
Jose.
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com

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 stdio.h
#include stdlib.h

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: find glGetStringi on both Mali and WGL

[Jose Fonseca]

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 fjhenig...@google.com
---
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_0543d0d12aa16e0daf361937619998c8995fd6fcd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=jj_3KkjKndz1s137tbSUUg5KMJt2V9GA1zfYN2FD3NMs=MqMB3pPMPv0XARCwxF4eXGARoUaWTUMgtf36lr6r18ke=
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_6ae99a4701bd5117a182c2e555a0c0a2061254d3d=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=jj_3KkjKndz1s137tbSUUg5KMJt2V9GA1zfYN2FD3NMs=nva4AmJVhqxaYMvR3ci1RRFczSckPxLwyQrku1kjGkge=
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

Re: [waffle] [PATCH 3/3] wgl: Verify the client area size matches the required size on window creation too.

[Jose Fonseca]

On 29/12/14 22:01, Emil Velikov wrote:

On 29/12/14 16:22, Jose Fonseca wrote:

From: José Fonseca jfons...@vmware.com

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

[Jose Fonseca]

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 dylanx.c.ba...@intel.com
---

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

[waffle] [PATCH 3/3] wgl: Verify the client area size matches the required size on window creation too.

[Jose Fonseca]

From: José Fonseca jfons...@vmware.com

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

[waffle] [PATCH 2/3] examples/gl_basic: Add option for window size.

[Jose Fonseca]

From: José Fonseca jfons...@vmware.com

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

Re: [waffle] [PATCH 3/4] cmake: Add the installed package files to the registry on windows

[Jose Fonseca]

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 dylanx.c.ba...@intel.com
---

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

Re: [waffle] [PATCH] cmake: Find and set include path for wglext.h

[Jose Fonseca]

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] [PULL] WGL support

[Jose Fonseca]

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 waffle-boun...@lists.freedesktop.org on behalf of Emil Velikov 
emil.l.veli...@gmail.com
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.gitd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=EGM6H4ulpFPwVnDDH3iPVGd98lc14c_lhS09jYVF5xws=lxQxEL2eOi4ZT2UgL4Ip5ZgShVo5gsGwfiGr2SODtgEe=
  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
  

Re: [waffle] Hopes and plans for waffle-next

[Jose Fonseca]

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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0As=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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0As=e6c60f71a59f4dcaaea54362e434d1451850d5f80312da28b5fdcf43ea10e906

[3] Prevent heap corruption (2 patch series)
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/waffle/2014-August/000643.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0As=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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=VtfCOU8aNtEinYk6ptUSjyGmMVEo2qBwZkJ%2F4Izc%2FM4%3D%0As=69a62cc1572404fbab4db0f5df82503298d9af7317439f151cb9cb1802a6c3eb



___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] Final (GSoCwise) waffle WGL release

[Jose Fonseca]

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

[Jose Fonseca]

On 19/08/14 18:44, Emil Velikov wrote:

On 19 August 2014 16:51, Jose Fonseca jfons...@vmware.com 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 emil.l.veli...@gmail.com
---
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 02/18] pkg/archlinux: add mingw-w64-waffle package

[Jose Fonseca]

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 chad.vers...@linux.intel.com
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 emil.l.veli...@gmail.com
 ---
  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 chad.vers...@linux.intel.com
 +
 +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%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=szKb4hF2Ik5O%2FxpnFqwbR6XKOzdStURP37Ybmzik3Ng%3D%0As=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() {
return 0;
}
$ /usr/bin/i686-w64-mingw32-gcc sanity.c
$ /usr/lib/gcc/i686-w64-mingw32/4.9.1/cc1: error while loading shared 
libraries: libisl.so.13: cannot open shared object file: No such file or 
directory
$
$ # Now build Emil's PKGBUILD
$ makepkg
== Making package: mingw-w64-waffle 1.3.0-1 (Wed Jul 30 19:57:04 PDT 2014)
== Checking runtime dependencies...
== Checking buildtime dependencies...
== Retrieving sources...
== Extracting sources...
== Starting build()...
== Building mingw-w64-waffle for cross-building
~/proj/hh/default/src/waffle/build-i686-w64-mingw32 ~/proj/hh/default/src/waffle
-- The C compiler identification is unknown
-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc
-- Check

Re: [waffle] [PATCH 03/18] README_WIN: add some notes about configuring and building WGL

[Jose Fonseca]

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 emil.l.veli...@gmail.com
---
  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 06/18] wgl: implement display management

[Jose Fonseca]

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 emil.l.veli...@gmail.com
---
  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 stdlib.h
+#include strings.h
+#include windows.h

  #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 = 

Re: [waffle] [PATCH 06/18] wgl: implement display management

[Jose Fonseca]

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 emil.l.veli...@gmail.com
---
  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 stdlib.h
+#include strings.h
+#include windows.h

  #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%23L218k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=tyTB22tb8qXxlAjtC9yppkPcm8bpett7KDrGHrMprfc%3D%0As=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 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

Re: [waffle] [PATCH 16/33] third_party/threads: import c11 threads emulation wrappers

[Jose Fonseca]

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 10/33] cmake: build with fPIC when possible

[Jose Fonseca]

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 emil.l.veli...@gmail.com
---
  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

[Jose Fonseca]

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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=YJhITSIo0uXhla76OWwW3MvMqY%2By%2B%2FdnBUwx2AJ8Yzk%3D%0As=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] Some new and old fixes

[Jose Fonseca]

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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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

[Jose Fonseca]

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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0eeLUEWkgi57miMy0UePE0pWYjRgjZiB06NM%2F5MlJqo%3D%0As=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 Kits\8.1\Include\um

21/08/2013  16:38 6,630 Windows.h
   1 File(s)  6,630 bytes
   0 Dir(s)  101,239,664,640 bytes free

 dir c:\Program Files

Re: [waffle] [GSOC2014] Current design/implementation + the infamous corruption

[Jose Fonseca]

- 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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=a2j0YKhUfDCeKnrHMRWtbX2GGkBhvFdRuL%2BmYYiIN7g%3D%0As=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

[Jose Fonseca]

- Original Message -
 On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@vmware.com wrote:
  - Original Message -
  On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
   On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@gmail.com
   wrote:
On 25/05/14 21:35, Jordan Justen wrote:
On Sat, May 24, 2014 at 12:28 PM, Emil Velikov
emil.l.veli...@gmail.com wrote:
* Library dependencies, etc. (low priority)
libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the
dependency,
ship them in the zip or leave it to the user/dev ?
   
  Library:
libgcc_s
  __emutls_get_address
  __udivdi3
  __umoddi3
   
  Options:
- Static link libgcc_s, generally not bad idea
sigh, a bit of a typo here - the above should read:
   
- Static link libgcc_s - generally _a bad_ idea
  
   Doesn't gcc/binutils automatically do this when you compile/link?
  
What are the licensing implications?
   
That's possibly the main reason why I'm inclined to go with rework.
I've
never
been good at the legal/licensing terms.
   
I think libgcc would be covered by this exception, right?
https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389
   
If so, it seems like static linking might not be a problem.
   
IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no
gpl-incompatible software is used during the Compilation Process,
thus
we
are Eligible.
  
   It sounds they only mean to prevent non-GPL compatible code from
   getting into the internals of the GCC complication process. So, in
   other words, you can't have a proprietary GCC plugin, and also use the
   exception to link to libgcc, etc.
  
   But, it seems like even proprietary code could use the exception to
   link to libgcc as long as it was just being compiled by GCC.
  
- or, rework waffle ?
  Split merged_version or move to (major  8 | minor) for
  the
  wcore_config_attrs_version_* helpers - will nuke the last
  two.
  No idea how to nuke __emutls_get_address.
   
  Suggestion:
Split to separate major/minor.
   
   
  Library:
 libwinpthread-1
   pthread_key_create
   pthread_mutex_lock
   pthread_mutex_unlock
   pthread_once
   pthread_setspecific
   
  Options:
 - Static link
   
What are the licensing implications?
   
It doesn't look as good as the libgcc case.
   
The library is a combination of X/MIT and 3-clause BSD. Which afaics
is
rather
vague on the topic of static linking the library and distribution of
the
final
binary(ies). My guess is that we ought to be safe but IANAL.
  
   This wasn't my concern. I was concerned the library might have been
   GPL licensed, and thus the waffle DLL wouldn't be usable with a
   proprietary application.
  
   Chad, would you be okay with releasing the windows waffle DLL and
   noting that it is partially covered by X/MIT, 3-clause BSD and
   2-clause BSD?
 
 
  If Waffle needs a stacked license to support Win32, that's ok with me.
  Liberal licenses in the BSD, MIT, and Apache family are all acceptable.
 
  I am not a lawyer either, so I do not know if statically linking the
  parts you speak of are safe to do so. I think you should make your
  initial decision based on its technical merits. Then, after the
  technical, decision is made but before you've invested too much time in
  it, all of us (you, Jordan, me, Jose) should analyze any license issues.
 
  FWIW, I prefer to avoid runtime dependency hell by statically linking
  small, problematic components. But my opinion is of limited value here,
  because I'm unfamiliar with the problem domain of mingw and MSVC.
 
  FWIW, my opinion is that we shouldn't get too distracted by licensing and
  what release binaries should look like.  It is not something that needs to
  be decided now, or ever: ultimately, that decision can be pushed to the
  final user.  They might prefer mingw, they might prefer msvc for easy of
  debugging, or because they want to statically link, etc.
 
 
 I thought we wanted to go ahead an provide a binary build for windows, and
 thus:
 1. It should be buildable under Linux using mingw
 2. The binary should have a reasonable license situation

 Didn't we already pretty much have this worked out anyhow?

Maybe I misinterpreted things.  I always saw mingw as a mean to an end, to 
facilitate development and get things started (ie, without forcing Emil to 
obtain and learn to use use a completely new set of tools).  And not the end 
itself (distribute

Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

- Original Message -
 
 
 - Original Message -
  On Wed, Jun 4, 2014 at 1:18 PM, Jose Fonseca jfons...@vmware.com wrote:
   - Original Message -
   On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
On Sun, May 25, 2014 at 2:43 PM, Emil Velikov
emil.l.veli...@gmail.com
wrote:
 On 25/05/14 21:35, Jordan Justen wrote:
 On Sat, May 24, 2014 at 12:28 PM, Emil Velikov
 emil.l.veli...@gmail.com wrote:
 * Library dependencies, etc. (low priority)
 libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the
 dependency,
 ship them in the zip or leave it to the user/dev ?

   Library:
 libgcc_s
   __emutls_get_address
   __udivdi3
   __umoddi3

   Options:
 - Static link libgcc_s, generally not bad idea
 sigh, a bit of a typo here - the above should read:

 - Static link libgcc_s - generally _a bad_ idea
   
Doesn't gcc/binutils automatically do this when you compile/link?
   
 What are the licensing implications?

 That's possibly the main reason why I'm inclined to go with rework.
 I've
 never
 been good at the legal/licensing terms.

 I think libgcc would be covered by this exception, right?
 https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389

 If so, it seems like static linking might not be a problem.

 IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and
 no
 gpl-incompatible software is used during the Compilation Process,
 thus
 we
 are Eligible.
   
It sounds they only mean to prevent non-GPL compatible code from
getting into the internals of the GCC complication process. So, in
other words, you can't have a proprietary GCC plugin, and also use the
exception to link to libgcc, etc.
   
But, it seems like even proprietary code could use the exception to
link to libgcc as long as it was just being compiled by GCC.
   
 - or, rework waffle ?
   Split merged_version or move to (major  8 | minor) for
   the
   wcore_config_attrs_version_* helpers - will nuke the
   last
   two.
   No idea how to nuke __emutls_get_address.

   Suggestion:
 Split to separate major/minor.


   Library:
  libwinpthread-1
pthread_key_create
pthread_mutex_lock
pthread_mutex_unlock
pthread_once
pthread_setspecific

   Options:
  - Static link

 What are the licensing implications?

 It doesn't look as good as the libgcc case.

 The library is a combination of X/MIT and 3-clause BSD. Which afaics
 is
 rather
 vague on the topic of static linking the library and distribution of
 the
 final
 binary(ies). My guess is that we ought to be safe but IANAL.
   
This wasn't my concern. I was concerned the library might have been
GPL licensed, and thus the waffle DLL wouldn't be usable with a
proprietary application.
   
Chad, would you be okay with releasing the windows waffle DLL and
noting that it is partially covered by X/MIT, 3-clause BSD and
2-clause BSD?
  
  
   If Waffle needs a stacked license to support Win32, that's ok with me.
   Liberal licenses in the BSD, MIT, and Apache family are all acceptable.
  
   I am not a lawyer either, so I do not know if statically linking the
   parts you speak of are safe to do so. I think you should make your
   initial decision based on its technical merits. Then, after the
   technical, decision is made but before you've invested too much time in
   it, all of us (you, Jordan, me, Jose) should analyze any license issues.
  
   FWIW, I prefer to avoid runtime dependency hell by statically linking
   small, problematic components. But my opinion is of limited value here,
   because I'm unfamiliar with the problem domain of mingw and MSVC.
  
   FWIW, my opinion is that we shouldn't get too distracted by licensing and
   what release binaries should look like.  It is not something that needs
   to
   be decided now, or ever: ultimately, that decision can be pushed to the
   final user.  They might prefer mingw, they might prefer msvc for easy of
   debugging, or because they want to statically link, etc.
  
  
  I thought we wanted to go ahead an provide a binary build for windows, and
  thus:
  1. It should be buildable under Linux using mingw
  2. The binary should have a reasonable license situation
 
  Didn't we already pretty much have this worked out anyhow?
 
 Maybe I misinterpreted things.  I always saw mingw as a mean

Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

- Original Message -
 On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
  On Sun, May 25, 2014 at 2:43 PM, Emil Velikov emil.l.veli...@gmail.com
  wrote:
   On 25/05/14 21:35, Jordan Justen wrote:
   On Sat, May 24, 2014 at 12:28 PM, Emil Velikov
   emil.l.veli...@gmail.com wrote:
   * Library dependencies, etc. (low priority)
   libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the
   dependency,
   ship them in the zip or leave it to the user/dev ?
  
 Library:
   libgcc_s
 __emutls_get_address
 __udivdi3
 __umoddi3
  
 Options:
   - Static link libgcc_s, generally not bad idea
   sigh, a bit of a typo here - the above should read:
  
   - Static link libgcc_s - generally _a bad_ idea
  
  Doesn't gcc/binutils automatically do this when you compile/link?
  
   What are the licensing implications?
  
   That's possibly the main reason why I'm inclined to go with rework. I've
   never
   been good at the legal/licensing terms.
  
   I think libgcc would be covered by this exception, right?
   https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0As=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389
  
   If so, it seems like static linking might not be a problem.
  
   IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no
   gpl-incompatible software is used during the Compilation Process, thus
   we
   are Eligible.
  
  It sounds they only mean to prevent non-GPL compatible code from
  getting into the internals of the GCC complication process. So, in
  other words, you can't have a proprietary GCC plugin, and also use the
  exception to link to libgcc, etc.
  
  But, it seems like even proprietary code could use the exception to
  link to libgcc as long as it was just being compiled by GCC.
  
   - or, rework waffle ?
 Split merged_version or move to (major  8 | minor) for the
 wcore_config_attrs_version_* helpers - will nuke the last
 two.
 No idea how to nuke __emutls_get_address.
  
 Suggestion:
   Split to separate major/minor.
  
  
 Library:
libwinpthread-1
  pthread_key_create
  pthread_mutex_lock
  pthread_mutex_unlock
  pthread_once
  pthread_setspecific
  
 Options:
- Static link
  
   What are the licensing implications?
  
   It doesn't look as good as the libgcc case.
  
   The library is a combination of X/MIT and 3-clause BSD. Which afaics is
   rather
   vague on the topic of static linking the library and distribution of the
   final
   binary(ies). My guess is that we ought to be safe but IANAL.
  
  This wasn't my concern. I was concerned the library might have been
  GPL licensed, and thus the waffle DLL wouldn't be usable with a
  proprietary application.
  
  Chad, would you be okay with releasing the windows waffle DLL and
  noting that it is partially covered by X/MIT, 3-clause BSD and
  2-clause BSD?
 
 
 If Waffle needs a stacked license to support Win32, that's ok with me.
 Liberal licenses in the BSD, MIT, and Apache family are all acceptable.
 
 I am not a lawyer either, so I do not know if statically linking the
 parts you speak of are safe to do so. I think you should make your
 initial decision based on its technical merits. Then, after the
 technical, decision is made but before you've invested too much time in
 it, all of us (you, Jordan, me, Jose) should analyze any license issues.
 
 FWIW, I prefer to avoid runtime dependency hell by statically linking
 small, problematic components. But my opinion is of limited value here,
 because I'm unfamiliar with the problem domain of mingw and MSVC.

FWIW, my opinion is that we shouldn't get too distracted by licensing and what 
release binaries should look like.  It is not something that needs to be 
decided now, or ever: ultimately, that decision can be pushed to the final 
user.  They might prefer mingw, they might prefer msvc for easy of debugging, 
or because they want to statically link, etc.

IMHO the most important is getting waffle to build and run on Windows on some 
form.

Jose
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

- Original Message -
 On 31/05/14 19:59, Jose Fonseca wrote:
  - Original Message -
  On 24/05/14 20:28, Emil Velikov wrote:
 [snip]
 
  AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
  allows the PixelFormat to be called prior to the creation of either window
  or
  context.
 
Options:
  - Create a window, choose format, destroy window.
No guarantee that the function will behave the same for another
window/device_context.
  
  In practice, the odds of this happening are very low.
  
  I'd recommend creating an invisible window, do your things then, keep the
  window around, and then merely double check later that things are not
  busted.
  
 Still not sure which one of the two you are recommending:
 
 Create a invisible(dummy) window initially and create a new one at
 wfl_window_create. or

This one. But I'm not 100% what is the best way.  Whatever works really.

Jose

 Create a invisible(dummy) window initially and bring it up/use it at
 wfl_window_create/wfl_window_show. ?
 
 
 Pardon if the above question sound rather dull :)
 
 Thanks
 Emil
 
  You can see in
  https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/wgl/stw_ext_pbuffer.ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=EVvdAN6DpAMPSYORbM%2BCu4MTEMmLt5L7XFRXd%2Be9PvI%3D%0As=7d4dab293ed0b1192ad5e333f73785f2aa7efedbd4ea4ec656a41ff96078d8c3
  how to create an invisible window  (This is how Mesa implements pbuffers
  on Windows!.)
  
  Jose
  
  - or, create window, choose format, reuse window on
  waffle_window_create()
Sanest solution. If windows is not created just make one (i.e.
waffle_config_choose is not executed before
waffle_window_create).
 
  - or, store the attributes, and invoke ChoosePixelFormat as
waffle_window_create is executed.
What if code-flow depends on waffle_config_choose's return
value
?
 
  - or rework waffle API ... (no, please no)
 
Suggestion:
  Cache the window, and reuse it on waffle_window_create.
 
 
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

- 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

[Jose Fonseca]

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] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

- 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.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=nPzAHYznyFhyA6Bn%2FXHt2AeHO%2FNhVm9VWwNYkwnEmIc%3D%0As=f1ea3aad8cc771542f8ab3be427e2335d4486e0516e7e738e83019b3457a475c
 
  
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 

Re: [waffle] [PATCH 0/8] Move WAFFLE_API out of the public header + misc patches

[Jose Fonseca]

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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0As=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/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0As=bf956564e315c2ca8e8da1e6e0c16a7758a2c1e8ef7bb1b9c3bfcdf84825b038
 
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle