Re: [Mesa-dev] [PATCH] Haiku: convert to autotools

[kallisti5]

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

[kallisti5]

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 <jerome.du...@gmail.com>
>>> > 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 modification

Re: [Mesa-dev] [PATCH] Haiku: convert to autotools

[kallisti5]

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 <jerome.du...@gmail.com>
> 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

[kallisti5]

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 <jerome.du...@gmail.com>
> 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

[kallisti5]

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

[kallisti5]

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

[kallisti5]

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

[kallisti5]

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.

[kallisti5]

On 2014-12-11 16:14, Jose Fonseca wrote:

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

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
 templateclass T 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
 templateclass T 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
 templateclass T 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] include: Add helper header to help trap includes inside extern C.

[kallisti5]

On 2015-05-13 10:42, Jason Ekstrand wrote:

On May 13, 2015 8:01 AM, kallisti5 kallis...@unixzen.com wrote:
src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28:
  include/no_extern_c.h:47:1: error: template with C linkage
 
   templateclass T 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 1/2] gallium/st: Clean up Haiku depth mapping, fix colorspace errors

[kallisti5]

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
kallis...@unixzen.com 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 1/2] gallium/st: Clean up Haiku depth mapping, fix colorspace errors

[kallisti5]

On 2014-12-27 11:41, Ilia Mirkin wrote:

On Sat, Dec 27, 2014 at 1:13 AM, Alexander von Gluck IV
kallis...@unixzen.com 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

[kallisti5]

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 01/12] egl: add void library, we need to implement driver on platform_haiku.cpp

[kallisti5]

On 2014-12-22 08:36, Alexander von Gluck IV wrote:

From: Adrián Arroyo Calle adrian.arroyoca...@gmail.com

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

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] [PATCH 09/12] egl: Adding Haiku configs, not stable yet

[kallisti5]

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 adrian.arroyoca...@gmail.com

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

[kallisti5]

On 2014-12-22 08:41, Matt Turner wrote:

On Mon, Dec 22, 2014 at 6:36 AM, Alexander von Gluck IV
kallis...@unixzen.com wrote:

From: Emil Velikov emil.l.veli...@gmail.com

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 06/12] egl_dri2: a ton of blob

[kallisti5]

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
kallis...@unixzen.com wrote:

From: Emil Velikov emil.l.veli...@gmail.com

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 08/12] egl: Resolve Haiku build issues

[kallisti5]

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 adrian.arroyoca...@gmail.com

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

+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] [RFC 2/8] mesa: bump required GCC version to 4.1.0

[kallisti5]

On 2014-12-14 08:45, Emil Velikov wrote:

On 12/12/14 11:46, Timothy Arceri wrote:

Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---

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

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] [RFC 2/8] mesa: bump required GCC version to 4.1.0

[kallisti5]

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 t_arc...@yahoo.com.au
---

 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

[kallisti5]

On 2014-12-12 05:46, Timothy Arceri wrote:

Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
 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 stdio.h

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

[Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes

[kallisti5]

Good morning,

It seems 8f7990c5f2 has broken the Haiku build...

http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=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

Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes

[kallisti5]

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.0id=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

Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes

[kallisti5]

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.0id=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 - resolved

[kallisti5]

On 2012-09-30 12:49 pm, Matt Turner wrote:
On Sun, Sep 30, 2012 at 10:27 AM, kallisti5 kallis...@unixzen.com 
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.0id=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.0id=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

[Mesa-dev] [PATCH] mesa: Add Haiku build support

[kallisti5]

From: Alexander von Gluck IV kallis...@unixzen.com

* 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 NDEBUG
+