On Sun, May 15, 2016 at 8:25 PM, Martin Peres <martin.pe...@free.fr> wrote: > On 16/05/16 02:55, Jason Ekstrand wrote: >> On May 15, 2016 2:01 PM, "Martin Peres" <martin.pe...@free.fr >> <mailto:martin.pe...@free.fr>> wrote: >> > >> > On 15/05/16 23:54, Ilia Mirkin wrote: >> >> >> >> On Sun, May 15, 2016 at 4:32 PM, Dave Airlie <airl...@gmail.com >> >> <mailto:airl...@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. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
