[Mesa-dev] should we do GSoC 2021?

2021-02-01 Thread Trevor Woerner
Hi everyone,

There are discussions regarding whether or not we want to participate in
GSoC this year. Org applications are open now until Feb 19.

Last year at the GSoC Mentor Summit (Oct 2020) it was announced that
changes were coming to GSoC 2021:
- the amount of time a student is expected to spend on a project is halved
- stipends are halved
- overall duration is shortened to 10 weeks
- lowered eligibility requirements

As a result, project expectations are supposed to be reduced as well.
Whereas previously a student was expected to work 350 hours and had to be
enrolled in an accredited university programme, now projects are expected
to take a student 175 hours and accredited colleges and coding camps are
acceptable.

What this means right now is that our list of ideas (
https://www.x.org/wiki/SummerOfCodeIdeas/) needs to be checked to see if
it's still suitable. Are the project ideas still valid? Are they something
a student could do in 175 hours?

Some people feel that 175 hours might not be enough time to contribute a
significant coding effort against an fd.o project. At this point my gut
feeling is to hold off on the application. If I can't find anyone to help
go through the ideas list or who are willing to mentor under these new
changes then we'll need to consider our options.

Thoughts?

Thanks so much for reading, best regards,
Trevor
___
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

2021-02-01 Thread Dave Airlie
On Mon, 1 Feb 2021 at 16:50, Dave Airlie  wrote:
>
> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger  wrote:
> >
> > >> 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
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804
>
> Is my first pass at writing the code for this I've no idea if this is
> anyway correct, but I'm just letting everyone know I've started
> working on it, and mipmap_tunnel doesn't look immediately wrong.

Olay the code in the MR above seems to work in most cases now and
seems to operate like softpipe.

However I'm seeing a trace failure
https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/

that worries me that maybe the softpipe code isn't great, I'm going to
try and reproduce the traces on softpipe locally to see how they look.

I'd appreciate any testing that can be given to this code by preexisting users.

Dave.

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