x86_32 mesa on x86_64

[seventh guardian-2]

Hello,

I'm running a 64 bit kernel and using the gallium branch from the
nouveau repository. It's being kept mostly synchronized with your
gallium branch, so this problem should also apply.

Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
rendering obviously reverts to software mode. So I wanted to build a
32 bit version of the libraries to be able to use hardware rendering
(this setup works for the nividia blob), but then things started to go
wrong ;)

First of all, the "-m32" flag is not being used in some of the demos
so gcc complains that I want to link 32 bit code into a 64 bit
executable. I had to add $(ARCH_FLAGS) to some lines in
progs/demos/Makefile for mesa to compile. I'm not sure if this is the
right solution, but a patch goes on annex for this.

After this and some other small tweaks it compiled fine. I have a
"multi-lib" setup with all the necessary xorg 32 bit libs.

Unfortunately, I'm still not getting direct rendering for 32 bit apps.
Can I be doing something wrong? Or is this not expected to work at
all?


As a final comment, I found the build system way too complicated. I
had to tweak the config files a lot, and the used hierarchy duplicates
stuff all over the place. I would definitely prefer having a properly
setup auto-tools environment. Don't take me wrong, I know that some
people don't like auto-tools for several reasons, and in the end it is
a matter of preference.

Cheers,
  Renato Caldas


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul]

seventh guardian wrote:

> Hello,
>
> I'm running a 64 bit kernel and using the gallium branch from the
> nouveau repository. It's being kept mostly synchronized with your
> gallium branch, so this problem should also apply.
>
> Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
> rendering obviously reverts to software mode. So I wanted to build a
> 32 bit version of the libraries to be able to use hardware rendering
> (this setup works for the nividia blob), but then things started to go
> wrong ;)
>
> First of all, the "-m32" flag is not being used in some of the demos
> so gcc complains that I want to link 32 bit code into a 64 bit
> executable. I had to add $(ARCH_FLAGS) to some lines in
> progs/demos/Makefile for mesa to compile. I'm not sure if this is the
> right solution, but a patch goes on annex for this.

It doesn't look like you're using Mesa from git.  At least your patch
doesn't apply there.


> After this and some other small tweaks it compiled fine. I have a
> "multi-lib" setup with all the necessary xorg 32 bit libs.
>
> Unfortunately, I'm still not getting direct rendering for 32 bit apps.
> Can I be doing something wrong? Or is this not expected to work at
> all?

I think you'll have to provide more details.  Does setting
LIBGL_DEBUG=verbose give any hints?


> As a final comment, I found the build system way too complicated. I
> had to tweak the config files a lot, and the used hierarchy duplicates
> stuff all over the place. I would definitely prefer having a properly
> setup auto-tools environment. Don't take me wrong, I know that some
> people don't like auto-tools for several reasons, and in the end it is
> a matter of preference.

We've had autoconf for a while now.  Try the 7.1 release candidate or
get the current code from git.

-Brian


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[seventh guardian-2]

On Mon, Jun 16, 2008 at 4:17 PM, Brian Paul
<brian.paul@...> wrote:

> seventh guardian wrote:
>>
>> Hello,
>>
>> I'm running a 64 bit kernel and using the gallium branch from the
>> nouveau repository. It's being kept mostly synchronized with your
>> gallium branch, so this problem should also apply.
>>
>> Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
>> rendering obviously reverts to software mode. So I wanted to build a
>> 32 bit version of the libraries to be able to use hardware rendering
>> (this setup works for the nividia blob), but then things started to go
>> wrong ;)
>>
>> First of all, the "-m32" flag is not being used in some of the demos
>> so gcc complains that I want to link 32 bit code into a 64 bit
>> executable. I had to add $(ARCH_FLAGS) to some lines in
>> progs/demos/Makefile for mesa to compile. I'm not sure if this is the
>> right solution, but a patch goes on annex for this.
>
> It doesn't look like you're using Mesa from git.  At least your patch
> doesn't apply there.

I'm using origin/gallium-0.1. That's the base for all the current 3d
nouveau work..

>> After this and some other small tweaks it compiled fine. I have a
>> "multi-lib" setup with all the necessary xorg 32 bit libs.
>>
>> Unfortunately, I'm still not getting direct rendering for 32 bit apps.
>> Can I be doing something wrong? Or is this not expected to work at
>> all?
>
> I think you'll have to provide more details.  Does setting
> LIBGL_DEBUG=verbose give any hints?

For some strange reason the app was trying to use the 64 bit libGL.so.
I've fixed that, thanks!

Now I get 90% syslog-ng cpu usage, and checking the logs I get a lot of these:

(...)
Jun 16 16:55:09 pinguinus [drm:drm_unlocked_ioctl] *ERROR* ret = 48 -12
(...)

I'm not sure if this concerns mesa anymore, I'll try to check with the
nouveau drm guys.

>> As a final comment, I found the build system way too complicated. I
>> had to tweak the config files a lot, and the used hierarchy duplicates
>> stuff all over the place. I would definitely prefer having a properly
>> setup auto-tools environment. Don't take me wrong, I know that some
>> people don't like auto-tools for several reasons, and in the end it is
>> a matter of preference.
>
> We've had autoconf for a while now.  Try the 7.1 release candidate or get
> the current code from git.

Oh, I see that the master branch has autoconf. Are there any plans to
use autoconf for the origin/gallium-0.1 branch?

Cheers,
  Renato

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul]

seventh guardian wrote:

> On Mon, Jun 16, 2008 at 4:17 PM, Brian Paul
> <brian.paul@...> wrote:
>> seventh guardian wrote:
>>> Hello,
>>>
>>> I'm running a 64 bit kernel and using the gallium branch from the
>>> nouveau repository. It's being kept mostly synchronized with your
>>> gallium branch, so this problem should also apply.
>>>
>>> Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
>>> rendering obviously reverts to software mode. So I wanted to build a
>>> 32 bit version of the libraries to be able to use hardware rendering
>>> (this setup works for the nividia blob), but then things started to go
>>> wrong ;)
>>>
>>> First of all, the "-m32" flag is not being used in some of the demos
>>> so gcc complains that I want to link 32 bit code into a 64 bit
>>> executable. I had to add $(ARCH_FLAGS) to some lines in
>>> progs/demos/Makefile for mesa to compile. I'm not sure if this is the
>>> right solution, but a patch goes on annex for this.
>> It doesn't look like you're using Mesa from git.  At least your patch
>> doesn't apply there.
>
> I'm using origin/gallium-0.1. That's the base for all the current 3d
> nouveau work..

Sorry, I missed where you wrote that before.  I'll apply your Makefile
patch.

>>> After this and some other small tweaks it compiled fine. I have a
>>> "multi-lib" setup with all the necessary xorg 32 bit libs.
>>>
>>> Unfortunately, I'm still not getting direct rendering for 32 bit apps.
>>> Can I be doing something wrong? Or is this not expected to work at
>>> all?
>> I think you'll have to provide more details.  Does setting
>> LIBGL_DEBUG=verbose give any hints?
>
> For some strange reason the app was trying to use the 64 bit libGL.so.
> I've fixed that, thanks!
>
> Now I get 90% syslog-ng cpu usage, and checking the logs I get a lot of these:
>
> (...)
> Jun 16 16:55:09 pinguinus [drm:drm_unlocked_ioctl] *ERROR* ret = 48 -12
> (...)
>
> I'm not sure if this concerns mesa anymore, I'll try to check with the
> nouveau drm guys.
>
>>> As a final comment, I found the build system way too complicated. I
>>> had to tweak the config files a lot, and the used hierarchy duplicates
>>> stuff all over the place. I would definitely prefer having a properly
>>> setup auto-tools environment. Don't take me wrong, I know that some
>>> people don't like auto-tools for several reasons, and in the end it is
>>> a matter of preference.
>> We've had autoconf for a while now.  Try the 7.1 release candidate or get
>> the current code from git.
>
> Oh, I see that the master branch has autoconf. Are there any plans to
> use autoconf for the origin/gallium-0.1 branch?

No plans for now.  Too busy w/ other things.

Feel free to try bringing it over yourself.

-Brian

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[seventh guardian-2]

On Mon, Jun 16, 2008 at 10:07 PM, Brian Paul
<brian.paul@...> wrote:

> seventh guardian wrote:
>>
>> On Mon, Jun 16, 2008 at 4:17 PM, Brian Paul
>> <brian.paul@...> wrote:
>>>
>>> seventh guardian wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm running a 64 bit kernel and using the gallium branch from the
>>>> nouveau repository. It's being kept mostly synchronized with your
>>>> gallium branch, so this problem should also apply.
>>>>
>>>> Everything works (mostly) fine with 64 bits apps, but for 32 bit apps
>>>> rendering obviously reverts to software mode. So I wanted to build a
>>>> 32 bit version of the libraries to be able to use hardware rendering
>>>> (this setup works for the nividia blob), but then things started to go
>>>> wrong ;)
>>>>
>>>> First of all, the "-m32" flag is not being used in some of the demos
>>>> so gcc complains that I want to link 32 bit code into a 64 bit
>>>> executable. I had to add $(ARCH_FLAGS) to some lines in
>>>> progs/demos/Makefile for mesa to compile. I'm not sure if this is the
>>>> right solution, but a patch goes on annex for this.
>>>
>>> It doesn't look like you're using Mesa from git.  At least your patch
>>> doesn't apply there.
>>
>> I'm using origin/gallium-0.1. That's the base for all the current 3d
>> nouveau work..
>
> Sorry, I missed where you wrote that before.  I'll apply your Makefile
> patch.

Thanks! BTW, I'm Renato Caldas and not Seventh Guardian ;)

>
>>>> After this and some other small tweaks it compiled fine. I have a
>>>> "multi-lib" setup with all the necessary xorg 32 bit libs.
>>>>
>>>> Unfortunately, I'm still not getting direct rendering for 32 bit apps.
>>>> Can I be doing something wrong? Or is this not expected to work at
>>>> all?
>>>
>>> I think you'll have to provide more details.  Does setting
>>> LIBGL_DEBUG=verbose give any hints?
>>
>> For some strange reason the app was trying to use the 64 bit libGL.so.
>> I've fixed that, thanks!
>>
>> Now I get 90% syslog-ng cpu usage, and checking the logs I get a lot of
>> these:
>>
>> (...)
>> Jun 16 16:55:09 pinguinus [drm:drm_unlocked_ioctl] *ERROR* ret = 48 -12
>> (...)
>>
>> I'm not sure if this concerns mesa anymore, I'll try to check with the
>> nouveau drm guys.
>>
>>>> As a final comment, I found the build system way too complicated. I
>>>> had to tweak the config files a lot, and the used hierarchy duplicates
>>>> stuff all over the place. I would definitely prefer having a properly
>>>> setup auto-tools environment. Don't take me wrong, I know that some
>>>> people don't like auto-tools for several reasons, and in the end it is
>>>> a matter of preference.
>>>
>>> We've had autoconf for a while now.  Try the 7.1 release candidate or get
>>> the current code from git.
>>
>> Oh, I see that the master branch has autoconf. Are there any plans to
>> use autoconf for the origin/gallium-0.1 branch?

After some investigation on the master branch I've noticed that
autoconf is only being used as a frontend to the original Makefile
system. So even if the interfacing is somewhat eased up, the build
system is still a bit too complex.

> No plans for now.  Too busy w/ other things.
>
> Feel free to try bringing it over yourself.

I'm not sure if I have the time and/or skill, but I can try ;)

Cheers,
  Renato Caldas

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Dan Nicholson-2]

On Mon, Jun 16, 2008 at 2:07 PM, Brian Paul
<brian.paul@...> wrote:
> seventh guardian wrote:
>>
>> Oh, I see that the master branch has autoconf. Are there any plans to
>> use autoconf for the origin/gallium-0.1 branch?
>
> No plans for now.  Too busy w/ other things.
>
> Feel free to try bringing it over yourself.

I'd be willing to work on this, but I kind of got the impression that
SCons was the wave of the future for Mesa. Is this something that's
wanted?

--
Dan

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev