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

[Emil Velikov]

On 16 May 2016 at 18:54, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Mon, May 16, 2016 at 1: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.
>
> This isn't set in stone. It's something we all decided on a while
> back. It's worked well and continues to work well, but we can all
> decide to make an exception or change it, if we get community
> consensus.
>
Indeed that is correct.

>>  - Saying "we must get these X things, no release until then, period"
>> (GL 4.5 or bust) is just plain silly
>
> This is not "summarising", this is your opinion. I like time based
> release schedules as much as the next guy/girl, but there are case or
> circumstances where exceptions make sense.
>
No objections. The question being is why don't we hear about these earlier ?

In all honestly I'm eagerly expecting any input when I sent out
release schedule emails and rarely hear any input.

>>  - 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 ?
>
> I think we have to priorities here: making the 12.0 release and
> getting 4.5 out as soon as possible. They don't actually conflict, we
> just have to agree on the mechanism we use: 1) push out 12.0 a bit
> (we'll need a deadline), 2) keep the 12.0 schedule but re-merge master
> and push out the release if we get to 4.5 before the release or 3) cut
> a release (12.1 or 13.0, whatever) as soon as we get to 4.5.
>
I believe I suggested the third option already ;-)

Why I opted for it as opposed to the other two ? Because one month is
roughly a third of the schedule, which by any metrics is a very
significant delay.

The way I see it, at least some people think that 'my' (it was Jason's
actually) idea is not that bad. I'm obviously biased, but who isn't ?

Thanks
Emil