Re: [Mesa-dev] Can't get self-built Mesa to work on the Raspberry Pi 4

[Iago Toral]

Hi Lukas,

you need:

-Dgallium-drivers=v3d,vc4,kmsro

Iago

On Wed, 2021-01-06 at 12:22 +0100, li...@luckyxxl.de wrote:
> Hi all,
> 
> In order to check whether a OpenGL ES driver bug I'm hitting on the 
> Raspberry Pi 4 still appears in the latest Mesa version, I'm trying
> to 
> build Mesa myself and run my application with that. Unfortunately
> I'm 
> having no success with either 19.3.2 (the version distributed with 
> raspbian), 20.3.2 (the latest release) or the current master. Each
> time 
> the driver initialization fails with the following messages printed
> to 
> the console:
> 
> libGL error: failed to create dri screen
> libGL error: failed to load driver: vc4
> 
> This is my meson setup command line:
> 
> ~/Downloads/meson-0.56.0/meson.py setup -Ddri-drivers= 
> -Dgallium-drivers=v3d,vc4 -Dvulkan-drivers= -Dplatforms=x11 
> -Dbuildtype=debug -Dbackend=ninja -Dprefix=/home/pi/mesa-build build
> 
> (vc4 seems to be required in the gallium-drivers option, otherwise
> it 
> failed with 'libGL error: MESA-LOADER: failed to open vc4 [...]'. I 
> guess this makes sense given the dependency on vc4 as explained here 
> https://docs.mesa3d.org/drivers/v3d.html ?)
> 
> I'm having this issue using both SDL or freeglut and either starting
> the 
> app from ssh (using 'export DISPLAY=:0') or directly on the desktop.
> 
> I'm a total beginner when it comes to Mesa and the pi graphics
> driver 
> stack, so any help would be highly appreciated :) Thanks!
> 
> Lukas
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Can't get self-built Mesa to work on the Raspberry Pi 4

[lists]

Hi Iago,

Thank you very much, that did it!

Lukas


On 2021-01-07 08:26, Iago Toral wrote:

Hi Lukas,

you need:

-Dgallium-drivers=v3d,vc4,kmsro

Iago

On Wed, 2021-01-06 at 12:22 +0100, li...@luckyxxl.de wrote:

Hi all,

In order to check whether a OpenGL ES driver bug I'm hitting on the
Raspberry Pi 4 still appears in the latest Mesa version, I'm trying
to
build Mesa myself and run my application with that. Unfortunately
I'm
having no success with either 19.3.2 (the version distributed with
raspbian), 20.3.2 (the latest release) or the current master. Each
time
the driver initialization fails with the following messages printed
to
the console:

libGL error: failed to create dri screen
libGL error: failed to load driver: vc4

This is my meson setup command line:

~/Downloads/meson-0.56.0/meson.py setup -Ddri-drivers=
-Dgallium-drivers=v3d,vc4 -Dvulkan-drivers= -Dplatforms=x11
-Dbuildtype=debug -Dbackend=ninja -Dprefix=/home/pi/mesa-build build

(vc4 seems to be required in the gallium-drivers option, otherwise
it
failed with 'libGL error: MESA-LOADER: failed to open vc4 [...]'. I
guess this makes sense given the dependency on vc4 as explained here
https://docs.mesa3d.org/drivers/v3d.html ?)

I'm having this issue using both SDL or freeglut and either starting
the
app from ssh (using 'export DISPLAY=:0') or directly on the desktop.

I'm a total beginner when it comes to Mesa and the pi graphics
driver
stack, so any help would be highly appreciated :) Thanks!

Lukas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Thu, 7 Jan 2021, 17:31 Andreas Fänger,  wrote:

> Hi Dave,
>
>
>
> sounds good. Is there a particular reason not to port the softpipe anisotropic
> filter implementation (or from swrast, they are almost identical)?
> Wouldn’t that be easier to implement as it is based on the gallium
> infrastructure already?
>

I hadn't really looked at mesa I had thought the aniso impl weren't
conformant, I'll look again next week when I get back to work.

Dave.

>
>
> Andreas
>
>
>
> *Von:* mesa-dev  *Im Auftrag von *Dave
> Airlie
> *Gesendet:* Donnerstag, 7. Januar 2021 05:56
> *An:* Brian Paul 
> *Cc:* mesa-dev ;
> mesa-us...@lists.freedesktop.org
> *Betreff:* Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of
> classic OSMesa
>
>
>
>
>
> I have some plans nothing firm to add some sort of aniso to llvmpipe. I
> was considering porting code from swiftshader, maybe I can bump it up the
> priority list.
>
>
>
> Dave.
>
>
>
> On Tue, 5 Jan 2021, 06:02 Brian Paul,  wrote:
>
>
>
>  Forwarded Message 
> Subject:[Mesa-users] Issues with removal of classic OSMesa
> Date:   Thu, 31 Dec 2020 12:56:04 +0100
> From:   Andreas Fänger 
> To: mesa-us...@lists.freedesktop.org
>
> Hi,
>
> I've just seen that classic OSMesa has been removed (again) from Mesa3D
> a few weeks ago with this commit "mesa: Retire classic OSMesa".
>
> We are still actively using classical OSMesa for high quality rendering
> of still images in a headless environment with no GPU support
> (server-based rendering on windows and linux)
>
> Unfortunately, none of the alternative software renderers provide all
> the features that we require, which is antialiasing and anisotropic
> filtering. The current state is (correct me if I'm wrong)
>
> * softpipe: anisotropic filtering is supported, no antialiasing
>
> * llvmpipe: no anisotropic filtering, has MSAA
>
>
>
>
>
> * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)
>
> We had hoped that classical OSMesa is only removed when there is a full
> replacement after the discussions in 2016 when OSMesa was about to be
> removed for the first time
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html
>
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html
>
> and the commit that reverted the removal
>
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c
>
> Are there any plans to enhance the renderers so that at least one of
> them is providing both anisotropic filtering and antialiasing?
>
> As far as I know, anisotropic texture filtering is also one of the
> OpenGL 4.6 requirements.
>
> In 2016 I was told that there are only very few developers involved in
> llvmpipe and that chances are not high that someone is going to port the
> softpipe anisotropic filtering implementation as llvmpipe is much more
> complex. Is there any change in that situation?
>
>
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Andreas Fänger]

Hi Dave,

 

don’t know why the current softpipe/swrast implementation shouldn’t be 
conformant.

 

If that helps, here are the original patches which might give you a quick 
overview of what was required to get it working in softpipe and swrast back 
then (of course, the code is different now due to other changes)

 

https://gitlab.freedesktop.org/mesa/mesa/-/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162

 

https://gitlab.freedesktop.org/mesa/mesa/-/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214

 

Andreas

 

Von: Dave Airlie  
Gesendet: Donnerstag, 7. Januar 2021 09:37
An: Andreas Fänger 
Cc: mesa-dev ; mesa-us...@lists.freedesktop.org
Betreff: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

 

 

On Thu, 7 Jan 2021, 17:31 Andreas Fänger, mailto:a.faen...@e-sign.com> > wrote:

Hi Dave,

 

sounds good. Is there a particular reason not to port the softpipe anisotropic 
filter implementation (or from swrast, they are almost identical)? Wouldn’t 
that be easier to implement as it is based on the gallium infrastructure 
already?

 

I hadn't really looked at mesa I had thought the aniso impl weren't conformant, 
I'll look again next week when I get back to work.

 

Dave.

 

Andreas

 

Von: mesa-dev mailto:mesa-dev-boun...@lists.freedesktop.org> > Im Auftrag von Dave Airlie
Gesendet: Donnerstag, 7. Januar 2021 05:56
An: Brian Paul mailto:bri...@vmware.com> >
Cc: mesa-dev mailto:mesa-dev@lists.freedesktop.org> >; mesa-us...@lists.freedesktop.org 
 
Betreff: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

 



I have some plans nothing firm to add some sort of aniso to llvmpipe. I was 
considering porting code from swiftshader, maybe I can bump it up the priority 
list.

 

Dave.

 

On Tue, 5 Jan 2021, 06:02 Brian Paul, mailto:bri...@vmware.com> > wrote:



 Forwarded Message 
Subject:[Mesa-users] Issues with removal of classic OSMesa
Date:   Thu, 31 Dec 2020 12:56:04 +0100
From:   Andreas Fänger mailto:a.faen...@e-sign.com> >
To: mesa-us...@lists.freedesktop.org 
 

Hi,

I've just seen that classic OSMesa has been removed (again) from Mesa3D 
a few weeks ago with this commit "mesa: Retire classic OSMesa".

We are still actively using classical OSMesa for high quality rendering 
of still images in a headless environment with no GPU support 
(server-based rendering on windows and linux)

Unfortunately, none of the alternative software renderers provide all 
the features that we require, which is antialiasing and anisotropic 
filtering. The current state is (correct me if I'm wrong)

* softpipe: anisotropic filtering is supported, no antialiasing

* llvmpipe: no anisotropic filtering, has MSAA

 



* openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)

We had hoped that classical OSMesa is only removed when there is a full 
replacement after the discussions in 2016 when OSMesa was about to be 
removed for the first time

https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html

https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html

and the commit that reverted the removal

http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c

Are there any plans to enhance the renderers so that at least one of 
them is providing both anisotropic filtering and antialiasing?

As far as I know, anisotropic texture filtering is also one of the 
OpenGL 4.6 requirements.

In 2016 I was told that there are only very few developers involved in 
llvmpipe and that chances are not high that someone is going to port the 
softpipe anisotropic filtering implementation as llvmpipe is much more 
complex. Is there any change in that situation?

 

 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org  
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Thu, 7 Jan 2021 at 18:49, Andreas Fänger  wrote:
>
> Hi Dave,
>
>
>
> don’t know why the current softpipe/swrast implementation shouldn’t be 
> conformant.

Interesting I hadn't known we had a correct impl in mesa, the
features.txt has said
"softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting"

so I never dug any deeper. I'll consider a port of this to llvmpipe at
some point, making it efficient might be tricky.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Erik Faye-Lund]

AFAIK, anisitropic filtering is almost uselessly underspecified, so
pretty much anything should pass the CTS tests.

But visual quality does affect applications, so we should probably aim
for something reasonable.

On Thu, 2021-01-07 at 19:41 +1000, Dave Airlie wrote:
> On Thu, 7 Jan 2021 at 18:49, Andreas Fänger 
> wrote:
> > 
> > Hi Dave,
> > 
> > 
> > 
> > don’t know why the current softpipe/swrast implementation shouldn’t
> > be conformant.
> 
> Interesting I hadn't known we had a correct impl in mesa, the
> features.txt has said
> "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the
> setting"
> 
> so I never dug any deeper. I'll consider a port of this to llvmpipe
> at
> some point, making it efficient might be tricky.
> 
> Dave.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Andreas Fänger]

>> don’t know why the current softpipe/swrast implementation shouldn’t be 
>> conformant.

>Interesting I hadn't known we had a correct impl in mesa, the features.txt has 
>said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the 
>setting"
>so I never dug any deeper. I'll consider a port of this to llvmpipe at some 
>point, making it efficient might be tricky.

It seems that features.txt hasn't been updated regarding this functionality; 
softpipe has "real" anisotropy since 2011.

> I'll consider a port of this to llvmpipe at some point, making it efficient 
> might be tricky.
That would be great. As anisotropic filtering is often an option which can be 
set by a user, I guess most people turn it off to get higher framerates. But in 
our use case, high quality renderings are required, so we accept the longer 
render times to get the best quality; hopefully a llvmpipe port would be faster 
than the old swrast implementation (we are only using the fixed rendering 
pipeline/no shaders in conjunction with the OpenMP patch for speeding up 
GL_POLYGON_SMOOTH_HINT)

Andreas
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Applying fixes to stable branches

[Andres Gomez]

On Wed, 2021-01-06 at 19:19 -0500, Marek Olšák wrote:
> Hi,
> 
> How do you apply the fixes?

The way it is done during the release process is semi-automated with
the help of some scripts.

> Is it possible to pick a random commit in master and apply all fixes that are 
> newer than that commit?

It is possible but you will have to do manual conflict resolution,
specially if the "random commit" is far from the tip.

Take a look here:
https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/bin

-- 
Br,

Andres


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev