[Mesa-dev] GL4.5 or bust...
martin.peres at free.fr
Mon May 16 00:25:14 UTC 2016
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
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.
More information about the mesa-dev