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

[Colin Finck]

[e-mail] wrote:
> [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 implementation present in
> opengl32.

That sounds fantastic! I'm just wondering, if it is better than our
current OpenGL software rendering in every regard, can't we just have it
as the default in our tree?

- Colin

[Kamil Hornicek]

Hi,
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.

It's much easier to download Mesa's sources for give or take every other 
minor release and package it and I'm willing to do that.

Kamil

Dne 20.3.2017 9:06, Colin Finck napsal(a):
> [e-mail] wrote:
> > [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 implementation present in
> > opengl32.
>
> That sounds fantastic! I'm just wondering, if it is better than our
> current OpenGL software rendering in every regard, can't we just have it
> as the default in our tree?
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Jerome Gardou]

I have to say that I also like it very much :-) For having tried that, I 
can only stand in awe seeing someone mastering the whole stack needed to 
compile the damn thing on windows.

Jérôme

Le 20/03/2017 à 09:44, Kamil Hornicek a écrit :
> Hi,
> 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.
>
> It's much easier to download Mesa's sources for give or take every 
> other minor release and package it and I'm willing to do that.
>
> Kamil
>
> Dne 20.3.2017 9:06, Colin Finck napsal(a):
> > [e-mail] wrote:
> > > [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 implementation present in
> > > opengl32.
> >
> > That sounds fantastic! I'm just wondering, if it is better than our
> > current OpenGL software rendering in every regard, can't we just have it
> > as the default in our tree?
> > Colin
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

please please please write some user manual in wiki

plizzzzzzzzzzzzzzzzzzz

On Mon, Mar 20, 2017 at 9:44 PM, Jerome Gardou [e-mail]
wrote:
> I have to say that I also like it very much :-) For having tried that, I
> can only stand in awe seeing someone mastering the whole stack needed to
> compile the damn thing on windows.
>
> Jérôme
>
> Le 20/03/2017 à 09:44, Kamil Hornicek a écrit :
> > Hi,
> > 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.
> >
> > It's much easier to download Mesa's sources for give or take every other
> > minor release and package it and I'm willing to do that.
> >
> > Kamil
> >
> > Dne 20.3.2017 9:06, Colin Finck napsal(a):
> > > [e-mail] wrote:
> > > > [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 implementation present in
> > > > opengl32.
> > >
> > > That sounds fantastic! I'm just wondering, if it is better than our
> > > current OpenGL software rendering in every regard, can't we just have it
> > > as the default in our tree?
> > > Colin
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

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

[Hermès BÉLUSCA-MAÏTO]

And another reason to make our SVN source tree structure modularized.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Colin Finck
Envoyé : lundi 20 mars 2017 23:05
À : [e-mail]
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
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Zachary Gorden]

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 <[e-mail]
> wrote:
> And another reason to make our SVN source tree structure modularized.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Colin
> Finck
> Envoyé : lundi 20 mars 2017 23:05
> À : [e-mail]
> 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Kamil Hornicek]

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
> <[e-mail] mailto:[e-mail]> wrote:
> And another reason to make our SVN source tree structure modularized.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]
> <mailto:[e-mail]>] De la part de Colin Finck
> Envoyé : lundi 20 mars 2017 23:05
> À : [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> http://www.reactos.org/mailman/listinfo/ros-dev
> <http://www.reactos.org/mailman/listinfo/ros-dev>
>
>
> _______________________________________________
> Ros-dev mailing list
> [e-mail] <mailto:[e-mail]>
> http://www.reactos.org/mailman/listinfo/ros-dev
> <http://www.reactos.org/mailman/listinfo/ros-dev>
>
>
>
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Mark Jansen]

How about doing the same as with gecko?
Provide the user with a question (or a list of optional components)
that he can install.

On 21 March 2017 at 10:40, Kamil Hornicek [e-mail] wrote:
> 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
> > <[e-mail] mailto:[e-mail]> wrote:
> > And another reason to make our SVN source tree structure modularized.
> >
> > -----Message d'origine-----
> > De : Ros-dev [mailto:[e-mail]
> > <mailto:[e-mail]>] De la part de Colin Finck
> > Envoyé : lundi 20 mars 2017 23:05
> > À : [e-mail] <mailto:[e-mail]>
> >
> > 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
> > [e-mail] <mailto:[e-mail]>
> > http://www.reactos.org/mailman/listinfo/ros-dev
> > <http://www.reactos.org/mailman/listinfo/ros-dev>
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail] <mailto:[e-mail]>
> > http://www.reactos.org/mailman/listinfo/ros-dev
> > <http://www.reactos.org/mailman/listinfo/ros-dev>
> >
> >
> >
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Am 21.03.2017 um 10:40 schrieb Kamil Hornicek:
> Mesa sources is 5k files, llvm is 15k, so we have 20k files we'd have
>
> to add to trunk.

Ok, that's indeed a huge undertaking! Although I also got mkisofs with
its special build system integrated into our CMake setup and reduced
from at least 1k files to around 130 for our needs :)

My main concern is that building this Mesa/Gallium/llvmpipe stack
doesn't become secret voodoo magic only known to a single person.
I like to keep the sources of all ReactOS components together. That
doesn't need to be a single repository. It even doesn't need to be a
module for our CMake setup.
But if building that stack for Windows requires e.g. putting 3 source
trees together, changing some lines here and there and adding an
installer, then it should be easier to do that in a Git repo than
carrying around instructions and patches.

Just some suggestions. You're free to do it however you prefer :)

- Colin

[Pranay Pratyush]

Hi there,
I have shared my GSOC proposal draft
https://docs.google.com/document/d/1wVvUyWX6TbuGpwGtiRa28IROOCwKPkmqPdQLHaHA9VU/edit?usp=sharing.
It's really crude right now because I am yet to figure to go through all
reactos code and figure out what exactly I need to do. Please comment on
the proposal and help me improve it.
Thank You

--
*Pranay Pratyush,*
3rd year undergraduate ,
Computer Science and Engineering Department
Indian Institute Of Technology, Kharagpur
--

[Javier Agustìn Fernàndez Arroyo]

what about adding this app too? its open source!

http://www2.cs.uidaho.edu/~jeffery/win32/wglgears.exe

http://www2.cs.uidaho.edu/~jeffery/win32/wglgears.c

from:

http://www2.cs.uidaho.edu/~jeffery/win32/

On Tue, Mar 21, 2017 at 7:10 PM, Pranay Pratyush [e-mail]
wrote:
> Hi there,
> I have shared my GSOC proposal draft
> https://docs.google.com/document/d/1wVvUyWX6TbuGpwGtiRa28IROOCwKPkmqPdQLHaHA9VU/edit?usp=sharing.
> It's really crude right now because I am yet to figure to go through all
> reactos code and figure out what exactly I need to do. Please comment on
> the proposal and help me improve it.
> Thank You
>
> --
> *Pranay Pratyush,*
> 3rd year undergraduate ,
> Computer Science and Engineering Department
> Indian Institute Of Technology, Kharagpur
> --
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Michael Fritscher]

Hi,

the "special samba edition" is sort of the same thing I think.

I don't know, but could the mesa source be stripped down?

Best regards,
Michael Fritscher
> And another reason to make our SVN source tree structure modularized.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Colin
> Finck
> Envoyé : lundi 20 mars 2017 23:05
> À : [e-mail]
> 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Johnsson]

Or, maybe have a default-rosapps thing? Where you have a build that has
some basic things already installed.

2017-03-21 8:19 GMT+01:00 Michael Fritscher [e-mail]:
> Hi,
>
> the "special samba edition" is sort of the same thing I think.
>
> I don't know, but could the mesa source be stripped down?
>
> Best regards,
> Michael Fritscher
> > And another reason to make our SVN source tree structure modularized.
> >
> > -----Message d'origine-----
> > De : Ros-dev [mailto:[e-mail]] De la part de Colin
> > Finck
> > Envoyé : lundi 20 mars 2017 23:05
> > À : [e-mail]
> > 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev