On Fri, Mar 20, 2015 at 03:54:01PM +0100, Daniel Vetter wrote:
> On Thu, Mar 19, 2015 at 03:16:15PM +, Chris Wilson wrote:
> > On Thu, Mar 12, 2015 at 11:11:17AM +, Chris Wilson wrote:
> > > This provides a nice boost to mesa in swap bound scenarios (as mesa
> > > throttles itself to the pr
On Thu, Mar 19, 2015 at 03:16:15PM +, Chris Wilson wrote:
> On Thu, Mar 12, 2015 at 11:11:17AM +, Chris Wilson wrote:
> > This provides a nice boost to mesa in swap bound scenarios (as mesa
> > throttles itself to the previous frame and given the scenario that will
> > complete shortly). It
On Thu, Mar 12, 2015 at 11:11:17AM +, Chris Wilson wrote:
> This provides a nice boost to mesa in swap bound scenarios (as mesa
> throttles itself to the previous frame and given the scenario that will
> complete shortly). It will also provide a good boost to systems running
> with semaphores d
On Thu, Mar 12, 2015 at 05:32:26PM +, Tvrtko Ursulin wrote:
>
> On 03/12/2015 04:50 PM, Chris Wilson wrote:
> >On Thu, Mar 12, 2015 at 04:41:10PM +, Tvrtko Ursulin wrote:
> >>Yes I didn't mean that - but to have a boolean spinning-wait=on/off.
> >>Maybe default to "on" on HZ=1000 with pree
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5941
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -7 274/274
On 03/12/2015 04:50 PM, Chris Wilson wrote:
On Thu, Mar 12, 2015 at 04:41:10PM +, Tvrtko Ursulin wrote:
Yes I didn't mean that - but to have a boolean spinning-wait=on/off.
Maybe default to "on" on HZ=1000 with preemption, or the opposite,
something like that.
I don't see the point in hav
On Thu, Mar 12, 2015 at 04:41:10PM +, Tvrtko Ursulin wrote:
> Yes I didn't mean that - but to have a boolean spinning-wait=on/off.
> Maybe default to "on" on HZ=1000 with preemption, or the opposite,
> something like that.
I don't see the point in having the complication, until someone
complai
On 03/12/2015 04:28 PM, Chris Wilson wrote:
On Thu, Mar 12, 2015 at 03:18:01PM +, Tvrtko Ursulin wrote:
On 03/12/2015 01:18 PM, Chris Wilson wrote:
1ms. I was just thinking of doing USECS_PER_SEC / HZ, then realised that
was a jiffie, hence the confusion. At any rate, it is still the minim
On Thu, Mar 12, 2015 at 03:18:01PM +, Tvrtko Ursulin wrote:
> On 03/12/2015 01:18 PM, Chris Wilson wrote:
> >1ms. I was just thinking of doing USECS_PER_SEC / HZ, then realised that
> >was a jiffie, hence the confusion. At any rate, it is still the minimum
> >we can trivially wait for (without
On 03/12/2015 01:18 PM, Chris Wilson wrote:
On Thu, Mar 12, 2015 at 01:14:30PM +, Tvrtko Ursulin wrote:
On 03/12/2015 11:11 AM, Chris Wilson wrote:
This provides a nice boost to mesa in swap bound scenarios (as mesa
throttles itself to the previous frame and given the scenario that will
co
On Thu, Mar 12, 2015 at 01:14:30PM +, Tvrtko Ursulin wrote:
> On 03/12/2015 11:11 AM, Chris Wilson wrote:
> >This provides a nice boost to mesa in swap bound scenarios (as mesa
> >throttles itself to the previous frame and given the scenario that will
> >complete shortly). It will also provide
On 03/12/2015 11:11 AM, Chris Wilson wrote:
This provides a nice boost to mesa in swap bound scenarios (as mesa
throttles itself to the previous frame and given the scenario that will
complete shortly). It will also provide a good boost to systems running
with semaphores disabled and so frequentl
On Thu, Mar 12, 2015 at 11:11:17AM +, Chris Wilson wrote:
> This provides a nice boost to mesa in swap bound scenarios (as mesa
> throttles itself to the previous frame and given the scenario that will
> complete shortly). It will also provide a good boost to systems running
> with semaphores d
This provides a nice boost to mesa in swap bound scenarios (as mesa
throttles itself to the previous frame and given the scenario that will
complete shortly). It will also provide a good boost to systems running
with semaphores disabled and so frequently waiting on the GPU as it
switches rings. In
14 matches
Mail list logo
