Basically this. I'll only add few other points:
- Mesa sources is 5k files, llvm is 15k, so we have 20k files we'd have
to add to trunk.
- We had Mesa in our tree once and I only managed to update it once or
twice during the nine(?) years I'm with the project, because it's *HUGE*
and it requires a siginificant effort to pull it off.
- If you're still not convinced you can try updating the Mesa code we
currently have in opengl32 and that's just a tiny chunk of the Mesa
codebase.
Having Mesa in our tree would actually make it much harder to update it,
believe me I've been there.
Also this is just a temporary solution until we fully support graphics
cards drivers. Any more time spent on this would be wasted.
Let's not discuss adding Mesa to the tree, let's instead come up with a
solution for providing the user with some "essential/optional" binaries
during or after the setup process.
K.
Dne 21.3.2017 1:48, Zachary Gorden napsal(a):
Mesa is really not a good example of something that should be added to
the ROS tree due to desired functionality. Its src is almost 5K files by
itself, when trunk is only a little under 20K files. Then there's its
rather esoteric build setup. I'm mildly curious as to whether Kamil
actually built it on Windows or if he needed to pull off a
cross-compilation on Linux instead. Getting RosBE to be able to build
Mesa is a nontrivial exercise. To try to incorporate Mesa is to take on
a large engineering task for what is not necessarily a big payoff. We
have an existing opengl implementation. Its performance sucks, sure, but
if you wanted actually performant 3D graphics you would need to go and
install a proper graphics driver anyway. For out of the box, all it
needs to do is provide a sufficient degree of compatibility.
SVN also has the equivalent of modules, externals. The project just
never bothered setting up the repo to make use of them.
On Mon, Mar 20, 2017 at 6:51 PM, Hermès BÉLUSCA-MAÏTO
<hermes.belu...@sfr.fr <mailto:hermes.belu...@sfr.fr>> wrote:
And another reason to make our SVN source tree structure modularized.
-----Message d'origine-----
De : Ros-dev [mailto:ros-dev-boun...@reactos.org
<mailto:ros-dev-boun...@reactos.org>] De la part de Colin Finck
Envoyé : lundi 20 mars 2017 23:05
À : ros-dev@reactos.org <mailto:ros-dev@reactos.org>
Objet : Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a
custom build of the Mesa 3D Graphics Library. This build contains
mesa, gallium and llvmpipe. It provides an enormous performance
boost over the software implemen...
Am 20.03.2017 um 09:44 schrieb Kamil Hornicek:
> few other people asked me, but Jerome did it right. Mesa code base is
> rather big and llvm is not small either. Integrating it in our
> building process and keeping it in sync would require huge amount of
> effort. It would also increase both the ISOs and the build time.
I'm seeing more and more people afraid of adding anything "big" to
our tree. But this is just natural for a project that aims to become
a fully fledged operating system!
The worst thing would be an OS that can be quickly compiled from
scratch and then needs lots of binary blobs to be useful. Even
worse, those binary blobs could hardly be verified and patched.
Don't forget we already had that with our schannel.dll
implementation that depended on an external GnuTLS binary.
Fortunately, this is fixed by now and ReactOS supports TLS out of
the box.
I would like to see the same for a Mesa/Gallium/llvmpipe stack.
Having one somewhere hidden in RAPPS, but not in an out of the box
ReactOS installation from the ReactOS giveaway CDs would be very
disappointing...
I also understand the group though who wants the default ReactOS
build to be lightweight. So maybe Mesa/Gallium/llvmpipe could become
part of another module which is added through our "modules"
subdirectory.
Our current SVN setup with just one ReactOS repository does not
really encourage adding new modules. Another reason for a move to
Git where everybody could easily put his big module into an own
repository :)
Cheers,
Colin
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org <mailto:Ros-dev@reactos.org>
http://www.reactos.org/mailman/listinfo/ros-dev
<http://www.reactos.org/mailman/listinfo/ros-dev>
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org <mailto:Ros-dev@reactos.org>
http://www.reactos.org/mailman/listinfo/ros-dev
<http://www.reactos.org/mailman/listinfo/ros-dev>
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
