Re: [waffle] [PULL] WGL support
Hi Emil, I went through the new patches and they look good AFAICT. Thanks for doing this. While going through wgl: fully support ARB_create_context and EXT_create_context_es_profile. again I noticed a couple of issues with the usage of WGL_EXT_create_context_es2_profile that I hadn't noticed before because I wasn't familiar with the extension: - WGL_EXT_create_context_es_profile ignored the opengl version, but WGL_EXT_create_context_es2_profile will create any version requested in. - I believe one must set WGL_CONTEXT_MAJOR_VERSION_ARB/WGL_CONTEXT_MINOR_VERSION_ARB when requesting ES contexts or one will always get a ES 1.0 context. - It's OK to assume that WGL_EXT_create_context_es2_profile then WGL_EXT_create_context_es_profile is supported, but not the other way around. This is because WGL_EXT_create_context_es_profile ignored the version See Revision History at the bottom of https://www.opengl.org/registry/specs/EXT/wgl_create_context_es2_profile.txt for details. Anyway, this is nor urgent -- it can be fixed in a follow on patch. Jose From: waffle 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] [PULL] WGL support
On Wed 12 Nov 2014, Jose Fonseca wrote: 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, thanks for spotting this bug. It also affects Waffle's GLX backend. So we don't forget about the bugs, I created two tickets: for WGL: https://github.com/waffle-gl/waffle/issues/23 for GLX: https://github.com/waffle-gl/waffle/issues/24 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On 10/11/14 06:17, Chad Versace wrote: On Sun 09 Nov 2014, Emil Velikov wrote: As mentioned earlier here is a rebase of all the wgl work so far on top of origin/master. Merged to next! So... what does that mean??? That means I'll merge your branch to 'master' after it cooks for a little while and I'm certain Piglit doesn't complain. To answer your branching query from Saturday... Here's a *very tiny* summary of the workflow I'm following in man:gitworkflow(7). - The 'master' branch should always be stable. At any time, it should be safe to cut a release off of master. - The 'next' branch is an integration branch. That's where the interesting action happens. - Topic branches are usually first merged to 'next', unless they are obvious fixes. After baking on 'next' for enough time to reveal any lurking bugs, the same topic branch is then merged to 'master'. - As explained in man:gitworkflow(7), merges between branches always flow upwards and never downwards. That is, maint - master - next and never master - next - Merges are preferred over cherry-picks. As explained in man:gitworkflow(7): Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful. Most importantly, merging works at the branch level, while cherry-picking works at the commit level. [...] Merges are also easier to understand because merge commit is a promise that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. [...] Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards intoeach other. [A merging upwards strategy] gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. Fwiw although it somewhat makes sense to merge maint into master, I'm personally commit to master and cherry-pick to stable/maint kind of person. Either way, as long as you're ok dealing with conflicts etc. I'll deal with it :P Friendly request - please don't cherry-pick from next onto master. Afaiu one can(is allowed to) rebase next which will cause a bit of ... Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On Mon 10 Nov 2014, Emil Velikov wrote: On 10/11/14 06:17, Chad Versace wrote: On Sun 09 Nov 2014, Emil Velikov wrote: - As explained in man:gitworkflow(7), merges between branches always flow upwards and never downwards. That is, maint - master - next and never master - next - Merges are preferred over cherry-picks. As explained in man:gitworkflow(7): Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful. Most importantly, merging works at the branch level, while cherry-picking works at the commit level. [...] Merges are also easier to understand because merge commit is a promise that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. [...] Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards intoeach other. [A merging upwards strategy] gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. Fwiw although it somewhat makes sense to merge maint into master, I'm personally commit to master and cherry-pick to stable/maint kind of person. Either way, as long as you're ok dealing with conflicts etc. I'll deal with it :P I like the merge conflicts. They make me feel safer, more aware of the global picture. Maybe I'm a masochist :/ Friendly request - please don't cherry-pick from next onto master. Agreed. If had cherry-picked from next onto master in the past, I consider that a mistake. That shouldn't happen again. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On Sun 09 Nov 2014, Emil Velikov wrote: As mentioned earlier here is a rebase of all the wgl work so far on top of origin/master. Merged to next! So... what does that mean??? That means I'll merge your branch to 'master' after it cooks for a little while and I'm certain Piglit doesn't complain. To answer your branching query from Saturday... Here's a *very tiny* summary of the workflow I'm following in man:gitworkflow(7). - The 'master' branch should always be stable. At any time, it should be safe to cut a release off of master. - The 'next' branch is an integration branch. That's where the interesting action happens. - Topic branches are usually first merged to 'next', unless they are obvious fixes. After baking on 'next' for enough time to reveal any lurking bugs, the same topic branch is then merged to 'master'. - As explained in man:gitworkflow(7), merges between branches always flow upwards and never downwards. That is, maint - master - next and never master - next - Merges are preferred over cherry-picks. As explained in man:gitworkflow(7): Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful. Most importantly, merging works at the branch level, while cherry-picking works at the commit level. [...] Merges are also easier to understand because merge commit is a promise that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. [...] Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. [A merging upwards strategy] gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
