On Thu, Sep 12, 2013 at 3:32 PM, Christian König
wrote:
> 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
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 librarie
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
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
mas
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
wrote:
> I see current situation is better:
>
> Symbol table '.dynsym
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
libmesacore
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
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 th
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 unnece
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
--with-gallium-drivers=freedreno,
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 wrote:
> 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/4
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
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]
13 matches
Mail list logo
