Thread: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Fixes here latest issues with mesa master GIT [1].

--
Sedat

[1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2

Fixed in master without requiring new libdrm.

-Marek

On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...>wrote:

> Fixes here latest issues with mesa master GIT [1].
>
> --
> Sedat
>
> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>

Thanks for the turbo fix, but you workarounded the "real" bug.

With my patch I get here in build.log:
...
checking for LIBDRM... yes
...
checking for LIBDRM_RADEON... no
...

With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
should immediately stop while libdrm package here has version 2.4.18.
BUT, that is not the case!

Intel_drm has in configure.ac:
...
case $DRI_DIRS in
*i915*|*i965*)
    PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 2.4.19])
    ;;
esac
...

radeon_libdrm on the contrary:
...
case $DRI_DIRS in
*radeon*|*r200*|*r300*|*r600*)
    PKG_CHECK_MODULES([LIBDRM_RADEON],
                      [libdrm_radeon libdrm >= $LIBDRM_RADEON_REQUIRED],
                      HAVE_LIBDRM_RADEON=yes,
                      HAVE_LIBDRM_RADEON=no)

    if test "$HAVE_LIBDRM_RADEON" = yes; then
        RADEON_CFLAGS="-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS"
        RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS
    fi
    ;;
esac
...

IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am
not an autotools expert.
I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be
handled like in libdrm_intel (...be removed and simplified).

Feedback welcome!

--
Sedat

On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák <ma...@gm...> wrote:
> Fixed in master without requiring new libdrm.
>
> -Marek
>
> On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Fixes here latest issues with mesa master GIT [1].
>>
>> --
>> Sedat
>>
>> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
>
>

On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek <sed...@go...>wrote:

> Thanks for the turbo fix, but you workarounded the "real" bug.
>

Frankly, the Mesa build system isn't my area and I don't want to have
anything to do with it.

The square microtiling is now disabled on both older kernels which don't
support it and older libdrm's which don't have the flag defined. No need to
have bleeding-edge stuff of everything is the way to go as long as it
doesn't get messy.

-Marek

> With my patch I get here in build.log:
> ...
> checking for LIBDRM... yes
> ...
> checking for LIBDRM_RADEON... no
> ...
>
> With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
> should immediately stop while libdrm package here has version 2.4.18.
> BUT, that is not the case!
>
> Intel_drm has in configure.ac:
> ...
> case $DRI_DIRS in
> *i915*|*i965*)
>    PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 2.4.19])
>    ;;
> esac
> ...
>
> radeon_libdrm on the contrary:
> ...
> case $DRI_DIRS in
> *radeon*|*r200*|*r300*|*r600*)
>    PKG_CHECK_MODULES([LIBDRM_RADEON],
>                      [libdrm_radeon libdrm >= $LIBDRM_RADEON_REQUIRED],
>                      HAVE_LIBDRM_RADEON=yes,
>                      HAVE_LIBDRM_RADEON=no)
>
>    if test "$HAVE_LIBDRM_RADEON" = yes; then
>        RADEON_CFLAGS="-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS"
>        RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS
>    fi
>    ;;
> esac
> ...
>
> IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am
> not an autotools expert.
> I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be
> handled like in libdrm_intel (...be removed and simplified).
>
> Feedback welcome!
>
> --
> Sedat
>
> On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák <ma...@gm...> wrote:
> > Fixed in master without requiring new libdrm.
> >
> > -Marek
> >
> > On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...
> >
> > wrote:
> >>
> >> Fixes here latest issues with mesa master GIT [1].
> >>
> >> --
> >> Sedat
> >>
> >> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Mesa3d-dev mailing list
> >> Mes...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >>
> >
> >
>

On Tue, Mar 23, 2010 at 6:37 PM, Marek Olšák <ma...@gm...> wrote:
> On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Thanks for the turbo fix, but you workarounded the "real" bug.
>
> Frankly, the Mesa build system isn't my area and I don't want to have
> anything to do with it.
>

This was the first time for me to have a closer look into the
build-system and I am still learning to understand.

> The square microtiling is now disabled on both older kernels which don't
> support it and older libdrm's which don't have the flag defined. No need to
> have bleeding-edge stuff of everything is the way to go as long as it
> doesn't get messy.
>

No problem with that kind of strategy and I am really happy we don't
need a depends version-bump.

One small critic as I have noticed several times in your commits:
It's helpful for people following the WIP development to have some
documented text in the commit-body especially when it is fixing:
* a previous b0rked commit - by adding its commit-no
* an fd.o bug - by adding its bug-no
* ...

--
Sedat