I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where which each clashing the symbol space
of any application using these drivers with a bunch of
Hi,
On Thursday, September 12, 2013 08:41:10 Christian König wrote:
I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where which each clashing the
On 09/11/2013 11:41 PM, Christian König wrote:
I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where which each clashing the symbol space
of any
I see current situation is better:
Symbol table '.dynsym' contains ...
master:
libdricore: 3675
i965_dri:398
after [PATCH 10/21]:
classic drivers:
libmesacore: 839
libmesadri: 348
total: 1187
i965_dri:397
gallium drivers:
libgallium: 833
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
Marek
On Thu, Sep 12, 2013 at 2:41 PM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
I see current situation is better:
Am Donnerstag, 12. September 2013, 14:52:15 schrieb Marek Olšák:
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
Marek
readelf -s usr/lib64/dri/radeonsi_dri.so
master:
Am 12.09.2013 14:52, schrieb Marek Olšák:
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
Yes that's indeed the right way of doing it, feel free to make the
changes Chia-l
On 09/12/2013 02:44 AM, Kenneth Graunke wrote:
On 09/11/2013 11:41 PM, Christian König wrote:
I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where
[PATCH 01/21] ilo: Fix out-of-tree build.
[PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.
[PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.
[PATCH 04/21] radeon: Build and use libradeon the right way.
Link libradeon only once in
Hi Johannes,
Could explain how you tested these patches: The configure flags you
used to build as well as the applications/hardware you used for testing.
Thanks,
Tom
On Thu, Sep 12, 2013 at 12:32:38AM +0200, Johannes Obermayr wrote:
[PATCH 01/21] ilo: Fix out-of-tree build.
[PATCH 02/21]
I don't like this. I prefer to have one big blob for whole Mesa as
discussed on Eric's blog:
http://anholt.livejournal.com/43652.html
I have no problem with longer compile times for release builds if I
get a little bit higher CPU performance with link-time optimizations.
And for debug builds, we
BTW, the build system fixes would be good to have anyway, but I'm not
an expert on the Mesa build system.
Marek
On Thu, Sep 12, 2013 at 1:51 AM, Marek Olšák mar...@gmail.com wrote:
I don't like this. I prefer to have one big blob for whole Mesa as
discussed on Eric's blog:
I am preferring a full build:
../configure --libdir=/usr/lib64 --includedir=/usr/include --bindir=/usr/bin
--prefix=/usr --sysconfdir=/etc --enable-xvmc --enable-vdpau
--enable-texture-float --enable-debug
--with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast
13 matches
Mail list logo
