Re: [Mesa-dev] [PATCH] Haiku: convert to autotools
On 2018-02-05 18:13, Dylan Baker wrote: Pretty close. I lied, apparently the pthreads fix is in 0.44 https://github.com/mesonbuild/meson/commit/fc547ad05e5a8e650ae5bc2ecc7d40e4dbcc9f0f Here's my branch, but it needs rebase pretty bad, there's also a patch to use shared glapi that I added trying to see if that would get the build working that needs to be removed: https://github.com/dcbaker/mesa/tree/wip/meson-haiku Ok. I went over and got Haiku building with menson with the following change: https://github.com/kallisti5/mesa/commit/e33dfab54d99edacdf1d24c402d29f50818631b3 Any feedback welcome. I need to review your branch now and see if I can make improvements based on your changes. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Haiku: convert to autotools
On 2018-02-05 18:13, Dylan Baker wrote: Quoting kallisti5 (2018-02-05 15:36:06) On 2018-02-05 16:14, kallisti5 wrote: > On 2018-02-05 15:39, Dylan Baker wrote: >> Quoting kallisti5 (2018-02-05 12:58:30) >>> On 2017-10-24 11:47, Emil Velikov wrote: >>> > Hi Jerome, >>> > >>> > On 23 October 2017 at 16:58, Jerome Duval >>> > wrote: >>> >> * configure.ac: >>> >> -pthread is not available on Haiku. >>> >> Haiku doesn't require --enable-dri >>> >> build hgl on Haiku >>> >> * egl/Makefile.am: define backendfiles for Haiku >>> >> * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and >>> >> targets/haiku-softpipe on Haiku. >>> >> * src/gallium/targets/haiku-softpipe: add Makefile.am >>> >> * src/gallium/state_trackers/hgl: add Makefile.am >>> >> * winsys/sw/hgl: add Makefile.am >>> >> * src/hgl/Makefile.am: add Makefile.am >>> >> --- >>> > Thanks for the patch. I think Eric has a point regarding splitting this >>> > up. >>> > Here is one way to handle it: >>> > - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku >>> > - 2 - src/egl >>> > - 3 - src/hgl >>> > - 4 misc fixes (the SoftwareRenderer.cpp hunk?) >>> > - 5 toggle - configure.ac + src/Makefile.am >>> >>> Hm, it looks like Jerome never got back to work on these changes... >>> let >>> me try to >>> pick up the ball and run with it. >>> >>> > Couple of small suggestions: >>> > - keep all the sources and headers in the sources lists in >>> > Makefile.sources >>> > - how do you guys manage pthreads - please mention that in the commit >>> > message. >>> > >>> > If I'm reading this correctly, you strip out -pthread and there's no >>> > pthread-stubs on Haiku. >>> >>> Haiku (and BeOS for that matter) has pthread support built into its >>> core >>> libroot.so. >>> >>> No need for -lpthread, all applications can assume its presence. >>> Things >>> that link -lpthread actually fail due to a non-existant libpthread... >>> *however* as i'm typing this i'm being told we recently implemented a >>> dummy static libpthread.a to try and appease assumptions about >>> -lpthread >>> existence so i'll remove the pthread checks :-) >>> >>> -- Alex >> >> Hi Alex, >> >> I have a branch for building haiku with meson, when I was trying to >> compile >> neither the scons build nor the autotools build seemed to compile on a >> Haiku VM >> instance (x86_64), that was a few months ago though, so maybe its >> fixed. >> >> Our plan is to remove autotools from mesa, probably this year. I'm >> thinking if >> things look pretty good through the 18.0 release cycle I'll probably >> propose >> marking autotools as deprecated for 18.1 and propose removal in 18.2. > > Ah. crap. I just got autoconfig working :-). Historically I have only > used > SCons for our builds. I always preferred the SCons build since > autotools always > ends up looking like spaghetti. Here is what our current build does: > > https://github.com/haikuports/haikuports/blob/master/sys-libs/mesa/mesa-17.1.4.recipe#L52 > > It looks like Jerome hacked in a patch for autotools... but i've heard > some reports > of instability with the resulting artifacts. > >> I'm not going to block you guys using autotools or NAK anything, I >> just want >> you to be aware that we're trying to consolidate down to just meson >> and >> android.mk files. I can respin the haiku patches and CC you if you're >> interested in >> looking at them. > > If Meson is the future, i'm definitely down helping (or even taking > over) that branch > if it is just incomplete Haiku work. > > I'm going to try and do better maintenance on Haiku Mesa in 2018. I've > been only around > minimally in 2017 am a little out of date. > >> You might also want to see if you guys can update your meson, at least >> last time >> I checked it was 0.42, and I fixed the pthreads stuff in 0.43 so that >> -pthread >> and -lpthread are never added by meson. > > I just installed meson on Haiku and we are currently at 0.43.0 I took a quick crack at meson on Haiku. Getting stuck with a -pthread getting injected somewhere around
Re: [Mesa-dev] [PATCH] Haiku: convert to autotools
On 2018-02-05 16:14, kallisti5 wrote: On 2018-02-05 15:39, Dylan Baker wrote: Quoting kallisti5 (2018-02-05 12:58:30) On 2017-10-24 11:47, Emil Velikov wrote: > Hi Jerome, > > On 23 October 2017 at 16:58, Jerome Duval > wrote: >> * configure.ac: >> -pthread is not available on Haiku. >> Haiku doesn't require --enable-dri >> build hgl on Haiku >> * egl/Makefile.am: define backendfiles for Haiku >> * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and >> targets/haiku-softpipe on Haiku. >> * src/gallium/targets/haiku-softpipe: add Makefile.am >> * src/gallium/state_trackers/hgl: add Makefile.am >> * winsys/sw/hgl: add Makefile.am >> * src/hgl/Makefile.am: add Makefile.am >> --- > Thanks for the patch. I think Eric has a point regarding splitting this > up. > Here is one way to handle it: > - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku > - 2 - src/egl > - 3 - src/hgl > - 4 misc fixes (the SoftwareRenderer.cpp hunk?) > - 5 toggle - configure.ac + src/Makefile.am Hm, it looks like Jerome never got back to work on these changes... let me try to pick up the ball and run with it. > Couple of small suggestions: > - keep all the sources and headers in the sources lists in > Makefile.sources > - how do you guys manage pthreads - please mention that in the commit > message. > > If I'm reading this correctly, you strip out -pthread and there's no > pthread-stubs on Haiku. Haiku (and BeOS for that matter) has pthread support built into its core libroot.so. No need for -lpthread, all applications can assume its presence. Things that link -lpthread actually fail due to a non-existant libpthread... *however* as i'm typing this i'm being told we recently implemented a dummy static libpthread.a to try and appease assumptions about -lpthread existence so i'll remove the pthread checks :-) -- Alex Hi Alex, I have a branch for building haiku with meson, when I was trying to compile neither the scons build nor the autotools build seemed to compile on a Haiku VM instance (x86_64), that was a few months ago though, so maybe its fixed. Our plan is to remove autotools from mesa, probably this year. I'm thinking if things look pretty good through the 18.0 release cycle I'll probably propose marking autotools as deprecated for 18.1 and propose removal in 18.2. Ah. crap. I just got autoconfig working :-). Historically I have only used SCons for our builds. I always preferred the SCons build since autotools always ends up looking like spaghetti. Here is what our current build does: https://github.com/haikuports/haikuports/blob/master/sys-libs/mesa/mesa-17.1.4.recipe#L52 It looks like Jerome hacked in a patch for autotools... but i've heard some reports of instability with the resulting artifacts. I'm not going to block you guys using autotools or NAK anything, I just want you to be aware that we're trying to consolidate down to just meson and android.mk files. I can respin the haiku patches and CC you if you're interested in looking at them. If Meson is the future, i'm definitely down helping (or even taking over) that branch if it is just incomplete Haiku work. I'm going to try and do better maintenance on Haiku Mesa in 2018. I've been only around minimally in 2017 am a little out of date. You might also want to see if you guys can update your meson, at least last time I checked it was 0.42, and I fixed the pthreads stuff in 0.43 so that -pthread and -lpthread are never added by meson. I just installed meson on Haiku and we are currently at 0.43.0 I took a quick crack at meson on Haiku. Getting stuck with a -pthread getting injected somewhere around glapi gen. Lets see if my modifications are close to yours sight unseen :-) https://gist.github.com/kallisti5/eb43162dd4c9e61b5740444d20955118 -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Haiku: convert to autotools
On 2018-02-05 15:39, Dylan Baker wrote: Quoting kallisti5 (2018-02-05 12:58:30) On 2017-10-24 11:47, Emil Velikov wrote: > Hi Jerome, > > On 23 October 2017 at 16:58, Jerome Duval > wrote: >> * configure.ac: >> -pthread is not available on Haiku. >> Haiku doesn't require --enable-dri >> build hgl on Haiku >> * egl/Makefile.am: define backendfiles for Haiku >> * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and >> targets/haiku-softpipe on Haiku. >> * src/gallium/targets/haiku-softpipe: add Makefile.am >> * src/gallium/state_trackers/hgl: add Makefile.am >> * winsys/sw/hgl: add Makefile.am >> * src/hgl/Makefile.am: add Makefile.am >> --- > Thanks for the patch. I think Eric has a point regarding splitting this > up. > Here is one way to handle it: > - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku > - 2 - src/egl > - 3 - src/hgl > - 4 misc fixes (the SoftwareRenderer.cpp hunk?) > - 5 toggle - configure.ac + src/Makefile.am Hm, it looks like Jerome never got back to work on these changes... let me try to pick up the ball and run with it. > Couple of small suggestions: > - keep all the sources and headers in the sources lists in > Makefile.sources > - how do you guys manage pthreads - please mention that in the commit > message. > > If I'm reading this correctly, you strip out -pthread and there's no > pthread-stubs on Haiku. Haiku (and BeOS for that matter) has pthread support built into its core libroot.so. No need for -lpthread, all applications can assume its presence. Things that link -lpthread actually fail due to a non-existant libpthread... *however* as i'm typing this i'm being told we recently implemented a dummy static libpthread.a to try and appease assumptions about -lpthread existence so i'll remove the pthread checks :-) -- Alex Hi Alex, I have a branch for building haiku with meson, when I was trying to compile neither the scons build nor the autotools build seemed to compile on a Haiku VM instance (x86_64), that was a few months ago though, so maybe its fixed. Our plan is to remove autotools from mesa, probably this year. I'm thinking if things look pretty good through the 18.0 release cycle I'll probably propose marking autotools as deprecated for 18.1 and propose removal in 18.2. Ah. crap. I just got autoconfig working :-). Historically I have only used SCons for our builds. I always preferred the SCons build since autotools always ends up looking like spaghetti. Here is what our current build does: https://github.com/haikuports/haikuports/blob/master/sys-libs/mesa/mesa-17.1.4.recipe#L52 It looks like Jerome hacked in a patch for autotools... but i've heard some reports of instability with the resulting artifacts. I'm not going to block you guys using autotools or NAK anything, I just want you to be aware that we're trying to consolidate down to just meson and android.mk files. I can respin the haiku patches and CC you if you're interested in looking at them. If Meson is the future, i'm definitely down helping (or even taking over) that branch if it is just incomplete Haiku work. I'm going to try and do better maintenance on Haiku Mesa in 2018. I've been only around minimally in 2017 am a little out of date. You might also want to see if you guys can update your meson, at least last time I checked it was 0.42, and I fixed the pthreads stuff in 0.43 so that -pthread and -lpthread are never added by meson. I just installed meson on Haiku and we are currently at 0.43.0 -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Haiku: convert to autotools
On 2017-10-24 11:47, Emil Velikov wrote: Hi Jerome, On 23 October 2017 at 16:58, Jerome Duval wrote: * configure.ac: -pthread is not available on Haiku. Haiku doesn't require --enable-dri build hgl on Haiku * egl/Makefile.am: define backendfiles for Haiku * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and targets/haiku-softpipe on Haiku. * src/gallium/targets/haiku-softpipe: add Makefile.am * src/gallium/state_trackers/hgl: add Makefile.am * winsys/sw/hgl: add Makefile.am * src/hgl/Makefile.am: add Makefile.am --- Thanks for the patch. I think Eric has a point regarding splitting this up. Here is one way to handle it: - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku - 2 - src/egl - 3 - src/hgl - 4 misc fixes (the SoftwareRenderer.cpp hunk?) - 5 toggle - configure.ac + src/Makefile.am Hm, it looks like Jerome never got back to work on these changes... let me try to pick up the ball and run with it. Couple of small suggestions: - keep all the sources and headers in the sources lists in Makefile.sources - how do you guys manage pthreads - please mention that in the commit message. If I'm reading this correctly, you strip out -pthread and there's no pthread-stubs on Haiku. Haiku (and BeOS for that matter) has pthread support built into its core libroot.so. No need for -lpthread, all applications can assume its presence. Things that link -lpthread actually fail due to a non-existant libpthread... *however* as i'm typing this i'm being told we recently implemented a dummy static libpthread.a to try and appease assumptions about -lpthread existence so i'll remove the pthread checks :-) -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa v2] REVIEWERS: add Jérôme & Alexander as a reviewer for Haiku files
On 2017-11-16 10:18, Eric Engestrom wrote: Cc: Alexander von Gluck IV Cc: Jérôme Duval Signed-off-by: Eric Engestrom --- There's been some Haiku-related activity lately, so let's document who to cc on these patches. Jérôme, Alexander, are you ok with that? "ack" to make it formal :) --- REVIEWERS | 9 + 1 file changed, 9 insertions(+) diff --git a/REVIEWERS b/REVIEWERS index 960c9ce7c5defc7c3702..cc1334b366ae0c0a4a0d 100644 --- a/REVIEWERS +++ b/REVIEWERS @@ -74,6 +74,15 @@ EGL R: Eric Engestrom F: src/egl/ +HAIKU +R: Jérôme Duval +F: include/HaikuGL/ +F: src/egl/drivers/haiku/ +F: src/gallium/state_trackers/hgl/ +F: src/gallium/targets/haiku-softpipe/ +F: src/gallium/winsys/sw/hgl/ +F: src/hgl/ + GALLIUM LOADER R: Emil Velikov F: src/gallium/auxiliary/pipe-loader/ ack :-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET
On 2017-11-15 08:35, Nicolai Hähnle wrote: From: Nicolai Hähnle v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds Cc: Jon Turney Cc: Rob Herring Cc: Alexander von Gluck IV Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674 Fixes: f1a364878431 ("threads: update for late C11 changes") I don't have the power to approve (I assume), but both look good to me. Thanks for doing SCons as well. We have a few incomplete patches floating around to add autotools support... They should be finished someday :-) -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] egl/haiku: Correct invalid void* conversion in calloc
On 2017-11-13 09:41, Brian Paul wrote: On 11/12/2017 02:53 PM, Alexander von Gluck IV wrote: --- src/egl/drivers/haiku/egl_haiku.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/egl/drivers/haiku/egl_haiku.cpp b/src/egl/drivers/haiku/egl_haiku.cpp index 237cebf056..287760661e 100644 --- a/src/egl/drivers/haiku/egl_haiku.cpp +++ b/src/egl/drivers/haiku/egl_haiku.cpp @@ -313,7 +313,8 @@ _eglBuiltInDriver(void) { CALLED(); - _EGLDriver* driver = calloc(1, sizeof(*driver)); + _EGLDriver* driver; + driver = (_EGLDriver*) calloc(1, sizeof(*driver)); if (!driver) { _eglError(EGL_BAD_ALLOC, "_eglBuiltInDriverHaiku"); return NULL; For both, Reviewed-by: Brian Paul Do you need me to push these for you? Nah, I have access. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
On 2015-05-13 10:42, Jason Ekstrand wrote: On May 13, 2015 8:01 AM, "kallisti5" wrote: src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28: > include/no_extern_c.h:47:1: error: template with C linkage > > template class _IncludeInsideExternCNotPortable; > > Any alternative fix ideas besides me adding a if !defined(__HAIKU__) to include/no_extern_c.h? Please do not do that! The whole point of this patch is to catch places where headers are included inside an extern "C" block. This patch makes them a compile error instead of being silently wrong. The correct solution is to fix the haiku platform integration so it doesn't do this. --Jason Yeah, I had a chat in IRC and determined that I need to add extern "C" a few places within Mesa instead of doing a bulk extern "C" to the mesa C headers. One example is glapi_priv lacks any extern "C" (ifdef C++ wrapped) I'll begin submitting patches to the ML over the next few days. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.
On 2014-12-11 16:14, Jose Fonseca wrote: From: José Fonseca This is just to help repro and fixing these issues with any C++ compiler -- commiting this will of course wait until all issues are addressed. $ scons src/glsl/ scons: Reading SConscript files ... Checking for GCC ... yes Checking for Clang ... no Checking for X11 (x11 xext xdamage xfixes glproto >= 1.4.13)... yes Checking for XCB (x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8)... yes Checking for XF86VIDMODE (xxf86vm)... yes Checking for DRM (libdrm >= 2.4.38)... yes Checking for UDEV (libudev >= 151)... yes warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl Compiling src/glsl/ast_array_index.cpp ... Compiling src/glsl/ast_expr.cpp ... Compiling src/glsl/ast_function.cpp ... Compiling src/glsl/ast_to_hir.cpp ... Compiling src/glsl/ast_type.cpp ... Compiling src/glsl/builtin_functions.cpp ... In file included from include/c99_compat.h:28:0, from src/mapi/u_compiler.h:4, from src/mapi/u_thread.h:47, from src/mapi/glapi/glapi.h:47, from src/mesa/main/mtypes.h:42, from src/mesa/main/errors.h:47, from src/mesa/main/imports.h:41, from src/mesa/main/core.h:44, from src/glsl/builtin_functions.cpp:58: include/no_extern_c.h:48:1: error: template with C linkage template class _IncludeInsideExternCNotPortable; ^ Good morning, This change breaks all of the Haiku code as we use a *lot* of C++ code inside of Mesa (well, all the OS interfaces are C++ that wrap the Mesa C) /Builds/mesa> find . -name "*.cpp" | grep haiku ./src/egl/drivers/haiku/egl_haiku.cpp ./src/gallium/targets/haiku-softpipe/GalliumContext.cpp ./src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp ./src/mesa/drivers/haiku/swrast/SoftwareRast.cpp Example: Compiling src/util/u_atomic_test.c ... In file included from include/c99_compat.h:28:0, from include/c11/threads.h:38, from src/mesa/main/mtypes.h:39, from src/mesa/main/errors.h:42, from src/mesa/main/imports.h:44, from src/mesa/main/context.h:52, from src/mesa/drivers/haiku/swrast/SoftwareRast.h:20, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:14: include/no_extern_c.h:47:1: error: template with C linkage template class _IncludeInsideExternCNotPortable; ^ In file included from include/c99_compat.h:28:0, from src/gallium/include/pipe/p_compiler.h:32, from src/gallium/auxiliary/util/u_math.h:42, from src/mesa/main/macros.h:35, from src/mesa/main/colormac.h:37, from src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28: include/no_extern_c.h:47:1: error: template with C linkage template class _IncludeInsideExternCNotPortable; Any alternative fix ideas besides me adding a if !defined(__HAIKU__) to include/no_extern_c.h? -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/st: Clean up Haiku depth mapping, fix colorspace errors
On 2014-12-27 11:41, Ilia Mirkin wrote: On Sat, Dec 27, 2014 at 1:13 AM, Alexander von Gluck IV wrote: --- src/gallium/state_trackers/hgl/hgl.c | 48 + 1 files changed, 19 insertions(+), 29 deletions(-) diff --git a/src/gallium/state_trackers/hgl/hgl.c b/src/gallium/state_trackers/hgl/hgl.c index 4d7c479..0b30290 100644 --- a/src/gallium/state_trackers/hgl/hgl.c +++ b/src/gallium/state_trackers/hgl/hgl.c @@ -232,9 +232,10 @@ hgl_create_st_visual(ulong options) const GLboolean alphaFlag = ((options & BGL_ALPHA) == BGL_ALPHA); const GLboolean dblFlag = ((options & BGL_DOUBLE) == BGL_DOUBLE); const GLboolean stereoFlag = false; - const GLint depth = (options & BGL_DEPTH) ? 24 : 0; - const GLint stencil = (options & BGL_STENCIL) ? 8 : 0; - const GLint accum = (options & BGL_ACCUM) ? 16 : 0; + const GLboolean depthFlag = ((options & BGL_DEPTH) == BGL_DEPTH); + const GLboolean stencilFlag = ((options & BGL_STENCIL) == BGL_STENCIL); + const GLboolean accumFlag = ((options & BGL_ACCUM) == BGL_ACCUM); + const GLint red = rgbFlag ? 8 : 5; const GLint green = rgbFlag ? 8 : 5; const GLint blue= rgbFlag ? 8 : 5; @@ -244,9 +245,9 @@ hgl_create_st_visual(ulong options) TRACE("alpha:\t%d\n", (bool)alphaFlag); TRACE("dbl :\t%d\n", (bool)dblFlag); TRACE("stereo :\t%d\n", (bool)stereoFlag); - TRACE("depth:\t%d\n", depth); - TRACE("stencil :\t%d\n", stencil); - TRACE("accum:\t%d\n", accum); + TRACE("depth:\t%d\n", (bool)depthFlag); + TRACE("stencil :\t%d\n", (bool)stencilFlag); + TRACE("accum:\t%d\n", (bool)accumFlag); TRACE("red :\t%d\n", red); TRACE("green:\t%d\n", green); TRACE("blue :\t%d\n", blue); @@ -254,34 +255,23 @@ hgl_create_st_visual(ulong options) // Determine color format if (red == 8) { + // Color format if (alpha == 8) - visual->color_format = PIPE_FORMAT_A8R8G8B8_UNORM; + visual->color_format = PIPE_FORMAT_B8G8R8A8_UNORM; else - visual->color_format = PIPE_FORMAT_X8R8G8B8_UNORM; + visual->color_format = PIPE_FORMAT_B8G8R8X8_UNORM; + + // Depth buffer + if (depthFlag) + visual->depth_stencil_format = PIPE_FORMAT_Z32_UNORM; I guess you only work with llvmpipe which supports whatever, but I don't think a lot of hw drivers support Z32_UNORM. Z24 is much more common. Some hardware also supports Z16 and Z32_FLOAT (and Z32_FLOAT_S8X24_UNORM for depth/stencil combined version). Thanks :-). If Z24 is a lot more common i'll go with that one for now. I'm interested to see if we could figure out something with dri3 and C++ in Haiku for hardware support, but that seems pretty far off. Further you appear to have dropped the stencil format here entirely. If that's expected, perhaps get rid of the stencilFlag above? Yeah, I mostly left it there in-case we wanted to set something based on it in the future, that BGL_STENCIL may not be obvious to non-Haiku people :-) Here are the list of flags our OpenGL Kit accepts for new GL contexts: BGL_RGB Use RGB graphics instead of indexed color (8-bit). This is the default if beither BGL_RGB nor BGL_INDEX is specified. BGL_INDEX Use indexed color (8-bit graphics). Not currently supported. BGL_SINGLE Use single-buffering; all rendering is done directly to the display. This is not currently supported by the BeOS implementation of OpenGL. This is the default BGL_DOUBLE Use double-buffered graphics. All rendering is done to an off-screen buffer and only becomes visible when the SwapBuffers() function is called. BGL_ACCUM Requests that the view have an accumulation buffer. BGL_ALPHA Requests that the view's color buffer include an alpha component. BGL_DEPTH Requests that the view have a depth buffer. BGL_STENCIL Requests that the view have a stencil buffer. Right now i'm trying to get rid of the last of the _mesa_* calls from the gallium target as they're cheating a bit. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Build fix for darwin
On 2015-01-03 10:00, Emil Velikov wrote: On 02/01/15 04:14, Jeremy Huddleston Sequoia wrote: This is certainly not the best solution to the problem, so I'm just sending this patch to the list to get the discussion started on the best way to solve this problem. Currently, any platform that does not support _SC_PHYS_PAGES and _SC_PAGESIZE will fail to build swrast. _SC_PHYS_PAGES is not POSIX and thus there are many platforms out there that don't support it (such as OS X). With the indentation fixed and a guard around the new includes this should be safe to go as is. Pretty sure the latter don't exist on all of mesa's supported platforms. Cc'ing Alexander (Haiku). Actually, Haiku is good to go here :-) ~> grep -R "_SC_PHYS_PAGES" /boot/system/develop/headers/ /boot/system/develop/headers/posix/unistd.h:#define _SC_PHYS_PAGES 40 ~> grep -R "_SC_PAGESIZE" /boot/system/develop/headers/ /boot/system/develop/headers/posix/unistd.h:#define _SC_PAGESIZE _SC_PAGE_SIZE ~> grep -R "sysconf" /boot/system/develop/headers/ . . /boot/system/develop/headers/posix/unistd.h:/* sysconf() constants */ /boot/system/develop/headers/posix/unistd.h:extern long sysconf(int name); /boot/system/develop/headers/private/libroot/unistd_private.h:long __sysconf_beos(int name); /boot/system/develop/headers/private/libroot/unistd_private.h:long __sysconf(int name); . . Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/st: Clean up Haiku depth mapping, fix colorspace errors
On 2014-12-29 16:55, Roland Scheidegger wrote: Am 27.12.2014 um 18:41 schrieb Ilia Mirkin: On Sat, Dec 27, 2014 at 1:13 AM, Alexander von Gluck IV wrote: --- src/gallium/state_trackers/hgl/hgl.c | 48 + 1 files changed, 19 insertions(+), 29 deletions(-) @@ -244,9 +245,9 @@ hgl_create_st_visual(ulong options) TRACE("alpha:\t%d\n", (bool)alphaFlag); TRACE("dbl :\t%d\n", (bool)dblFlag); TRACE("stereo :\t%d\n", (bool)stereoFlag); - TRACE("depth:\t%d\n", depth); - TRACE("stencil :\t%d\n", stencil); - TRACE("accum:\t%d\n", accum); + TRACE("depth:\t%d\n", (bool)depthFlag); + TRACE("stencil :\t%d\n", (bool)stencilFlag); + TRACE("accum:\t%d\n", (bool)accumFlag); TRACE("red :\t%d\n", red); TRACE("green:\t%d\n", green); TRACE("blue :\t%d\n", blue); @@ -254,34 +255,23 @@ hgl_create_st_visual(ulong options) // Determine color format if (red == 8) { + // Color format if (alpha == 8) - visual->color_format = PIPE_FORMAT_A8R8G8B8_UNORM; + visual->color_format = PIPE_FORMAT_B8G8R8A8_UNORM; else - visual->color_format = PIPE_FORMAT_X8R8G8B8_UNORM; + visual->color_format = PIPE_FORMAT_B8G8R8X8_UNORM; + + // Depth buffer + if (depthFlag) + visual->depth_stencil_format = PIPE_FORMAT_Z32_UNORM; I guess you only work with llvmpipe which supports whatever, but I don't think a lot of hw drivers support Z32_UNORM. Z24 is much more common. Some hardware also supports Z16 and Z32_FLOAT (and Z32_FLOAT_S8X24_UNORM for depth/stencil combined version). FWIW llvmpipe (and softpipe) do not really support z32_unorm neither, it should never be used. (The reason is just like hw most things are done with floats, so you've got only 24bit mantissa bits to work with really). So, while it may work, the precision is probably not what you expected and if you rely on some specific accuracy (for instance for depth offsets) the results may be somewhat bogus. We actually wanted to drop the format entirely at some point, could still do it at some point. Similar things can be said about the other 32bit snorm/unorm formats though IIRC these are sort of necessary for supporting gl vertex attribs which can be 32bit normalized, but they should not be needed as render target / texture support. So indeed z24 (with or without stencil), z16_unorm if that's good enough or z32_float should be used. I actually just rewrote pretty much all of our state_tracker code. I was cheating in a a few places and using _mesa_* calls vs using stamps :-) The patch can be found here: http://unixzen.com/patchwork/0001-gallium-state_tracker-Rewrite-Haiku-s-state-tracker.patch This isn't final, so i'm not attaching it to the ML just yet. My remaining issue is when I have an OpenGL window open, and resize it, the rendered item remains in the bottom left corner of the viewport at the original size. This didn't happen-pre this patch. (attached) I can say that: * The winsys bitmap resizes with the window * The state_tracker frame buffer gets destroyed and recreated that the proper size. So no idea what i'm missing :-) Feedback very, very, welcome. -- Alex___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] egl: Resolve Haiku build issues
On 2014-12-22 09:17, Emil Velikov wrote: On 22/12/14 14:36, Alexander von Gluck IV wrote: From: Adrián Arroyo Calle * Builds perfect and it loads the driver. * It still reports EGL_NOT_INITIALIZED --- src/egl/drivers/dri2/SConscript |8 +++- src/egl/drivers/dri2/platform_haiku.cpp |4 src/egl/main/SConscript |4 ++-- src/egl/main/egldisplay.c |3 ++- src/egl/main/egldisplay.h |1 + 5 files changed, 16 insertions(+), 4 deletions(-) diff --git a/src/egl/drivers/dri2/SConscript b/src/egl/drivers/dri2/SConscript index 2c081d2..26765c5 100644 --- a/src/egl/drivers/dri2/SConscript +++ b/src/egl/drivers/dri2/SConscript @@ -20,6 +20,7 @@ if env['platform'] == 'haiku': sources.append('platform_haiku.cpp') env.Append(CPPDEFINES = [ 'HAVE_HAIKU_PLATFORM', +'_EGL_NATIVE_PLATFORM=haiku', ]) if env['x11']: @@ -27,11 +28,16 @@ if env['x11']: env.Append(CPPDEFINES = [ 'HAVE_X11_PLATFORM', ]) -env.Append([CPPPATH = [ +env.Append(CPPPATH = [ #'XCB_DRI2_CFLAGS', ]) +env.Prepend(LIBS = [ +libloader, +]) + egl_dri2 = env.ConvenienceLibrary( +#egl_dri2 = env.SharedLibrary( target = 'egl_dri2', source = sources, ) diff --git a/src/egl/drivers/dri2/platform_haiku.cpp b/src/egl/drivers/dri2/platform_haiku.cpp index 15e6c95..ef85e27 100644 --- a/src/egl/drivers/dri2/platform_haiku.cpp +++ b/src/egl/drivers/dri2/platform_haiku.cpp @@ -26,10 +26,14 @@ #include #include +extern "C" { + #include "loader.h" #include "egl_dri2.h" #include "egl_dri2_fallbacks.h" +} + Please don't do this. Do annotate the headers properly rather than adding the extern "C" here. Check this [1] out for more information. All of the dri2 changes were later removed... thus me working on a single less confusing patch :-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/12] egl_dri2: a ton of blob
On 2014-12-22 08:45, kallisti5 wrote: On 2014-12-22 08:41, Matt Turner wrote: On Mon, Dec 22, 2014 at 6:36 AM, Alexander von Gluck IV wrote: From: Emil Velikov Attempt to get a egl_dri2 SConscript - Drop going into the gallium egl-static - Promote the main library to a shared one. - Convert libEGL_Haiku into a conv. library - shove a demo platform_x11. - s/HAVE_EGL_PLATFORM_HAIKU/HAVE_HAIKU_PLATFORM/ - A ton of extra crap all over. Not even build tested, and I don't expect it to build properly yet. Presumably the commit message needs to be updated?! At the time of that message it wasn't. Later commits fixed that. :-) I can redo all of this into one big 801 line patch (which actually might be easier to review as some DRI2 stuff was added, then removed.. -- Alex Actually, yeah. I just did a git diff HEAD~12 and saw some stuff I *really* didn't like that wasn't visible in the 12 patch set. Let me post the single patch file and see what everyone thinks. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/12] egl: Adding Haiku configs, not stable yet
On 2014-12-22 09:24, Emil Velikov wrote: On 22/12/14 14:36, Alexander von Gluck IV wrote: From: Adrián Arroyo Calle --- src/egl/drivers/dri2/egl_dri2.c |7 ++ src/egl/drivers/dri2/platform_haiku.cpp | 172 +-- src/egl/main/SConscript | 14 ++- src/egl/main/egldisplay.c |4 + 4 files changed, 160 insertions(+), 37 deletions(-) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 062fb54..5bda4fd 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -398,9 +398,16 @@ dri2_open_driver(_EGLDisplay *disp) "%.*s/tls/%s_dri.so", len, p, dri2_dpy->driver_name); dri2_dpy->driver = dlopen(path, RTLD_NOW | RTLD_GLOBAL); #endif + + if (dri2_dpy->driver == NULL) { +#ifndef HAVE_HAIKU_PLATFORM snprintf(path, sizeof path, "%.*s/%s_dri.so", len, p, dri2_dpy->driver_name); +#else +snprintf(path, sizeof path, + "lib%s.so",len,p,dri2_dpy->driver_name); +#endif Imho Haiku's way of "reinventing" the DRI model/modules is rather unfortunate, and it would be nice if it can just follow suite. Unless of course there is some real (technical) reasons which prohibits it from going otherwise. A few reasons: * libpciaccess needs ported to Haiku to use dri2 or wrapper code needs created. * our video card driver model is substantially different from Linux splitting apart the card driver from the card functions. The driver only enables multiple accelerants to connect to the card device (/dev/graphics/radeonhd_0_0) at once. The driver sets up memory areas and passes these areas to each accelerant. It could be done but it would require someone with deep understanding of dri2 and Haiku's graphics card stack. * Our OpenGL subsystem works using the Mesa GL Dispatch code adding additional complexity. http://cgit.freedesktop.org/mesa/mesa/tree/src/hgl/GLDispatcher.cpp And the biggest reason: * I don't have a ton of free time anymore due to a baby :-) If someone smarter than me could figure out how to do dri2 in a way that makes sense we would likely jump on it to help reduce upkeep for Mesa (and us) -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/12] egl_dri2: a ton of blob
On 2014-12-22 08:41, Matt Turner wrote: On Mon, Dec 22, 2014 at 6:36 AM, Alexander von Gluck IV wrote: From: Emil Velikov Attempt to get a egl_dri2 SConscript - Drop going into the gallium egl-static - Promote the main library to a shared one. - Convert libEGL_Haiku into a conv. library - shove a demo platform_x11. - s/HAVE_EGL_PLATFORM_HAIKU/HAVE_HAIKU_PLATFORM/ - A ton of extra crap all over. Not even build tested, and I don't expect it to build properly yet. Presumably the commit message needs to be updated?! At the time of that message it wasn't. Later commits fixed that. :-) I can redo all of this into one big 801 line patch (which actually might be easier to review as some DRI2 stuff was added, then removed.. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] egl: add void library, we need to implement driver on platform_haiku.cpp
On 2014-12-22 08:36, Alexander von Gluck IV wrote: From: Adrián Arroyo Calle --- include/EGL/eglplatform.h | 10 ++- src/SConscript |3 +- src/egl/drivers/dri2/SConscript | 24 + src/egl/drivers/dri2/platform_haiku.cpp | 42 +++ src/egl/main/SConscript |2 +- 5 files changed, 78 insertions(+), 3 deletions(-) create mode 100644 src/egl/drivers/dri2/SConscript create mode 100644 src/egl/drivers/dri2/platform_haiku.cpp This is the work of our Google Code In Student to add EGL support for Haiku. Style can be little rough in spots (someof which Emil Velikov has cleaned up) I plan on improving some of the submitted work, but it should be all pretty solid. GCI Task: https://www.google-melange.com/gci/task/view/google/gci2014/5869503078465536 A test application for Haiku showing usage is located here: https://gist.github.com/AdrianArroyoCalle/6df6685582a2afd8a079 -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 2/8] mesa: bump required GCC version to 4.1.0
On 2014-12-14 09:22, kallisti5 wrote: On 2014-12-14 08:45, Emil Velikov wrote: On 12/12/14 11:46, Timothy Arceri wrote: Signed-off-by: Timothy Arceri --- Its been just under 5 years since the required version of GCC was set at 3.3.0 at the time it was 7 years old. I'm proposing bumping it to 4.1.0 which is almost 9 years old since its used in RHEL 5 which is still supported. For the record if it was set to 4.3.0 there would be very few version checks needed at all. Nicely done Timothy. Can we just get a confirmation from Alexander von Gluck IV. IIRC he is/was building mesa with gcc 3. Alexander, what were the details about the gcc 3 build ? I take it that you'll be ok with moving to gcc 4.1.0+ ? We'll be fine :-), we're using GCC 4.8.3 on our modern builds. We are using GCC 2.9x for the "BeOS ABI compatible" builds, but we forked Mesa 7.9.2 which seems to be the absolute last version of Mesa that will compile under GCC 2.9x :-) https://github.com/haiku/mesa_legacy Also, I sent an email about removing the SUNPRO C version checks, but it seems like it was never delivered: Nevermind, I just saw Timothy's response to that :-) -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 6/8] mesa: remove support for GCC older than 4.1.0
On 2014-12-12 05:46, Timothy Arceri wrote: Signed-off-by: Timothy Arceri --- src/mesa/main/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 34671dc..cdc843d 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -122,7 +122,7 @@ extern "C" { * inline a static function that we later use in an alias. - ajax */ #ifndef PUBLIC -# if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)) +# if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)) #define PUBLIC __attribute__((visibility("default"))) #define USED __attribute__((used)) # else Why not also drop the SUNPRO_C version check? # if defined(__GNUC__) || defined(__SUNPRO_C) I downloaded SunStudio 12 (circa 2007) and __SUNPRO_C is set to 0x590. If we drop support for GCC 4.1 (2007), might as well drop older sun compilers. -- Alex #include int main() { printf("0x%X\n", __SUNPRO_C); return 0; } user@desktop bin :) $ ./cc test.c user@desktop bin :) $ ./a.out 0x590 user@desktop bin :) $ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 2/8] mesa: bump required GCC version to 4.1.0
On 2014-12-14 08:45, Emil Velikov wrote: On 12/12/14 11:46, Timothy Arceri wrote: Signed-off-by: Timothy Arceri --- Its been just under 5 years since the required version of GCC was set at 3.3.0 at the time it was 7 years old. I'm proposing bumping it to 4.1.0 which is almost 9 years old since its used in RHEL 5 which is still supported. For the record if it was set to 4.3.0 there would be very few version checks needed at all. Nicely done Timothy. Can we just get a confirmation from Alexander von Gluck IV. IIRC he is/was building mesa with gcc 3. Alexander, what were the details about the gcc 3 build ? I take it that you'll be ok with moving to gcc 4.1.0+ ? We'll be fine :-), we're using GCC 4.8.3 on our modern builds. We are using GCC 2.9x for the "BeOS ABI compatible" builds, but we forked Mesa 7.9.2 which seems to be the absolute last version of Mesa that will compile under GCC 2.9x :-) https://github.com/haiku/mesa_legacy Also, I sent an email about removing the SUNPRO C version checks, but it seems like it was never delivered: " Why not also drop the SUNPRO_C version check? # if defined(__GNUC__) || defined(__SUNPRO_C) I downloaded SunStudio 12 (circa 2007) and __SUNPRO_C is set to 0x590. If we drop support for GCC 4.1 (2007), might as well drop older sun compilers. -- Alex #include int main() { printf("0x%X\n", __SUNPRO_C); return 0; } user@desktop bin :) $ ./cc test.c user@desktop bin :) $ ./a.out 0x590 user@desktop bin :) $ " -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes - resolved
On 2012-09-30 12:49 pm, Matt Turner wrote: On Sun, Sep 30, 2012 at 10:27 AM, kallisti5 wrote: On 2012-09-30 12:16 pm, Kenneth Graunke wrote: On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p "glcpp_parser_" option. This changes the prefix on all functions from the generic "yy" to "glcpp_parser_" to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. We're using the scons build system :) I checked and don't see any lex.yy.c generated in the tree. -- Alex Oh, scons. https://bugs.freedesktop.org/show_bug.cgi?id=54947 I can confirm this is resolved after the following commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=e642d61d130b725c0c3efbc87f86a4968311ba2a The Mesa 9.0 branch now builds under Haiku again. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
On 2012-09-30 12:16 pm, Kenneth Graunke wrote: On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p "glcpp_parser_" option. This changes the prefix on all functions from the generic "yy" to "glcpp_parser_" to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. We're using the scons build system :) I checked and don't see any lex.yy.c generated in the tree. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
A small note, I updated our bison from 2.5 -> 2.6.2 and still see the same error. I'm tempted to add __HAIKU__ def's around the removed code in 8f7990c5f2... but that seems dirty. -- Alex On 2012-09-30 9:37 am, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0&id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Add Haiku build support
From: Alexander von Gluck IV * Add Haiku as a platform to mklib * Fix GLU to allow building static libGLU * Remove a few existing Haiku defines that break the build --- Makefile |1 + acinclude.m4 |2 +- bin/mklib| 37 ++ src/gallium/auxiliary/os/os_thread.h |2 +- src/gallium/auxiliary/util/u_debug.h |2 - src/gallium/drivers/r300/Makefile|1 + src/glsl/link_uniforms.cpp |3 +- src/glu/sgi/Makefile | 15 +++-- src/mesa/main/querymatrix.c |2 +- 9 files changed, 51 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index cf6555c..4caa8ce 100644 --- a/Makefile +++ b/Makefile @@ -90,6 +90,7 @@ freebsd \ freebsd-dri \ freebsd-dri-amd64 \ freebsd-dri-x86 \ +haiku \ hpux10 \ hpux10-gcc \ hpux10-static \ diff --git a/acinclude.m4 b/acinclude.m4 index a5b389d..33ed8a8 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -34,7 +34,7 @@ if test "$enable_pic" != no; then # see if we're using GCC if test "x$GCC" = xyes; then case "$host_os" in -aix*|beos*|cygwin*|irix5*|irix6*|osf3*|osf4*|osf5*) +aix*|cygwin*|haiku*|irix5*|irix6*|osf3*|osf4*|osf5*) # PIC is the default for these OSes. ;; mingw*|os2*|pw32*) diff --git a/bin/mklib b/bin/mklib index 70bd1a2..ca4b62c 100755 --- a/bin/mklib +++ b/bin/mklib @@ -959,6 +959,43 @@ case $ARCH in fi ;; +'Haiku') +if [ $STATIC = 1 ] ; then +LIBNAME="lib${LIBNAME}.a" +if [ "x$LINK" = "x" ] ; then +# -linker was not specified so set default link command now +if [ $CPLUSPLUS = 1 ] ; then +LINK=g++ +else +LINK=gcc +fi +fi + +OPTS="-ru" +if [ "${ALTOPTS}" ] ; then +OPTS=${ALTOPTS} +fi + +echo "mklib: Making static library for Haiku: " ${LIBNAME} + +# expand .a into .o files +NEW_OBJECTS=`expand_archives ${LIBNAME}.obj $OBJECTS` + +# make static lib +FINAL_LIBS=`make_ar_static_lib ${OPTS} 1 ${LIBNAME} ${NEW_OBJECTS}` + +# remove temporary extracted .o files +rm -rf ${LIBNAME}.obj +else +LIBNAME="lib${LIBNAME}.so" # prefix with "lib", suffix with ".so" +OPTS="-shared" + +echo "mklib: Making shared library for Haiku: " ${LIBNAME} + ${LINK} ${OPTS} ${LDFLAGS} ${OBJECTS} ${DEPS} -o ${LIBNAME} +FINAL_LIBS="${LIBNAME}" +fi +;; + 'example') # If you're adding support for a new architecture, you can # start with this: diff --git a/src/gallium/auxiliary/os/os_thread.h b/src/gallium/auxiliary/os/os_thread.h index d830129..3e1c273 100644 --- a/src/gallium/auxiliary/os/os_thread.h +++ b/src/gallium/auxiliary/os/os_thread.h @@ -314,7 +314,7 @@ typedef int64_t pipe_condvar; * pipe_barrier */ -#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) || defined(PIPE_OS_HAIKU)) && !defined(PIPE_OS_ANDROID) +#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)) && !defined(PIPE_OS_ANDROID) typedef pthread_barrier_t pipe_barrier; diff --git a/src/gallium/auxiliary/util/u_debug.h b/src/gallium/auxiliary/util/u_debug.h index b5ea405..677e478 100644 --- a/src/gallium/auxiliary/util/u_debug.h +++ b/src/gallium/auxiliary/util/u_debug.h @@ -75,7 +75,6 @@ _debug_printf(const char *format, ...) * - avoid outputing large strings (512 bytes is the current maximum length * that is guaranteed to be printed in all platforms) */ -#if !defined(PIPE_OS_HAIKU) static INLINE void debug_printf(const char *format, ...) _util_printf_format(1,2); @@ -92,7 +91,6 @@ debug_printf(const char *format, ...) #endif } -#endif /* !PIPE_OS_HAIKU */ /* * ... isn't portable so we need to pass arguments in parentheses. diff --git a/src/gallium/drivers/r300/Makefile b/src/gallium/drivers/r300/Makefile index 5f56fc4..3e3a765 100644 --- a/src/gallium/drivers/r300/Makefile +++ b/src/gallium/drivers/r300/Makefile @@ -15,6 +15,7 @@ C_SOURCES += \ LIBRARY_INCLUDES = \ -I$(TOP)/include \ -I$(TOP)/src/mesa \ + -I$(TOP)/src/mapi \ -I$(TOP)/src/glsl include ../../Makefile.template diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp index c7de480..f2e6648 100644 --- a/src/glsl/link_uniforms.cpp +++ b/src/glsl/link_uniforms.cpp @@ -336,9 +336,8 @@ link_assign_uniform_locations(struct gl_shader_program *prog) rzalloc_array(prog, struct gl_uniform_storage, num_user_uniforms); union gl_constant_value *data = rzalloc_array(uniforms, union gl_constant_value, num_data_slots); -#ifndef ND