[Mesa-dev] GL4.5 or bust...

Mon May 16 08:57:12 UTC 2016

I'd rather push GL4.5 support after the release and have all 3 months
for bug fixing.

If we delay the release now, the release after that should be sooner,
so that it's aligned with fall distribution releases.

Marek

On Mon, May 16, 2016 at 10:43 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi all,
>
> On 16 May 2016 at 01:32, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Sun, May 15, 2016 at 8:25 PM, Martin Peres <martin.peres at free.fr> wrote:
>>> On 16/05/16 02:55, Jason Ekstrand wrote:
>>>> On May 15, 2016 2:01 PM, "Martin Peres" <martin.peres at free.fr
>>>> <mailto:martin.peres at free.fr>> wrote:
>>>> >
>>>> > On 15/05/16 23:54, Ilia Mirkin wrote:
>>>> >>
>>>> >> On Sun, May 15, 2016 at 4:32 PM, Dave Airlie <airlied at gmail.com
>>>> >> <mailto:airlied at gmail.com>> wrote:
>>>> >>>
>>>> >>> So I said this on irc over the weekend and it seemed like we had some
>>>> >>> consensus on holding off 12.0 until we could announce 4.5 on some
>>>> >>> hardware. This assumes the FP64 stuff is going in at least.
>>>> >>>
>>>> >>> So I decided to roll out the proposal here, which is that we finish
>>>> >>> GL4.5 features off for at least Skylake I think.
>>>> >>>
>>>> >>> So what is needed/missing: please add as you see fit.
>>>> >>>
>>>> >>> a) robustness - radeonsi has some bits of this. We need to get
>>>> >>> KHR_robustness bits, that I think Kayden has patches started for, and
>>>> >>> i965 needs to ensure it uses robust buffer stuff. I don't think this
>>>> >>> one in unobtainable.
>>>> >>>
>>>> >>> b) cull_distance - I merged something, it broke, I'll fix it today,
>>>> >>> job done.
>>>> >>>
>>>> >>> c) enhanced_layouts - So tarceri has posted patches, we know that to
>>>> >>> do it properly we probably need to rip up attribute packing and
>>>> >>> rewrite it, however if Kayden thinks what tarceri has done is
>>>> >>> functional enough for now, we could merge the final pieces and work on
>>>> >>> perfection later.
>>>> >>>
>>>> >>> d) SIMD32 for i965 compute shaders - this is probably the most unknown
>>>> >>> to me, curro says he's got some patches, that need to rebase onto FP64
>>>> >>> when it lands, assuming he can do that, and reviewers can get on top
>>>> >>> of things, and we possibly only enable SIMD32 in the corner cases
>>>> >>> initially, it might be possible to get this landed.
>>>> >>>
>>>> >>> Have I missed anything? Should we go for it?
>>>> >>
>>>> >> The bugs that get triggered when you expose GL 4.3+ to UE4 games. Some
>>>> >> are ours, some are theirs. Someone needs to sign up for this work.
>>>> >>
>>>> >> Also, I'd like to mention that ES 3.2 is pretty close as well. But
>>>> >> probably not close enough to squeeze in here. Ian has started working
>>>> >> on the OES_shader_io_blocks bits of it (which IMO shouldn't be too bad
>>>> >> for someone who knows what all GLSL allows and what it doesn't), which
>>>> >> was the last remaining big chunk. I have preliminary patches for core
>>>> >> support of advanced blending, the rest should all be easy.
>>>> >>
>>>> >>> For radeonsi, I think the only other missing bit is qbo and
>>>> >>> clear_texture, which may or may not make it in time.
>>>> >>
>>>> >> I'm in favor of this plan. Nouveau should be ready for Fermi and
>>>> >> Kepler once Samuel's images patches for Fermi land (mostly reviewed,
>>>> >> had a couple of nits). Maxwell will be missing tess and images, and
>>>> >> it's unlikely that either of those will get done in a reasonable
>>>> >> period of time. I think we can just flip robustness on... probably not
>>>> >> meeting all the provisions of that spec, but ... meh.
>>>> >>
>>>> >> That said, we should put a cap on this timewise - if e.g. it becomes
>>>> >> clear that SIMD32 will take a long time (I think the biggest potential
>>>> >> issue of the batch), we should just cut a release. Maybe a 1 month
>>>> >> cap?
>>>> >
>>>> >
>>>> > Yeah, a cap of 1 month delay compared to the initial plan or 1
>>>> > week after the driver reaching 4.5 in master, whatever happens
>>>> > first.
>>>>
>>>> I agree with a time limit if we're going to do this. Another suggestion
>>>> that had been made is to go ahead with the release and then plan to release
>>>> mesa 13 as soon as we get 4.5. I'm personally OK with either.
>>>> --Jason
>>>>
>>> Let's see if it would prevent some superstitious people from updating :p
>>>
>>> In any case, I agree with Jason. Mesa is released often-enough and things
>>> will get a little buggy as games suddenly start exercising mesa is funny
>>> ways. So, let's not rush it out if it cannot reach the quality needed and
>>> just release another major version when it is ready.
>>
>> Of course the way to discover that games/applications suddenly start
>> exercising mesa in funny ways is to do a release... a bit of a catch
>> 22, wouldn't you say? I don't think developers and the users of
>> mesa-git are really going to be enough to get all the kinks out. And
>> the RC period should be sufficient time to fix any major issues that
>> pop up.
>>
>
> Let's see if I can summarise:
>  - People want to have a release with GL 4.5 capable driver(s)
>  - Mesa releasing is on a time based model, not a feature one.
>  - Saying "we must get these X things, no release until then, period"
> (GL 4.5 or bust) is just plain silly
>  - If we amend ^^ to honour some timeline, than we may not reach the
> stated goad even with the imposed delay.
>  - Parties interested in the original timeline, may miss, are too shy,
> etc. to say anything against this last minute change.
>
> How about we do the following:
>  - Keep the plan as originally
>  - As people are happy that we have 1-2 drivers covering GL version X,
> branch off/feature freeze and release a few weeks later.
>  - Last but not least - let's try and bring up such discussions
> earlier, please ?
> If people have missed the earlier emails let me know we can improve on
> that. Don't just ignore them and shout at the last minute, please ?
>
> Thank you
> Emil
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev