Increasing Compositor Raster Worker Threads during low FPS

[Sohan Jyoti Ghosh]

Hello,

Is there a way we can increase the number of Raster Worker Threads in Worker Pool at run-time.

Currently, during Tile Manager creation, RasterWorkerPool is instantiated, and we can specify the number of thread workers, which is set up at layer_tree_settings.

For some low FPS sites, if we can change the number of threads at run-time, it could be beneficial.

Not sure, if the order of execution will be broken, if we add threads during run-time.

Regards,
Sohan

[David Reveman]

We currently need to know the number of raster threads at SkPicture record time to create the right amount of picture clones. I guess --num-raster-threads can be a max. In general, it wouldn't be too hard to adjust the number of raster threads at run-time but it's not clear to me how that would benefit us. Can you explain a bit more why this would be beneficial for low FPS sites?

David

 

Regards,
Sohan

[Sohan Jyoti Ghosh]

Hi David,

For some of the sites where Picture Raster is taking much time (~300-400ms), when we increased the number of raster threads, we found in Chrome Traces that the GLRenderer drawLayers and consequently didCompleteSwapBuffer happen more often, than with 1 raster thread.

But, the number of threads are only set at TileManager creation, how can we alter the number of thread once the tile manager is already created, we couldnt find any exposed function or code to do the same in RasterWorkerPool.

Regards,

Sohan

[David Reveman]

On Wed, Sep 11, 2013 at 11:06 AM, Sohan Jyoti Ghosh <sohanjy...@gmail.com> wrote:

Hi David,

For some of the sites where Picture Raster is taking much time (~300-400ms), when we increased the number of raster threads, we found in Chrome Traces that the GLRenderer drawLayers and consequently didCompleteSwapBuffer happen more often, than with 1 raster thread.

But, the number of threads are only set at TileManager creation, how can we alter the number of thread once the tile manager is already created, we couldnt find any exposed function or code to do the same in RasterWorkerPool.

Current code doesn't support changing it dynamically at run-time. What's the problem with just setting it to a higher value at TileManager creation time? 

[Nat Duca]

Sohan -

I would encourage you to investigate creating more than you need, then teaching the inner parts of the compositor to not use some of those threads on the fly, rather than trying to change the thread count dynamically.

[Leon Scroggins]

On Wed, Sep 11, 2013 at 10:42 AM, David Reveman <rev...@google.com> wrote:

On Wed, Sep 11, 2013 at 2:53 AM, Sohan Jyoti Ghosh <sohanjy...@gmail.com> wrote:

Hello,

Is there a way we can increase the number of Raster Worker Threads in Worker Pool at run-time.

Currently, during Tile Manager creation, RasterWorkerPool is instantiated, and we can specify the number of thread workers, which is set up at layer_tree_settings.

For some low FPS sites, if we can change the number of threads at run-time, it could be beneficial.

Not sure, if the order of execution will be broken, if we add threads during run-time.

We currently need to know the number of raster threads at SkPicture record time to create the right amount of picture clones.

FWIW, from Skia's point of view, you do not need to know the number of desired clones at record time, although that may be a chromium side restriction. In fact, SkPicture::clone can be called multiple times, but it is more efficient to create all clones at once.

 

I guess --num-raster-threads can be a max. In general, it wouldn't be too hard to adjust the number of raster threads at run-time but it's not clear to me how that would benefit us. Can you explain a bit more why this would be beneficial for low FPS sites?

David

 

Regards,
Sohan

To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev...@chromium.org.

--
Leon Scroggins III
scr...@google.com

[Adrienne Walker]

2013/9/11 Leon Scroggins <scr...@google.com>:

> FWIW, from Skia's point of view, you do not need to know the number of
> desired clones at record time, although that may be a chromium side
> restriction. In fact, SkPicture::clone can be called multiple times, but it
> is more efficient to create all clones at once.

Yeah, it makes things a little less complex on the compositor side to
do the cloning at record time rather than having to do it lazily much
later.

The ideal situation for us would be for Skia to not require cloning at
all and let us keep whatever unsafe state there is separate from the
SkPicture itself.

-enne

[Tom Wiltzius]

Out of curiosity, Sohan what heuristic were you intending to use to vary the worker pool size? Look at historical (some trailing average) tile raster times on a per-page basis and bump the worker pool if those times seemed long?

[Sohan Jyoti Ghosh]

Hi Tom,

We are planning to use a helper class, in lines of FrameRateCounter for HUD , to help ascertain the frame rate, and on low value, we planned to increase the pool size,

But, the problem is by the time we determine the avg FPS, TileManager is already created, and with it RasterWorkerPool size.

Dynamically, we are unable to vary the number of threads.

Regards,

Sohan

On Wednesday, September 11, 2013 12:23:05 PM UTC+5:30, Sohan Jyoti Ghosh wrote:

[David Reveman]

On Mon, Sep 16, 2013 at 1:19 AM, Sohan Jyoti Ghosh <sohanjy...@gmail.com> wrote:

Hi Tom,

We are planning to use a helper class, in lines of FrameRateCounter for HUD , to help ascertain the frame rate, and on low value, we planned to increase the pool size,

But, the problem is by the time we determine the avg FPS, TileManager is already created, and with it RasterWorkerPool size.

Dynamically, we are unable to vary the number of threads.

The easiest way to implement TileManager::SetNumRasterThreads(size_t) would be to just tear down the raster worker pool and create a new instance with the new number of raster threads. Not the most efficient way to adjust the number of raster threads but maybe it's good enough.

David

[Sohan Jyoti Ghosh]

Thanks David, will try the re-creation of RasterPool on demand, and see how it goes.

Regards,

Sohan

On Wednesday, September 11, 2013 12:23:05 PM UTC+5:30, Sohan Jyoti Ghosh wrote:

[ducbu...@gmail.com]

Hello,
I wonder whether there is any update about implementing dynamic number of Raster Worker threads.

If it is hard to change the number of created Raster Worker threads, how about changing the number of Worker threads which are actually used among the created threads?

Best regards,
Duke

[Sohan Jyoti Ghosh]

Hi,

We had done that sometime back, by deleting the existing worker pool, and creating a new one with more number of threads, there were some sync issues because of cloning.
But, now since skpicture can be accessed well across threads(?), we shoulnt face such issues.

There is some work going on for increasing default number of threads for more cpu cores, to get better perf with impl painting.

Maybe David/Vlad/Dana can comment better.

Thanks,
Sohan

[Dana Jansens]

We're in the process of enabling impl-side painting across our various platforms right now, and didn't want to throw multiple threads into that mix. We will take another look at this for M40 or 41.