Re: [Intel-gfx] [RFC][PATCH 1/1] drm/i915: Rewrite ILK+ watermark handling
On Thu, May 09, 2013 at 12:09:30PM -0700, Jesse Barnes wrote: > On Mon, 6 May 2013 16:45:52 +0300 > ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > Rewrite the ILK+ watermark code to allow: > > - updating the watermarks safely (to avoid underruns) > > - pre-computing watermarks (will help with atomic modest and pageflip) > > - enabling LP1+ watermarks for HSW multi-pipe scenarios > > This looks like the right way to go long term. But Paulo's patches for > HSW are fairly small and make things better immediately, so we should > probably get them in first. Agreed. I'll try to review them properly soon, so far I just glanced at them. > This one needs to be split up somehow so we can review it better like > you mention in the TODO. > > Another thing that I used when doing the WM code way back when was to > port it to userspace and run through various configs to make sure the > values were all sane. Might be nice if we could do that easily > somehow, maybe with an #ifdef or putting all the wm stuff into a > separate file. Actually I had this stuff running in user space first :) It's not that hard to implement the required stubs to get some drm file to compile in userland. I did it already for drm_edid.c (stuff that I've neglected to publish anywhere). I've not tried it for i915 code, and I suppose it may be a bit more work. Splitting the watermark stuff into a separate file could help a bit though. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 1/1] drm/i915: Rewrite ILK+ watermark handling
On Mon, 6 May 2013 16:45:52 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rewrite the ILK+ watermark code to allow: > - updating the watermarks safely (to avoid underruns) > - pre-computing watermarks (will help with atomic modest and pageflip) > - enabling LP1+ watermarks for HSW multi-pipe scenarios This looks like the right way to go long term. But Paulo's patches for HSW are fairly small and make things better immediately, so we should probably get them in first. This one needs to be split up somehow so we can review it better like you mention in the TODO. Another thing that I used when doing the WM code way back when was to port it to userspace and run through various configs to make sure the values were all sane. Might be nice if we could do that easily somehow, maybe with an #ifdef or putting all the wm stuff into a separate file. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 1/1] drm/i915: Rewrite ILK+ watermark handling
2013/5/6 : > From: Ville Syrjälä > > Rewrite the ILK+ watermark code to allow: > - updating the watermarks safely (to avoid underruns) > - pre-computing watermarks (will help with atomic modest and pageflip) > - enabling LP1+ watermarks for HSW multi-pipe scenarios > > The watermark registers are not double buffered, so we have to be > careful when/how we update them. It might be possible to increase the > watermark level before a plane update occurs, but decreasing the > watermark must happen after the plane update has finished. Also the > FIFO split can change depending on whether a sprite is enabled or not. > > The HSW multi-pipe low power watermark feature adds another level of > complexity since the LP watermarks must be the max of all pipes at any > given time. > > All of this makes the whole idea of updating watermarks before the plane > update too difficult. Instead just always update watermarks from the > vblank interrupt. > > We track the pending and active watermark levels for each pipe > separately, and when the active levels for any pipe are updated from the > vblank interrupt, we update the merged LP watermarks as well. We also > need to track the active state of sprites and pipes alongside the > watermarks to make sure we check the merged watermarks against the correct > limits. The assumption is that if even one pipe is using a sprite we > must check the merged values against the 1:1 (or 1:5) split FIFO sizes. > > TODO: > - pre-gen5/vlv obviously > - are the IVB sprite scaling workarounds good enough or do we need > extra vbl waits there? > - lots of testing to make sure it works I wanted to see if the values computed were correct, so I compiled your gitorious tree. On Haswell, it gives a "divide error" when I try to modprobe i915.ko. -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
