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

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? Andreas Von: mesa-dev Im Auftrag von

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

You need to enable kmsro. On Wed, Jan 6, 2021 at 3:31 AM 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 >

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

LIBGL_DEBUG=verbose could be a good start? Regards //Ernst Den ons 6 jan. 2021 kl 12:31 skrev : > 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

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

Re: [Mesa-dev] llvmpipe MSAA (Was: Fwd: [Mesa-users] Issues with removal of classic OSMesa)

It looks like llvmpipe has real MSAA with NIR. Marek On Wed, Jan 6, 2021 at 5:06 AM Jose Fonseca wrote: > That's an interesting idea! > > llvmpipe rasterization is complicated and very optimized, so changing > llvmpipe's rasterizer to spit out MSAA coverages is very hard. I think > that a

[Mesa-dev] Applying fixes to stable branches

Hi, How do you apply the fixes? Is it possible to pick a random commit in master and apply all fixes that are newer than that commit? Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org

[Mesa-dev] Mesa 21.0 release schedule

It's already that time again. I've posted the proposed schedule for Mesa 21.0: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8356, in keeping with our goal of branching on the second wednesday of January. I'll plan to create a branch in 1 week from today (January 13). Cheers, Dylan

Re: [Mesa-dev] Mesa main repor branch clean-up

Thank you for doing this. The dead branches in the mesa repo always annoyed me. There are still many tags that look like they were inadvertently pushed to the origin by developers. Does it make sense to delete them as well? -Mark Jason Ekstrand writes: > All, > > At suggestion from several

[Mesa-dev] Mesa main repor branch clean-up

All, At suggestion from several people on IRC, I've done a bit of house cleaning of the main Mesa repo. I created a new mesa/mesa-archive repo and moved all of the stale feature branches to that repo and removed them from mesa/mesa. Many of those branches haven't seen a commit in 10-20 years so

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

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

[Mesa-dev] llvmpipe MSAA (Was: Fwd: [Mesa-users] Issues with removal of classic OSMesa)

That's an interesting idea! llvmpipe rasterization is complicated and very optimized, so changing llvmpipe's rasterizer to spit out MSAA coverages is very hard. I think that a good way to approach this is to: 1) continue to do single sample rasterization, but adjust the line coeffs of the