Upgrade Mesa, how feasible?

Nothing new.

haiku_gsraytrace
gsraytrace demo on Haiku

@dragon

Mesa 19.1.7 is the last build I successfully compiled on Haiku.

Update:

Do this and test your GL code at this level using the current Haiku Mesa 17.1.10 implementation:
export MESA_GL_OVERRIDE=4.5COMPAT
export MESA_GLSL_VERSION_OVERRIDE=450

NOTE: mesa_swpipe (HGL) supports OpenGL 3.0 context. OpenGL 3.1 context and higher not supported at this time when using mesa_swpipe. :wink:

Just file a bug report in Haikuports if your program misrenders - even with those settings.

I see. Then I have to pass (which I regret a lot). My game engine aims at 3.2+ as minimum for the reason that OGL 3.2+ drastically changed how contexts and profiles are managed.

I am currently dealing with an up-stream bug in MESA right now (in contact with devs and such). I had to compile MESA from GIT for the bug tracking process. It did not seem that complicated but that has been on real 3D hardware. What exactly makes it difficult to build on Haiku?

I donā€™t know what @cocobean is talking about; LLVMpipe should support OpenGL 3.2 already, I think?

Yeah I think so the current latest llvmpipe supports 3.3ā€¦ and recently grew compute shader support. About half of the extensions for opengl 4-4.6 are implemented granted some of the missing ones are big.

The problem you run into is when on 32bit and you are running the older mesaā€¦

You use the older Mesa only if you build with gcc2, which no one sane is going to try at this point. If you use gcc8, even on a 32bit system, you of course get an up to date Mesa.

2 Likes

Thanks for clarifying that. I was pretty sure that was the case but that nails it down.

Your recipe seems to be broken currently.
Otherwise this is not a small or easy task, are you sure you are up to the task? What could we realistically expect as result? Have you worked on MESA source code before on any other platform? Do you plan to upstream your changes? If so, have you contacted the MESA team? Many project states one have to contact them, before start to hack on their code, maybe it is mandatory at MESA too.

EDIT: it seems they switched from auto* based build system to meson. Do you have experience with it?

The license does not dictate this and it would be quite strange if it didā€¦ itā€™s open source! People should hack as they please! :slight_smile:

Mesa and actually most of the Linux graphics stack is MIT licensed so compatible with Haiku in full license wiseā€¦ nobody has to ask permission for anything either only perpetuate the license. The parts of the graphics stack in the Linux kernel are typically dual licensed MIT and GPLā€¦ if you build it in the Linux kernel itā€™s GPL but you can copy it into an MIT project freely without issue due to the dual licensure.

I dont talk about license, i talk about the upstreaming plans. Ofc you can hack whatever you want, but if you want to upstream, better ask and discuss first.

We already have code up stream in Mesaā€¦ they are extremely unlikely to reject code cleanup and fixes as long as they donā€™t break other portsā€¦

Also most of the code needed to implement 3d drivers for real would be in the Haiku kernel and driversā€¦ basically adapting Haiku to be able to load libdrm + Mesa, enabling targeting GPUs in LLVM etcā€¦

Thatā€™s not the problem. The problem is if there are no plans for upstreaming and no coordination with the Mesa team, the maintenance burden will fall on Haikuports team (and extrowerk is one of the active people there, so he is totally right to complain).

If you want to experiment on your side, indeed, thatā€™s great! But donā€™t do so by submitting experimental recipes at haikuports that keep confusing people. I donā€™t know, work in your own fork of haikuports if you want to use it, or work entirely outside of it if you prefer. Remember that anything that lands in Haikuports is immediately unleashed to unsuspecting users, so it is not a good place for experimentation (something we should maybe change, but for now, thatā€™s how it is).

2 Likes

In my experience it is the case that it is excruciating to get anything into Haikuportsā€¦ I got nitpicked to death over a stupid command line package that isnā€™t a dependency for anything. Granted I think there was a bit of warranted gatekeeping since it was my first packageā€¦ but yeah. I didnā€™t have the branch my repo then submit to Haikuports flow down either so that was a little annoying my fault though.

So, the idea that broken packages are getting uploaded with no review at all is indeed concerningā€¦ granted a completely broken package isnā€™t as impactful as a broken package that builds and ends up making it all the way to HaikuDepot.

I gave a try to that receipt but it is indeed not building at all. Since Iā€™m completely new to haikuports I donā€™t know if it is me or the receipt. Itā€™s not in the master branch so chances are something goes wrong by me trying to use the mesa-19.1.7 branch.

Part of which is in Mesaā€¦ to fix this will require changes on both ends for functionality and cleanup reasons according to kallisti5. So, if a package doesnā€™t work at all there is little point in checking it into even a branch in haikuports unless you are going to fix it in the short termā€¦ otherwise it is just a branch sitting around confusing people. Forking Haikuports and having it in your own repo and branch would be the ideal situation if you want to do that.

Software that compiles but doesnā€™t workā€¦ isnā€™t useful. Just because you patched it to compile doesnā€™t mean itā€™s worth putting on the official haikuports, even in a branch, yet because people see that as an update or progress when in reality it isnā€™t.

Which is upstream in mesaā€¦ what is your point.

The stink others brought up was not about discussing anything with Mesa developersā€¦ that was a separate issue. The stink was about dropping broken recipes on official haikuports branchesā€¦ and the code is broken because HGL code in upstream mesa is broken and needs to be fixed and sent back upstream. That way we donā€™t have to updated it every releaseā€¦ when they break the downstream changes because they donā€™t have the code in upstream.

Upstream is broken now because they made some large changes and it just broke upstream and nobody has fixed thatā€¦ downstream fixes should be tested outside of Haikuports, then upstreamed to mesa, then and only then should Haikuports be updated to the new release, otherwise you are just churning out changes to a broken recipe because upstream code is brokenā€¦ fix the problem instead of maintaining a broken package.

This is all very obvious stuffā€¦ and it seems some of the developers have already explained this to you before.

Hey, if you want to do work that canā€™t be used yet because code that is needed to be fixed is indefinitely broken have at it. The fact is compiled or not, that version of mesa cannot work yet with out upstream changes, and probably changes in Haiku also right?

I do think you need to take into consideration that doing work in a branch of haikuports without forking can generate confusion.

For me it isnt. What am i doing wrong? Mako is missing. Building mesa locally with mako installed manually bails out like i said in the PR comment. I dont understand, whats wrong, it just fails. Any idea? You told it is ok to merge, so i wanted to test it, but without any howto i landed onto my face. Ouch!

1 Like

They will definitely say: Update. Frankly, what else should they say?

You know, i am not a developer but i would do it like this, hope it gives you some hints:

  • I want to update MESA
  • MESA is changed (Ouch!)
  • I would analyze what kind of changes would be required in MESA sources and eventually in Haiku
  • I would contact the original porter, discuss about his plans. If he have no time, capacity to mess with it, still can give me some hints
  • Then i would contact the Haiku devs about the plans and the required changes in Haiku (if it is required)
  • Then i would contact MESA, telling them there are problems with the last version, and i am here to fix the Haiku backend. I would talk with them about the actual problems, so they can give me some important technical info, we woud talk about their plans too, because they have some for the next releases for sure. We would then talk about what kind of changes would they accept in mainline, how the upstreaming process should go, who can check the changes from MESA side, etc.
  • Then I would start to work to implement the changes
  • If it is ready, the result will be accepted for sure in MESA and Haiku upstream, as I made it sure beforehand, and not after.

This is how i would do this, but probably i am too naĆÆve, i am sure i forgot about something.

From my viewpoint if you just partially can do this (I mean if you canā€™t actually implement the required changes) then you are wasting time of non-involved non-responsible developers (the MESA guys).

What you can realistically expect from the MESA team is that they contact the original porter and warn him stating: ā€œThe Haiku supporting code needs changes, and if this changes wonā€™t be provided the Haiku support will be deprecated and eventually dropped.ā€
But they definitely wonā€™t say: ā€œAh ok, letā€™s fix it.ā€ They are not responsible for the Haiku related code, and if they would care it would be not broken, but i am not aware any MESA member here. Would be nice, but letā€™s be realistic: for them less platform to support is better.

So at the end you would just generate some extra stress for the original porter, who now have to fix the code, even if he have no capacity currently or had other plans.

This outcome would be unfortunate, even dangerous. Please, calculate with this beforehand, and make sure you donā€™t generate unnecessary problems for others.

If you canā€™t provide the required changes i have an idea how you can still help the MESA update: Create a recipe for mako! That would be really helpful, and you got the experiences to accomplish it.

2 Likes