Gallium driver and compatibility issues

Gallium driver and compatibility issues

[Uwe Bugla]

Hi,

I use two nv34 cards and I would like to test / try out / use the
Gallium driver without drawbacks.

Unfortunately this has not been working since I decided to install /
compile nouveau drivers.

My system is Debian Squeeze, my kernel is 2.6.34-rc1.

The problem is:

Every time I load nouveau_dri.so into RAM existing applications are
broken / unusable (Example: gnome-games).

It does not matter if I overwrite existing versions of libglut*,
libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
difference.
The center of the problem is nouveau_dri.so and nothing else.

Could it please be possible to modify this driver file so that it does
NOT continue to break existing applications??

Would be a pleasure!

Cheers

Uwe

Re: Gallium driver and compatibility issues

[Younes Manton]

On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> Hi,
>
> I use two nv34 cards and I would like to test / try out / use the
> Gallium driver without drawbacks.
>
> Unfortunately this has not been working since I decided to install /
> compile nouveau drivers.
>
> My system is Debian Squeeze, my kernel is 2.6.34-rc1.
>
> The problem is:
>
> Every time I load nouveau_dri.so into RAM existing applications are
> broken / unusable (Example: gnome-games).
>
> It does not matter if I overwrite existing versions of libglut*,
> libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
> difference.
> The center of the problem is nouveau_dri.so and nothing else.
>
> Could it please be possible to modify this driver file so that it does
> NOT continue to break existing applications??
>
> Would be a pleasure!
>
> Cheers
>
> Uwe

Don't install nouveau_dri.so globally. When you want to try it with a
specific application set LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in
your env.

Re: Gallium driver and compatibility issues

[Uwe Bugla]

Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton:
> On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> > Hi,
> >
> > I use two nv34 cards and I would like to test / try out / use the
> > Gallium driver without drawbacks.
> >
> > Unfortunately this has not been working since I decided to install /
> > compile nouveau drivers.
> >
> > My system is Debian Squeeze, my kernel is 2.6.34-rc1.
> >
> > The problem is:
> >
> > Every time I load nouveau_dri.so into RAM existing applications are
> > broken / unusable (Example: gnome-games).
> >
> > It does not matter if I overwrite existing versions of libglut*,
> > libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
> > difference.
> > The center of the problem is nouveau_dri.so and nothing else.
> >
> > Could it please be possible to modify this driver file so that it does
> > NOT continue to break existing applications??
> >
> > Would be a pleasure!
> >
> > Cheers
> >
> > Uwe
> 
> Don't install nouveau_dri.so globally. When you want to try it with a
> specific application set LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in
> your env.

Thanks. Sounds plausible.

But:
1. Udev decides which driver is being loaded into memory at boot time.
2. I was asking for a _long term_ solution, not for a quick short term
workaround without changing the driver itself.

Cheers

Re: Gallium driver and compatibility issues

[Younes Manton]

On Thu, Mar 11, 2010 at 2:40 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton:
>> On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
>> > Hi,
>> >
>> > I use two nv34 cards and I would like to test / try out / use the
>> > Gallium driver without drawbacks.
>> >
>> > Unfortunately this has not been working since I decided to install /
>> > compile nouveau drivers.
>> >
>> > My system is Debian Squeeze, my kernel is 2.6.34-rc1.
>> >
>> > The problem is:
>> >
>> > Every time I load nouveau_dri.so into RAM existing applications are
>> > broken / unusable (Example: gnome-games).
>> >
>> > It does not matter if I overwrite existing versions of libglut*,
>> > libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
>> > difference.
>> > The center of the problem is nouveau_dri.so and nothing else.
>> >
>> > Could it please be possible to modify this driver file so that it does
>> > NOT continue to break existing applications??
>> >
>> > Would be a pleasure!
>> >
>> > Cheers
>> >
>> > Uwe
>>
>> Don't install nouveau_dri.so globally. When you want to try it with a
>> specific application set LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in
>> your env.
>
> Thanks. Sounds plausible.
>
> But:
> 1. Udev decides which driver is being loaded into memory at boot time.
> 2. I was asking for a _long term_ solution, not for a quick short term
> workaround without changing the driver itself.
>
> Cheers

I don't understand. What does udev have to do with nouveau_dri.so? If
you don't install nouveau_dri.so globally it won't be used for either
direct or indirect rendering by default. When you want to try it make
sure libGL can find it by pointing the driver path to it and it should
be used in that instance and that instance only.

Re: Gallium driver and compatibility issues

[Pekka Paalanen]

On Thu, 11 Mar 2010 20:40:34 +0100
Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:

> Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton:
> > On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org>
> > wrote:
> > > Hi,
> > >
> > > I use two nv34 cards and I would like to test / try out / use
> > > the Gallium driver without drawbacks.

A multicard setup? According to
http://nouveau.freedesktop.org/wiki/FeatureMatrix
that is not supported yet.

What do you mean "without drawbacks"? Have only the apps
you select to use the experimental driver and all other
apps to use the stable software renderer? Do not install
nouveau_dri.so system-wide, then.

Note, that the Nvidia proprietary driver simply cannot live
together with Nouveau like this.

> > > Unfortunately this has not been working since I decided to
> > > install / compile nouveau drivers.

Problems are expected on the OpenGL front, if you install any
of the experimental, unreleased 3D drivers.

> > > My system is Debian Squeeze, my kernel is 2.6.34-rc1.
> > >
> > > The problem is:
> > >
> > > Every time I load nouveau_dri.so into RAM existing
> > > applications are broken / unusable (Example: gnome-games).

Without logs we cannot help at all.

> > > It does not matter if I overwrite existing versions of
> > > libglut*, libGLw*, libGLU*, libGL*, libEGL* or not - that
> > > does not make any difference.

Did you forget libglx? The X log would tell.

> > > The center of the problem is nouveau_dri.so and nothing else.
> > >
> > > Could it please be possible to modify this driver file so
> > > that it does NOT continue to break existing applications??

Yes. That is called "development". It is what people are
doing all the time. You whining about it does not make it
happen faster. Quite the contrary.

> > Don't install nouveau_dri.so globally. When you want to try it
> > with a specific application set
> > LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in your env.
> 
> Thanks. Sounds plausible.
> 
> But:
> 1. Udev decides which driver is being loaded into memory at boot
> time. 2. I was asking for a _long term_ solution, not for a quick
> short term workaround without changing the driver itself.

udev has nothing to do with this. Udev only loads the kernel
modules. The 3D driver is not a kernel module, though it depends
on Nouveau DRM.

The long term solution is *long term*. Nouveau still does not
officially support 3D, although some reports of some 3D apps
working exist.

The current advice is to *never* install nouveau_dri.so
system-wide.

Also, you have failed to provide any logs nor descriptions
about what is broken and how. Therefore we cannot help.
My best guess is that you have parts of the prorietary Nvidia
driver still in your system (e.g. libglx).

If you want to try things, do follow
http://nouveau.freedesktop.org/wiki/GalliumHowto
and do not install the Gallium3D driver system-wide.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

Re: Gallium driver and compatibility issues

[Uwe Bugla]

Am Freitag, den 12.03.2010, 12:52 +0200 schrieb Pekka Paalanen:
> On Thu, 11 Mar 2010 20:40:34 +0100
> Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> 
> > Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton:
> > > On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org>
> > > wrote:
> > > > Hi,
> > > >
> > > > I use two nv34 cards and I would like to test / try out / use
> > > > the Gallium driver without drawbacks.
> 
> A multicard setup? According to
> http://nouveau.freedesktop.org/wiki/FeatureMatrix
> that is not supported yet.
> 
> What do you mean "without drawbacks"? Have only the apps
> you select to use the experimental driver and all other
> apps to use the stable software renderer? Do not install
> nouveau_dri.so system-wide, then.
> 
> Note, that the Nvidia proprietary driver simply cannot live
> together with Nouveau like this.
> 
> > > > Unfortunately this has not been working since I decided to
> > > > install / compile nouveau drivers.
> 
> Problems are expected on the OpenGL front, if you install any
> of the experimental, unreleased 3D drivers.
> 
> > > > My system is Debian Squeeze, my kernel is 2.6.34-rc1.
> > > >
> > > > The problem is:
> > > >
> > > > Every time I load nouveau_dri.so into RAM existing
> > > > applications are broken / unusable (Example: gnome-games).
> 
> Without logs we cannot help at all.
> 
> > > > It does not matter if I overwrite existing versions of
> > > > libglut*, libGLw*, libGLU*, libGL*, libEGL* or not - that
> > > > does not make any difference.
> 
> Did you forget libglx? The X log would tell.
> 
> > > > The center of the problem is nouveau_dri.so and nothing else.
> > > >
> > > > Could it please be possible to modify this driver file so
> > > > that it does NOT continue to break existing applications??
> 
> Yes. That is called "development". It is what people are
> doing all the time. You whining about it does not make it
> happen faster. Quite the contrary.
> 
> > > Don't install nouveau_dri.so globally. When you want to try it
> > > with a specific application set
> > > LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in your env.
> > 
> > Thanks. Sounds plausible.
> > 
> > But:
> > 1. Udev decides which driver is being loaded into memory at boot
> > time. 2. I was asking for a _long term_ solution, not for a quick
> > short term workaround without changing the driver itself.
> 
> udev has nothing to do with this. Udev only loads the kernel
> modules. The 3D driver is not a kernel module, though it depends
> on Nouveau DRM.
> 
> The long term solution is *long term*. Nouveau still does not
> officially support 3D, although some reports of some 3D apps
> working exist.
> 
> The current advice is to *never* install nouveau_dri.so
> system-wide.
> 
> Also, you have failed to provide any logs nor descriptions
> about what is broken and how. Therefore we cannot help.
> My best guess is that you have parts of the prorietary Nvidia
> driver still in your system (e.g. libglx).
> 
> If you want to try things, do follow
> http://nouveau.freedesktop.org/wiki/GalliumHowto
> and do not install the Gallium3D driver system-wide.
> 

Pekka,

although your answering style and niveau are a catastrophe I still try
to extract the positive parts of the traffic:

Lapse No. 1:
If I mention owing 2 nv34 cards this does not automatically mean that I
use a multicard setup.

"What do you mean "without drawbacks"?"
Lapse No. 2:
If you first read a message as a whole to try and understand the issue
as a whole you very simply can avoid questions like that one.
So FIRST try to understand the message as a whole, THEN start answering.

"Note, that the Nvidia proprietary driver....."
Lapse No. 3:
Misleading usage of expressions.
Everybody talking about the "Nvidia proprietary driver" in the graphic
card context of Nvidia cards normallly means the blob driver shipped by
Nvidia (closed source driver!) which does not have any problems with
stuff like Compiz or other 3D applications. I do not like blob drivers
for a whole bunch of reasons.
As you are definitely using the wrong expression it remains your
personal secret what you are trying to express or say.

"Problems are expected on the OpenGL front....."
Lapse No. 4:
I did not mention nearly all driver parts of the Gallium drivers
carrying the "GL" in their names just by chance. I reflect while I am
typing messages. I explicitly mentioned that the versions of the driver
parts carrying the "GL" in their names are NOT responsible for the
breakage that I reported.
Thus it still remains your personal secret what you mean by "OpenGL
front".


"Yes. That is called "development". It is what people are
doing all the time. You whining about it does not make it
happen faster. Quite the contrary."
Lapse No. 5:
If you want to be addressed like something utmost primitive
that noone appreciates or needs or wants then go on expressing yourself
like that.
If you want to be addressed like a human being, either immediately change
your style or simply shut up!

Lapse No. 6:
Instead of repeating the core message of my request for 4 times in this mail
(how insane!) I propose to change this page

http://nouveau.freedesktop.org/wiki/GalliumHowto

in the following way:

1. Wipe off the following stupid idiotic crap:

"Warning : Nouveau's developers don't want people to build gallium drivers now, and do not support it at all.
They also don't want bug reports on gallium ATM.
This is code in rapid development. Bug reports for this are useless, as
it's known to be broken."

2. Substitute this goddamn crap with the following text:

Warning: If you decide to install and test the Gallium driver, do not
install it system-wide. Do use the software rastering driver as standard
driver (swrast_dri.so). For using / testing the Gallium driver please do
not forget to change your environment variable like that:
LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so.


The broken application that I mentioned is the solitaire card game of
Gnome which appears in certain variants.

You can see the screen and the shape of the window, but the contents of
the window is nothing but illegible mud. You cannot see the cards, you
cannot see the values of the cards (A for Ass, Q for queen etc.).
Just a window containing nothing but junk opens.
And once again: The error is not hidden in some library file containing
the "GL" in its name, and the versioning of those GL files is also NOT
the problem.
It's the sources of the nouveau_dri.so file that do contain the bug.

Cheers

Uwe

Re: Gallium driver and compatibility issues

[Pekka Paalanen]

On Fri, 12 Mar 2010 14:51:34 +0100
Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:

> "Note, that the Nvidia proprietary driver....."
> Lapse No. 3:
> Misleading usage of expressions.
> Everybody talking about the "Nvidia proprietary driver" in the
> graphic card context of Nvidia cards normallly means the blob
> driver shipped by Nvidia (closed source driver!) which does not
> have any problems with stuff like Compiz or other 3D
> applications. I do not like blob drivers for a whole bunch of
> reasons. As you are definitely using the wrong expression it
> remains your personal secret what you are trying to express or
> say.

One of the most common reasons for problems with Nouveau are
the remnants of the proprietary driver. Since you did not
provide kernel log, X log, nor glxinfo output, I of course
assumed the most probable case. A stale libglx from the blob
kills OpenGL, for instance.

Furthermore, you cannot have the Nvidia proprietary 3D
driver running by default, and then use the Nouveau 3D driver
on selected apps. If you use *any* part of Nouveau, you cannot
have *any* part of the proprietary driver, and vice versa.
They cannot live together at all.

I'm sorry I guessed your problem wrong. There was no real
information to begin the diagnosis with.

> "Problems are expected on the OpenGL front....."
> Lapse No. 4:
> I did not mention nearly all driver parts of the Gallium drivers
> carrying the "GL" in their names just by chance. I reflect while
> I am typing messages. I explicitly mentioned that the versions of
> the driver parts carrying the "GL" in their names are NOT
> responsible for the breakage that I reported.
> Thus it still remains your personal secret what you mean by
> "OpenGL front".

Actually, they are. Mesa libGL will try to load nouveau_dri.so
to provide hardware accelerated 3D rendering. At this time
OpenGL (via Mesa) is the only real user of nouveau_dri.so.
nouveau_dri.so may be loaded by the X server (AIGLX) or
the application (direct rendering) when they load libGL.

In short, having nouveau_dri.so will break OpenGL and perhaps
kill the X server in the AIGLX case.

> Lapse No. 6:
> Instead of repeating the core message of my request for 4 times
> in this mail (how insane!) I propose to change this page
> http://nouveau.freedesktop.org/wiki/GalliumHowto
> 
> in the following way:
> 
> 1. Wipe off the following stupid idiotic crap:
> 
> "Warning : Nouveau's developers don't want people to build
> gallium drivers now, and do not support it at all. They also
> don't want bug reports on gallium ATM. This is code in rapid
> development. Bug reports for this are useless, as it's known to
> be broken."

That is rude on purpose. It is supposed to be crystal clear
to everyone, that this is not yet for end users, but apparently
it is not that clear. The time for end users will come, later.
At that time the page will be rewritten to be polite. Right now
it is just a cheatsheet for new developers.

> And once again: The error is not hidden in some library
> file containing the "GL" in its name, and the versioning of those
> GL files is also NOT the problem.
> It's the sources of the nouveau_dri.so file that do contain the
> bug.

True. nouveau_dri.so misses complete features and contains bugs.

I read your two first posts as nothing more than an elaborate
"Fix everything, please". That really is what people are actually
doing on their free time. Trying to kick their butt can only make
them ignorant or angry.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

Re: Gallium driver and compatibility issues

[Chicken Shack]

Am Freitag, den 12.03.2010, 22:25 +0200 schrieb Pekka Paalanen:
> On Fri, 12 Mar 2010 14:51:34 +0100
> Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> 
> > "Note, that the Nvidia proprietary driver....."
> > Lapse No. 3:
> > Misleading usage of expressions.
> > Everybody talking about the "Nvidia proprietary driver" in the
> > graphic card context of Nvidia cards normallly means the blob
> > driver shipped by Nvidia (closed source driver!) which does not
> > have any problems with stuff like Compiz or other 3D
> > applications. I do not like blob drivers for a whole bunch of
> > reasons. As you are definitely using the wrong expression it
> > remains your personal secret what you are trying to express or
> > say.
> 
> One of the most common reasons for problems with Nouveau are
> the remnants of the proprietary driver. Since you did not
> provide kernel log, X log, nor glxinfo output, I of course
> assumed the most probable case. A stale libglx from the blob
> kills OpenGL, for instance.
> 
> Furthermore, you cannot have the Nvidia proprietary 3D
> driver running by default, and then use the Nouveau 3D driver
> on selected apps. If you use *any* part of Nouveau, you cannot
> have *any* part of the proprietary driver, and vice versa.
> They cannot live together at all.
> 
> I'm sorry I guessed your problem wrong. There was no real
> information to begin the diagnosis with.
> 
> > "Problems are expected on the OpenGL front....."
> > Lapse No. 4:
> > I did not mention nearly all driver parts of the Gallium drivers
> > carrying the "GL" in their names just by chance. I reflect while
> > I am typing messages. I explicitly mentioned that the versions of
> > the driver parts carrying the "GL" in their names are NOT
> > responsible for the breakage that I reported.
> > Thus it still remains your personal secret what you mean by
> > "OpenGL front".
> 
> Actually, they are. Mesa libGL will try to load nouveau_dri.so
> to provide hardware accelerated 3D rendering. At this time
> OpenGL (via Mesa) is the only real user of nouveau_dri.so.
> nouveau_dri.so may be loaded by the X server (AIGLX) or
> the application (direct rendering) when they load libGL.
> 
> In short, having nouveau_dri.so will break OpenGL and perhaps
> kill the X server in the AIGLX case.
> 
> > Lapse No. 6:
> > Instead of repeating the core message of my request for 4 times
> > in this mail (how insane!) I propose to change this page
> > http://nouveau.freedesktop.org/wiki/GalliumHowto
> > 
> > in the following way:
> > 
> > 1. Wipe off the following stupid idiotic crap:
> > 
> > "Warning : Nouveau's developers don't want people to build
> > gallium drivers now, and do not support it at all. They also
> > don't want bug reports on gallium ATM. This is code in rapid
> > development. Bug reports for this are useless, as it's known to
> > be broken."
> 
> That is rude on purpose. It is supposed to be crystal clear
> to everyone, that this is not yet for end users, but apparently
> it is not that clear. The time for end users will come, later.
> At that time the page will be rewritten to be polite. Right now
> it is just a cheatsheet for new developers.
> 
> > And once again: The error is not hidden in some library
> > file containing the "GL" in its name, and the versioning of those
> > GL files is also NOT the problem.
> > It's the sources of the nouveau_dri.so file that do contain the
> > bug.
> 
> True. nouveau_dri.so misses complete features and contains bugs.
> 
> I read your two first posts as nothing more than an elaborate
> "Fix everything, please". That really is what people are actually
> doing on their free time. Trying to kick their butt can only make
> them ignorant or angry.
> 

Yup! Good vibes!

a. I do not use parts of the Nvidia blob driver or the blob as whole.
b. Up to now I always loaded nouveau_dri.so via AIGLX plus minimal
xorg.conf plus nouveau kernel staging driver.
c. I can send you some xorg.0.log if you may wish.
What other log files could be useful please?
d. In fact the xorg server did not crash even once.
The only thing that is broken is the specific application (solitaire).
There do exist apps that are not broken.

That's it for now. If you need further info please tell me.
Otherwise I will stay away from Gallium from now on.

Cheers

Uwe

Re: Gallium driver and compatibility issues

[Uwe Bugla]

Am Freitag, den 12.03.2010, 22:25 +0200 schrieb Pekka Paalanen:
> On Fri, 12 Mar 2010 14:51:34 +0100
> Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:
> 
> > "Note, that the Nvidia proprietary driver....."
> > Lapse No. 3:
> > Misleading usage of expressions.
> > Everybody talking about the "Nvidia proprietary driver" in the
> > graphic card context of Nvidia cards normallly means the blob
> > driver shipped by Nvidia (closed source driver!) which does not
> > have any problems with stuff like Compiz or other 3D
> > applications. I do not like blob drivers for a whole bunch of
> > reasons. As you are definitely using the wrong expression it
> > remains your personal secret what you are trying to express or
> > say.
> 
> One of the most common reasons for problems with Nouveau are
> the remnants of the proprietary driver. Since you did not
> provide kernel log, X log, nor glxinfo output, I of course
> assumed the most probable case. A stale libglx from the blob
> kills OpenGL, for instance.
> 
> Furthermore, you cannot have the Nvidia proprietary 3D
> driver running by default, and then use the Nouveau 3D driver
> on selected apps. If you use *any* part of Nouveau, you cannot
> have *any* part of the proprietary driver, and vice versa.
> They cannot live together at all.
> 
> I'm sorry I guessed your problem wrong. There was no real
> information to begin the diagnosis with.
> 
> > "Problems are expected on the OpenGL front....."
> > Lapse No. 4:
> > I did not mention nearly all driver parts of the Gallium drivers
> > carrying the "GL" in their names just by chance. I reflect while
> > I am typing messages. I explicitly mentioned that the versions of
> > the driver parts carrying the "GL" in their names are NOT
> > responsible for the breakage that I reported.
> > Thus it still remains your personal secret what you mean by
> > "OpenGL front".
> 
> Actually, they are. Mesa libGL will try to load nouveau_dri.so
> to provide hardware accelerated 3D rendering. At this time
> OpenGL (via Mesa) is the only real user of nouveau_dri.so.
> nouveau_dri.so may be loaded by the X server (AIGLX) or
> the application (direct rendering) when they load libGL.
> 
> In short, having nouveau_dri.so will break OpenGL and perhaps
> kill the X server in the AIGLX case.
> 
> > Lapse No. 6:
> > Instead of repeating the core message of my request for 4 times
> > in this mail (how insane!) I propose to change this page
> > http://nouveau.freedesktop.org/wiki/GalliumHowto
> > 
> > in the following way:
> > 
> > 1. Wipe off the following stupid idiotic crap:
> > 
> > "Warning : Nouveau's developers don't want people to build
> > gallium drivers now, and do not support it at all. They also
> > don't want bug reports on gallium ATM. This is code in rapid
> > development. Bug reports for this are useless, as it's known to
> > be broken."
> 
> That is rude on purpose. It is supposed to be crystal clear
> to everyone, that this is not yet for end users, but apparently
> it is not that clear. The time for end users will come, later.
> At that time the page will be rewritten to be polite. Right now
> it is just a cheatsheet for new developers.
> 
> > And once again: The error is not hidden in some library
> > file containing the "GL" in its name, and the versioning of those
> > GL files is also NOT the problem.
> > It's the sources of the nouveau_dri.so file that do contain the
> > bug.
> 
> True. nouveau_dri.so misses complete features and contains bugs.
> 
> I read your two first posts as nothing more than an elaborate
> "Fix everything, please". That really is what people are actually
> doing on their free time. Trying to kick their butt can only make
> them ignorant or angry.
> 


Yup! Good vibes!

a. I do not use parts of the Nvidia blob driver or the blob as whole.
b. Up to now I always loaded nouveau_dri.so via AIGLX plus minimal
xorg.conf plus nouveau kernel staging driver.
c. I can send you some xorg.0.log if you may wish.
What other log files could be useful please?
d. In fact the xorg server did not crash even once.
The only thing that is broken is the specific application (solitaire).
There do exist apps that are not broken.

That's it for now. If you need further info please tell me.
Otherwise I will stay away from Gallium from now on.

Cheers

Uwe

Re: Gallium driver and compatibility issues

[Luca Barbieri]

It is not surprising that some (or most) 3D applications don't
actually work correctly with nouveau on nv3x right now.

The driver will probably improve in the future.

Re: Gallium driver and compatibility issues

[Uwe Bugla]

Am Freitag, den 12.03.2010, 23:06 +0100 schrieb Luca Barbieri:
> It is not surprising that some (or most) 3D applications don't
> actually work correctly with nouveau on nv3x right now.
> 
> The driver will probably improve in the future.

Hi Luca,

Thanks for your excellent merging work of the nv30 and nv40 branch!
The trouble with the solitaire game is gone.
Against all golden rules I have installed gallium 0.4 globally on my
Gnome 2.28 desktop now, and it seems to do its job quite good without
crashing or doing other harm to the installed software on my desktop.
That's a good sign, isn't it?

I know that the nv40 and nv30 series are completely different cards
compared to the nv50 series and I know that there needs a lot of work to
be done, but neverless I wanted to thank all devs for their good
hitherto work while I am looking forward to the Gallium driver in
general and to its Compiz Fusion support in detail.

Best regards

Uwe

Re: Gallium driver and compatibility issues

[Christoph Bumiller]

On 11.03.2010 18:42, Uwe Bugla wrote:
> Hi,
>
> I use two nv34 cards and I would like to test / try out / use the
> Gallium driver without drawbacks.
>
>   
Note that you said "use", and not "own", which is a little
biased towards "they're plugged into the same MB".

> Unfortunately this has not been working since I decided to install /
> compile nouveau drivers.
>
>   
This is kind of a pre-requisite to be able to try the gallium
drivers ... well, you can run a simulation in your head, but,
that would be rather tedious.

> My system is Debian Squeeze, my kernel is 2.6.34-rc1.
>
> The problem is:
>
> Every time I load nouveau_dri.so into RAM existing applications are
> broken / unusable (Example: gnome-games).
>
>   
Loading stuff into RAM by itself shouldn't cause any problems
if that RAM isn't used by something else, but, I'll just interpret
this as best I can:
AIGLX is loading it from .../lib/dri/, i.e. you installed it globally -
not the safest way to try, because now any app using OpenGL
may use the hw through indirect rendering.
(indirect meaning app -> libGL -> Xorg -> nouveau_dri, instead
of app -> libGL -> nouveau_dri)

> It does not matter if I overwrite existing versions of libglut*,
> libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
> difference.
> The center of the problem is nouveau_dri.so and nothing else.
>
>   
Sure, libGL etc. don't directly control the hardware, they
hook into the dri driver (nouveau_dri.so) to do that.

> Could it please be possible to modify this driver file so that it does
> NOT continue to break existing applications??
>
>   
It will break existing applications if existing applications make
use of it and it is itself broken.
So, either don't let them use it, or fix it. We're working on that.

Consider yourself lucky that you got an answer at all. Normally,
at this time, we don't care about the process of people trying the
gallium driver without knowing exactly (well, to a certain degree
at least) what they're doing.

Half-expecting to have my message dissected now,

Christoph
> Would be a pleasure!
>
> Cheers
>
> Uwe
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>   

Re: Gallium driver and compatibility issues

[Uwe Bugla]

Am Freitag, den 12.03.2010, 16:19 +0100 schrieb Christoph Bumiller:
> On 11.03.2010 18:42, Uwe Bugla wrote:
> > Hi,
> >
> > I use two nv34 cards and I would like to test / try out / use the
> > Gallium driver without drawbacks.
> >
> >   
> Note that you said "use", and not "own", which is a little
> biased towards "they're plugged into the same MB".
> 
> > Unfortunately this has not been working since I decided to install /
> > compile nouveau drivers.
> >
> >   
> This is kind of a pre-requisite to be able to try the gallium
> drivers ... well, you can run a simulation in your head, but,
> that would be rather tedious.
> 
> > My system is Debian Squeeze, my kernel is 2.6.34-rc1.
> >
> > The problem is:
> >
> > Every time I load nouveau_dri.so into RAM existing applications are
> > broken / unusable (Example: gnome-games).
> >
> >   
> Loading stuff into RAM by itself shouldn't cause any problems
> if that RAM isn't used by something else, but, I'll just interpret
> this as best I can:
> AIGLX is loading it from .../lib/dri/, i.e. you installed it globally -
> not the safest way to try, because now any app using OpenGL
> may use the hw through indirect rendering.
> (indirect meaning app -> libGL -> Xorg -> nouveau_dri, instead
> of app -> libGL -> nouveau_dri)
> 
> > It does not matter if I overwrite existing versions of libglut*,
> > libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any
> > difference.
> > The center of the problem is nouveau_dri.so and nothing else.
> >
> >   
> Sure, libGL etc. don't directly control the hardware, they
> hook into the dri driver (nouveau_dri.so) to do that.
> 
> > Could it please be possible to modify this driver file so that it does
> > NOT continue to break existing applications??
> >
> >   
> It will break existing applications if existing applications make
> use of it and it is itself broken.
> So, either don't let them use it, or fix it. We're working on that.
> 
> Consider yourself lucky that you got an answer at all. Normally,
> at this time, we don't care about the process of people trying the
> gallium driver without knowing exactly (well, to a certain degree
> at least) what they're doing.
> 
> Half-expecting to have my message dissected now,
> 
> Christoph
> > Would be a pleasure!
> >
> > Cheers
> >
> > Uwe

Christoph,

Thanks for the explanation of "indirect rendering".

"Consider yourself lucky that you got an answer at all."
Please avoid sentences like that one, as this bum style really sucks!

In addition to my proposal of changing the intro of the Gallium HOWTO
I would propose to establish an (incomplete) list of apps known to work
with the Gallium driver. So one can easily find out the gaps and at
least try to fill them by testing.

Reason / Conclusion:
Developers of whatever kind of software aren't omnicient gods.
They need feedback, cause without that feedback they are lost.
Whenever Gallium and nouveau will be stable or "finished" they will not
be the result of "Stay-away-from-it" slogans by some profile-neurotic
stupid, arrogant and asocial would-like-to's. They will be instead
products of a social community work of many many different people.

Cheers

Uwe

Re: Gallium driver and compatibility issues

[Pekka Paalanen]

On Fri, 12 Mar 2010 17:09:38 +0100
Uwe Bugla <uwe.bugla-Mmb7MZpHnFY@public.gmane.org> wrote:

> Reason / Conclusion:
> Developers of whatever kind of software aren't omnicient gods.
> They need feedback, cause without that feedback they are lost.

The point is, the developers do NOT need feedback TODAY.
They have enough broken applications to debug on their own.
When this situation changes, it will certainly be announced
to the world. But not yet.

That is the reason why end users should not be trying the
3D part of the driver set. This is also why developers are
so hostile to 3D issues.

-- 
Pekka Paalanen
http://www.iki.fi/pq/