On 11/08/2013 11:00 AM, Dave Airlie wrote: > On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick <idr@xxxxxxxxxxxxxxx> wrote: >> On 11/07/2013 10:32 PM, Daniel Vetter wrote: >>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: >>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >>>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick <idr@xxxxxxxxxxxxxxx> wrote: >>>>>> On 10/27/2013 05:30 AM, Daniel Vetter wrote: >>>>>>> On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote: >>>>>>>> Since the Mesa merge window is closing soon, I'm finally getting back on >>>>>>>> this. I've pushed a rebase of my old Mesa branch to my fd.o repo >>>>>>>> >>>>>>>> http://cgit.freedesktop.org/~idr/mesa/log/?h=robustness3 >>>>>>>> >>>>>>>> I have a couple questions... >>>>>>>> >>>>>>>> 1. Has any of this landed an a kernel tree anywhere? >>>>>>> >>>>>>> Afaik everything but the actual ioctl and i-g-t testcase has landed. >>>>>> >>>>>> And that stuff will land once my patches hit the Mesa list or ... ? >>>>> >>>>> Yup. >>>> >>>> Hey kernel first, then upstream projects, at the moment libdrm has >>>> ioctls in it that I have no upstream solid kernel commit for, >>>> >>>> Either in the next 24 hrs I have this in my tree or the libdrm commits >>>> need to be reverted, >>>> >>>> and if someone releases libdrm in that time span then I'm going to be >>>> quite pissed. >>> >>> It's kinda too late imo for 3.13 (and there's an open question whether >>> we need one more flag or not), so I wanted to pull it in into 3.14. >>> Which also gives us plenty of time to add or not add that optional >>> flag. So I guess time to revert. Can you do that pls? >> >> Reverting has completely broken Mesa builds, and was the wrong choice. >> Thanks for giving me opportunity to reply before breaking my stuff. > > Hey Ian, > > stop merging incomplete shit 5 mins before the branch point, Stop calling other people's hard work shit. It just makes you look like an asshole. Seriously. > you should know better, Mesa is meant to be moving to 3 mth release > cycle to avoid this kinda merge everything crap, That's not the reason for the 3 month cycle. The reason for the 3 month cycle is because all of the distros, including Fedora, were pulling random points from master because waiting 6 months for features and performance improvements was too long. > there was an open thread on the api for this feature, there was > questions of whether a drm cap was needed, you failed to address any I don't know where you're getting "drm cap" nonsense. That was closed two weeks ago: http://lists.freedesktop.org/archives/intel-gfx/2013-October/035016.html > of these and you merged the feature, the rules aren't different than > before, stuff goes in the kernel first and userspace second, we went > down this road before and it always gets screwed up. I thought Daniel and I had closed that, and I Acked-by the kernel patch. He and I talked about this on IRC. ***IF*** we need an extra flag for global resets, there's already a place for it in the (currently) pad field returned by the ioctl. This isn't some last minute, half-baked interface. We've been working on this for nearly a year. After going through several revisions, Mika's kernel patch has been on the intel-gfx list since July. That people are exploding about this now just boggles my mind. > Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
