Allow WebGL readback for Mesa llvmpipe driver

Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899
R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel

Committed: https://crrev.com/883c491b1d8a92b3b46d3c8689dd0720e72900e7
Cr-Commit-Position: refs/heads/master@{#389879}

[Julien Isorce Samsung, 2016-02-12 14:38:54]

Description was changed from

==========
Allow GPU composition for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow starting the gpu
process.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
should start the gpu process.

Review URL:
==========

to

==========
Allow GPU composition for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
should start the gpu process.
==========

[Julien Isorce Samsung, 2016-02-12 14:40:33]

Description was changed from

==========
Allow GPU composition for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
should start the gpu process.
==========

to

==========
Allow GPU composition for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
should start the gpu process.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-02-12 14:42:24]

Hi, please review. The delta "1" contains rebase as mentioned in "Patch Set 2".

[piman, 2016-02-12 21:14:29]

Does it pass the conformance tests?

We could consider this, but:
1- It would likely regress plain old page rendering performance, since we would
then go into GL compositing mode + llvmpipe instead of 2D compositing mode using
skia, and I suspect just the extra overhead of command buffer copies will make
it slower.
2- We wouldn't want additional support burden. The marginal utility of webgl for
linux users without a GPU is fairly low (compared to the above).

[Ken Russell (switch to Gerrit), 2016-02-17 02:50:24]

kbr@chromium.org changed reviewers:
+ senorblanco@chromium.org

[Ken Russell (switch to Gerrit), 2016-02-17 02:50:25]

I agree with Antoine's concerns -- it seems to me to be the wrong direction to
start going down Chromium's OpenGL code paths on machines using Mesa + LLVMpipe.

[Julien Isorce Samsung, 2016-02-17 15:56:16]

On 2016/02/12 21:14:29, piman wrote:
> Does it pass the conformance tests?
Yes it does pass most of the tests:

Test Summary (49113 total tests):
Tests ran in 1455719175.84 seconds (this value seems wrong since it just took
around 10 min to run all tests)
Tests PASSED: 48492
Tests FAILED: 621
Tests TIMED OUT: 0
Tests SKIPPED: 0

Failures are mostly in: 
conformance/extensions/oes-texture-half-float-with-canvas.html (699 of 867
passed)
conformance/extensions/oes-texture-half-float-with-video.html (26 of 99 passed)
conformance/textures/misc/texture-size-limit.html (1217 of 1577 passed) ->
failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY

this is with --use-gl=egl. Number of failure goes down to 424 with
--use-gl=desktop (i.e. glx). I have not tried to compare with "nouveau" driver
yet but it looks to me a pretty good support. Also llvmpipe driver is supposed
to pass most piglit tests (https://cgit.freedesktop.org/piglit) like other Mesa
drivers. Also see mesamatrix: https://mesamatrix.net/

> 
> We could consider this, but:
> 1- It would likely regress plain old page rendering performance, since we
would
> then go into GL compositing mode + llvmpipe instead of 2D compositing mode
using
> skia, and I suspect just the extra overhead of command buffer copies will make
> it slower.

Good point I can try to run some benchmark. My initial intention was not to have
something the most efficient but just having usable software equivalent of real
case, i.e. using gpu process. softpipe driver is really not usable with GL
compositing mode but llvmpipe driver is really fast.
Which chromium benchmark tests in particular would be good for that comparison
between GL compositing mode vs 2D compositing/skia? 

Also here http://code.google.com/p/chromium/issues/detail?id=91208#c104 I ran
tools/perf/run_benchmark blink_perf.canvas but this test does not run with skia
since I got (===== SKIPPING TEST upload-video-to-texture.html: Skipped because
story is not supported ) when the gl driver is black listed.

> 2- We wouldn't want additional support burden. The marginal utility of webgl
for
> linux users without a GPU is fairly low (compared to the above).

It is useful for headless mode when using Xvfb. I can see "--xvfb" in
chromium/src/testing/scripts/common.py, and AFAIK you can only use a software
driver with Xvfb. In which case this option is used in Chromium ? for some try
bots ?
It can also be useful when using Chromium in VirtualBox.

On 2016/02/17 02:50:25, Ken Russell wrote:
> I agree with Antoine's concerns -- it seems to me to be the wrong direction to
> start going down Chromium's OpenGL code paths on machines using Mesa +
LLVMpipe.

I personally find it useful to compare with real driver. But I get your point
that you do not want to receive extra bugs because of that enablement. (Also I
can still pass --ignore-gpu-blacklist)

[piman, 2016-02-17 21:50:45]

On Wed, Feb 17, 2016 at 7:56 AM, <j.isorce@samsung.com> wrote:

> On 2016/02/12 21:14:29, piman wrote:
> > Does it pass the conformance tests?
> Yes it does pass most of the tests:
>
> Test Summary (49113 total tests):
> Tests ran in 1455719175.84 seconds (this value seems wrong since it just took
> around 10 min to run all tests)
> Tests PASSED: 48492
> Tests FAILED: 621
> Tests TIMED OUT: 0
> Tests SKIPPED: 0
>
> Failures are mostly in:
> conformance/extensions/oes-texture-half-float-with-canvas.html (699 of 867
> passed)
> conformance/extensions/oes-texture-half-float-with-video.html (26 of 99
passed)
> conformance/textures/misc/texture-size-limit.html (1217 of 1577 passed) ->
> failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY
>
> this is with --use-gl=egl. Number of failure goes down to 424 with
> --use-gl=desktop (i.e. glx). I have not tried to compare with "nouveau"
driver
> yet but it looks to me a pretty good support. Also llvmpipe driver is
supposed
> to pass most piglit tests (https://cgit.freedesktop.org/piglit) like other
Mesa
> drivers. Also see mesamatrix: https://mesamatrix.net/
>
> >
> > We could consider this, but:
> > 1- It would likely regress plain old page rendering performance, since we
> would
> > then go into GL compositing mode + llvmpipe instead of 2D compositing mode
> using
> > skia, and I suspect just the extra overhead of command buffer copies will
make
> > it slower.
>
> Good point I can try to run some benchmark. My initial intention was not to
have
> something the most efficient but just having usable software equivalent of
real
> case, i.e. using gpu process. softpipe driver is really not usable with GL
> compositing mode but llvmpipe driver is really fast.
> Which chromium benchmark tests in particular would be good for that
comparison
> between GL compositing mode vs 2D compositing/skia?
>
> Some telemetry tests. thread_times.tough_compositor_cases  is probably a
good one. The smoothness tests as well.

>
> Also here http://code.google.com/p/chromium/issues/detail?id=91208#c104 I ran
> tools/perf/run_benchmark blink_perf.canvas but this test does not run with
skia
> since I got (===== SKIPPING TEST upload-video-to-texture.html: Skipped
because
> story is not supported ) when the gl driver is black listed.
>
> > 2- We wouldn't want additional support burden. The marginal utility of
webgl
> for
> > linux users without a GPU is fairly low (compared to the above).
>
> It is useful for headless mode when using Xvfb. I can see "--xvfb" in
> chromium/src/testing/scripts/common.py, and AFAIK you can only use a software
> driver with Xvfb. In which case this option is used in Chromium ? for some
try
> bots ?
> It can also be useful when using Chromium in VirtualBox.
>
> On 2016/02/17 02:50:25, Ken Russell wrote:
> > I agree with Antoine's concerns -- it seems to me to be the wrong direction
to
> > start going down Chromium's OpenGL code paths on machines using Mesa +
> LLVMpipe.
>
> I personally find it useful to compare with real driver. But I get your point
> that you do not want to receive extra bugs because of that enablement. (Also
I
> can still pass --ignore-gpu-blacklist)
>
>
> https://codereview.chromium.org/1548893004/
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Julien Isorce Samsung, 2016-02-18 11:25:16]

On 2016/02/17 21:50:45, piman wrote:
> On Wed, Feb 17, 2016 at 7:56 AM, <mailto:j.isorce@samsung.com> wrote:
> > Which chromium benchmark tests in particular would be good for that
> > comparison
> > between GL compositing mode vs 2D compositing/skia?
>
> Some telemetry tests. thread_times.tough_compositor_cases  is probably a
> good one. The smoothness tests as well.

Here results https://drive.google.com/file/d/0B-3c0686agmNb29YTzhTb05jTXM/view
for "tools/perf/run_benchmark thread_times.tough_compositor_cases
--browser=release", you need to download the file first.
In order:

llvmpipe, gpu process, glx  |  llvmpipe, no gpu process, glx  | nouveau gpu
process, glx | llvmpipe, gpu process, egl | llvmpipe, no gpu process, egl  |
nouveau, gpu process, egl with --ignore-gpu-blacklist |

The graphs show that there is no obvious difference between glx and egl on this
benchmark. Make sense considering it is all Mesa based.

But for "llvmpipe GL compositing mode" vs "llvmpipe 2D compositing/skia", it
seems the later is a bit faster but just by a few ms. But "llvmpipe GL
compositing mode" seems to be faster than using "nouveau" driver so I am not
sure to read the results properly.

I have not smoothness tests yet. There are lot of tests in there, maybe
smoothness.tough_scrolling_cases ?

> 
> >
> > It is useful for headless mode when using Xvfb. I can see "--xvfb" in
> > chromium/src/testing/scripts/common.py, and AFAIK you can only use a
software
> > driver with Xvfb. In which case this option is used in Chromium ? for some
> > try bots ?

So when is used Xvfb exactly ?

[piman, 2016-02-24 22:33:36]

On 2016/02/18 11:25:16, j.isorce wrote:
> On 2016/02/17 21:50:45, piman wrote:
> > On Wed, Feb 17, 2016 at 7:56 AM, <mailto:j.isorce@samsung.com> wrote:
> > > Which chromium benchmark tests in particular would be good for that
> > > comparison
> > > between GL compositing mode vs 2D compositing/skia?
> >
> > Some telemetry tests. thread_times.tough_compositor_cases  is probably a
> > good one. The smoothness tests as well.
> 
> Here results https://drive.google.com/file/d/0B-3c0686agmNb29YTzhTb05jTXM/view
> for "tools/perf/run_benchmark thread_times.tough_compositor_cases
> --browser=release", you need to download the file first.
> In order:
> 
> llvmpipe, gpu process, glx  |  llvmpipe, no gpu process, glx  | nouveau gpu
> process, glx | llvmpipe, gpu process, egl | llvmpipe, no gpu process, egl  |
> nouveau, gpu process, egl with --ignore-gpu-blacklist |
> 
> The graphs show that there is no obvious difference between glx and egl on
this
> benchmark. Make sense considering it is all Mesa based.
> 
> But for "llvmpipe GL compositing mode" vs "llvmpipe 2D compositing/skia", it
> seems the later is a bit faster but just by a few ms.

A few ms per frame is a lot!

> But "llvmpipe GL
> compositing mode" seems to be faster than using "nouveau" driver so I am not
> sure to read the results properly.

I think the numbers unfortunately don't count the thread times for the llvmpipe
threads, being not instrumented (because we don't know about them). That's
likely where the bulk of the CPU lies, however. Not sure how best to measure
that - one option would be to disable llvmpipe threading (so that it's counted
in the GPU thread), but that would distort the measurements (still would give a
good idea of the overall impact).

> 
> I have not smoothness tests yet. There are lot of tests in there, maybe
> smoothness.tough_scrolling_cases ?

That's probably a good one.

> 
> > 
> > >
> > > It is useful for headless mode when using Xvfb. I can see "--xvfb" in
> > > chromium/src/testing/scripts/common.py, and AFAIK you can only use a
> software
> > > driver with Xvfb. In which case this option is used in Chromium ? for some
> > > try bots ?
> 
> So when is used Xvfb exactly ?

It's used for tests on non-GPU bots - i.e. most of them. When using Xvfb, we
also use the OSMesa back-end from third_party/mesa, which is a known quantity,
though slow - and so we disable draws on most tests, so using llvmpipe would
probably not give a large difference on those. The few tests where we look at
pixels, the difference is probably in the noise, and probably not worth the
extra constraints of using a system-provided software implementation.


At a high level though, maybe the right thing to do is to allow llvmpipe, but
treat it just like swiftshader, i.e. it's allowed for webgl but we still do
compositing in 2D (i.e. we "readback" the webgl contents and composite in
software). There's a bit of infrastructure to do that, but some of it is
probably linked to --use-gl=swiftshader. This would need to be generalized a bit
(GPU process reports a software implementation -> we blacklist compositing but
still allow webgl).

[Julien Isorce Samsung, 2016-02-26 18:14:37]

On 2016/02/24 22:33:36, piman wrote:
> A few ms per frame is a lot!
Indeed, I did not know it was FPS, the graph description is not shown properly
so it is not readable ...

> 
> > But "llvmpipe GL
> > compositing mode" seems to be faster than using "nouveau" driver so I am not
> > sure to read the results properly.
> 
> I think the numbers unfortunately don't count the thread times for the
llvmpipe
> threads, being not instrumented (because we don't know about them). That's
> likely where the bulk of the CPU lies, however. Not sure how best to measure
> that - one option would be to disable llvmpipe threading (so that it's counted
> in the GPU thread), but that would distort the measurements (still would give
a
> good idea of the overall impact).

The number of threads can be set through the env var: LP_MAX_THREADS
Using LP_MAX_THREADS=1 indeed increase the difference between "GL compositing
mode + llvmpipe" and "2D compositing mode using skia".
Maybe kNumRasterThreads has an impact as well ?


> > So when is used Xvfb exactly ?
> 
> It's used for tests on non-GPU bots - i.e. most of them. When using Xvfb, we
> also use the OSMesa back-end from third_party/mesa, which is a known quantity,
> though slow - and so we disable draws on most tests, so using llvmpipe would
> probably not give a large difference on those. The few tests where we look at
> pixels, the difference is probably in the noise, and probably not worth the
> extra constraints of using a system-provided software implementation.
> 
> 
> At a high level though, maybe the right thing to do is to allow llvmpipe, but
> treat it just like swiftshader, i.e. it's allowed for webgl but we still do
> compositing in 2D (i.e. we "readback" the webgl contents and composite in
> software). There's a bit of infrastructure to do that, but some of it is
> probably linked to --use-gl=swiftshader. This would need to be generalized a
bit
> (GPU process reports a software implementation -> we blacklist compositing but
> still allow webgl).

From this remark I naively tried to blacklist all features except "webgl" but it
seems webgl cannot be enabled without "gpu_compositing".
Which now make sense with there is this special --use-gl=swiftshader case you
described.
Which one of egl or glx is used to create a gl context when --use-gl=swiftshader
is set ?

Also I tried:
LP_MAX_THREADS=1 GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
tools/perf/run_benchmark --browser=release smoothness.tough_scrolling_cases
--extra-browser-args="--use-gl=swiftshader" 
and it is faster than "2D Compositing skia".
So I think that what you suggested ("allow webgl but we still do compositing in
2D") make a very good case for llvmpipe.

Would it be a solution to setup a new workaround, for example
"ALLOW_WEBGL_WITHOUT_GPU_COMPOSITING" and activate it for llvmpipe ? (so first
an exception in blacklist and then a workaround for llvmpipe in
gpu_driver_bug_list_json.cc) 
But this is just for the "surface"/"user", in any case I'll dig it out more to
see how this would work.

Thx for the suggestions.

[piman, 2016-02-26 23:39:12]

On Fri, Feb 26, 2016 at 10:14 AM, <j.isorce@samsung.com> wrote:

> On 2016/02/24 22:33:36, piman wrote:
> > A few ms per frame is a lot!
> Indeed, I did not know it was FPS, the graph description is not shown
> properly
> so it is not readable ...
>
> >
> > > But "llvmpipe GL
> > > compositing mode" seems to be faster than using "nouveau" driver so I
> am not
> > > sure to read the results properly.
> >
> > I think the numbers unfortunately don't count the thread times for the
> llvmpipe
> > threads, being not instrumented (because we don't know about them).
> That's
> > likely where the bulk of the CPU lies, however. Not sure how best to
> measure
> > that - one option would be to disable llvmpipe threading (so that it's
> counted
> > in the GPU thread), but that would distort the measurements (still would
> give
> a
> > good idea of the overall impact).
>
> The number of threads can be set through the env var: LP_MAX_THREADS
> Using LP_MAX_THREADS=1 indeed increase the difference between "GL
> compositing
> mode + llvmpipe" and "2D compositing mode using skia".
>

http://www.mesa3d.org/envvars.html suggests using LP_MAX_THREADS=0 disables
threading altogether.


> Maybe kNumRasterThreads has an impact as well ?
>

Most likely yes. We're counting CPU time on all raster threads and add that
together, but it's likely that e.g. single-thread is more efficient in
terms of CPU usage than multi-thread (but is likely slower overall).


> > > So when is used Xvfb exactly ?
> >
> > It's used for tests on non-GPU bots - i.e. most of them. When using
> Xvfb, we
> > also use the OSMesa back-end from third_party/mesa, which is a known
> quantity,
> > though slow - and so we disable draws on most tests, so using llvmpipe
> would
> > probably not give a large difference on those. The few tests where we
> look at
> > pixels, the difference is probably in the noise, and probably not worth
> the
> > extra constraints of using a system-provided software implementation.
> >
> >
> > At a high level though, maybe the right thing to do is to allow
> llvmpipe, but
> > treat it just like swiftshader, i.e. it's allowed for webgl but we still
> do
> > compositing in 2D (i.e. we "readback" the webgl contents and composite in
> > software). There's a bit of infrastructure to do that, but some of it is
> > probably linked to --use-gl=swiftshader. This would need to be
> generalized a
> bit
> > (GPU process reports a software implementation -> we blacklist
> compositing but
> > still allow webgl).
>
> From this remark I naively tried to blacklist all features except "webgl"
> but it
> seems webgl cannot be enabled without "gpu_compositing".
> Which now make sense with there is this special --use-gl=swiftshader case
> you
> described.
> Which one of egl or glx is used to create a gl context when
> --use-gl=swiftshader
> is set ?
>

egl. swiftshader is only used on Windows, where glx is not an option.


>
> Also I tried:
> LP_MAX_THREADS=1 GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
> tools/perf/run_benchmark --browser=release smoothness.tough_scrolling_cases
> --extra-browser-args="--use-gl=swiftshader"
> and it is faster than "2D Compositing skia".
> So I think that what you suggested ("allow webgl but we still do
> compositing in
> 2D") make a very good case for llvmpipe.
>
> Would it be a solution to setup a new workaround, for example
> "ALLOW_WEBGL_WITHOUT_GPU_COMPOSITING" and activate it for llvmpipe ? (so
> first
> an exception in blacklist and then a workaround for llvmpipe in
> gpu_driver_bug_list_json.cc)
>

I would rather avoid having 2 ways of expressing the same thing, so if we
can maybe decouple "webgl" from "gpu compositing" (and swiftshader) that
would be best.

Maybe let's continue this discussion on a bug?


> But this is just for the "surface"/"user", in any case I'll dig it out
> more to
> see how this would work.
>
> Thx for the suggestions.
>
>
>
> https://codereview.chromium.org/1548893004/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Julien Isorce Samsung, 2016-04-12 15:26:49]

Description was changed from

==========
Allow GPU composition for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
should start the gpu process.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still wont't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-04-12 15:34:55]

On 2016/02/26 23:39:12, piman wrote:
> I would rather avoid having 2 ways of expressing the same thing, so if we
> can maybe decouple "webgl" from "gpu compositing" (and swiftshader) that
> would be best.
> 
> Maybe let's continue this discussion on a bug?

Sorry for late reply. So I was about to investigate how "webgl" and "gpu
compositing" can be decouple and it turned out that it is already the case. I
think I made a mistake last time when I enabled webgl while keeping
gpu_compositing disabled (or maybe due to a recent enhancement ?).

So with the new entry in software_rendering_list_json.cc, when using llvmpipe
drier the user will find the following info on chrome://gpu :

Canvas: Software only, hardware acceleration unavailable
Flash: Software only, hardware acceleration unavailable
Flash Stage3D: Software only, hardware acceleration unavailable
Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
Compositing: Software only, hardware acceleration unavailable
  -> means 2d compositing Skia isn't it ?
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated but at reduced performance
  -> which means 'enabled_readback', see
content/browser/resources/gpu/info_view.js)

I also added a browser test and updated CL description.

[piman, 2016-04-14 02:46:14]

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (left):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:528: "driver_vendor": "Mesa",
Any reason for removing this?

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (right):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
@zmo: is there a way to do the opposite, disable all features but whitelist
webgl? I worry that this won't be maintained as we add other features.

[Ken Russell (switch to Gerrit), 2016-04-14 02:56:26]

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (right):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
On 2016/04/14 02:46:14, piman wrote:
> @zmo: is there a way to do the opposite, disable all features but whitelist
> webgl? I worry that this won't be maintained as we add other features.

Not to speak for zmo@ but I suspect the JSON file would have to be extended with
an "enabled_features" list whose semantic is the opposite of "features".

[Julien Isorce Samsung, 2016-04-14 17:54:28]

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (left):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:528: "driver_vendor": "Mesa",
On 2016/04/14 02:46:14, piman wrote:
> Any reason for removing this?
It is a mistake :)

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (right):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
On 2016/04/14 02:56:26, Ken Russell wrote:
> On 2016/04/14 02:46:14, piman wrote:
> > @zmo: is there a way to do the opposite, disable all features but whitelist
> > webgl? I worry that this won't be maintained as we add other features.
> 
> Not to speak for zmo@ but I suspect the JSON file would have to be extended
with
> an "enabled_features" list whose semantic is the opposite of "features".

If there is no way to express that (zmo@ ?), and since it would only make sense
to use that whitelist when the "all" keyword is used (if I am not mistaken), I
suggest the following format (instead of "enabled_features"):
all^webgl,accelerated_video_decode,flash_stage3d . So in that CL I would be use:
all^webgl

[Zhenyao Mo, 2016-04-14 20:23:45]

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (right):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
We can implement an "exception" to the "features", so add "all" and enabled
features in the "exception". This should be implemented separately from this CL.

[Julien Isorce Samsung, 2016-04-14 21:10:06]

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
File gpu/config/software_rendering_list_json.cc (right):

https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
On 2016/04/14 20:23:45, Zhenyao Mo wrote:
> We can implement an "exception" to the "features", so add "all" and enabled
> features in the "exception". This should be implemented separately from this
CL.

Thx Zhenyao for your suggestion. But to avoid any confusion, do you mean:

a)

{
  "id": 1,
  "os": {
    "type": "linux"
  },
  "gl_renderer": "*engine*",
  "features": [
    "all",
    "exception": [
      "accelerated_video_decode",
      "webgl"
    ]
  ]
}

or

b)

{
  "id": 2,
  "description": "Some desc2",
  "os": {
  "type": "linux"
  },
  "vendor_id": "0x1002",
  "exceptions": [
    {
      "driver_vendor": ".*AMD.*",
      "features": [
        "webgl",
        "accelerated_video_decode"
      ]
    }
  ],
  "features": [
    "all"
  ]
}

I already thought about b) but it was not possible because of current
implementation of ControlList::MakeDecision + Entry::Contain logic.

But I think what you suggest is something similar to a) but this cannot be
exactly a) because this "features" is a list so it cannot contains a key+val
unless I am mistaken.

So can you provide an example for the format ? Thx.

[Zhenyao Mo, 2016-04-14 21:36:16]

On 2016/04/14 21:10:06, j.isorce wrote:
>
https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
> File gpu/config/software_rendering_list_json.cc (right):
> 
>
https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
> gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
> On 2016/04/14 20:23:45, Zhenyao Mo wrote:
> > We can implement an "exception" to the "features", so add "all" and enabled
> > features in the "exception". This should be implemented separately from this
> CL.
> 
> Thx Zhenyao for your suggestion. But to avoid any confusion, do you mean:
> 
> a)
> 
> {
>   "id": 1,
>   "os": {
>     "type": "linux"
>   },
>   "gl_renderer": "*engine*",
>   "features": [
>     "all",
>     "exception": [
>       "accelerated_video_decode",
>       "webgl"
>     ]
>   ]
> }
> 
> or
> 
> b)
> 
> {
>   "id": 2,
>   "description": "Some desc2",
>   "os": {
>   "type": "linux"
>   },
>   "vendor_id": "0x1002",
>   "exceptions": [
>     {
>       "driver_vendor": ".*AMD.*",
>       "features": [
>         "webgl",
>         "accelerated_video_decode"
>       ]
>     }
>   ],
>   "features": [
>     "all"
>   ]
> }
> 
> I already thought about b) but it was not possible because of current
> implementation of ControlList::MakeDecision + Entry::Contain logic.
> 
> But I think what you suggest is something similar to a) but this cannot be
> exactly a) because this "features" is a list so it cannot contains a key+val
> unless I am mistaken.
> 
> So can you provide an example for the format ? Thx.

I was thinking about a), but we have to modify the gpu_control_list
implementation to make it possible. The existing semantics won't allow that. 
That's why I suggest to use the current json file change you did, and do this in
a separate CL.

[Julien Isorce Samsung, 2016-04-26 16:16:13]

On 2016/04/14 21:36:16, Zhenyao Mo wrote:
> On 2016/04/14 21:10:06, j.isorce wrote:
> >
>
https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
> > File gpu/config/software_rendering_list_json.cc (right):
> > 
> >
>
https://codereview.chromium.org/1548893004/diff/60001/gpu/config/software_ren...
> > gpu/config/software_rendering_list_json.cc:1242: "gpu_rasterization"
> > On 2016/04/14 20:23:45, Zhenyao Mo wrote:
> > > We can implement an "exception" to the "features", so add "all" and
enabled
> > > features in the "exception". This should be implemented separately from
this
> > CL.
> > 
> > Thx Zhenyao for your suggestion. But to avoid any confusion, do you mean:
> > 
> > a)
> > 
> > {
> >   "id": 1,
> >   "os": {
> >     "type": "linux"
> >   },
> >   "gl_renderer": "*engine*",
> >   "features": [
> >     "all",
> >     "exception": [
> >       "accelerated_video_decode",
> >       "webgl"
> >     ]
> >   ]
> > }
> > 
> > or
> > 
> > b)
> > 
> > {
> >   "id": 2,
> >   "description": "Some desc2",
> >   "os": {
> >   "type": "linux"
> >   },
> >   "vendor_id": "0x1002",
> >   "exceptions": [
> >     {
> >       "driver_vendor": ".*AMD.*",
> >       "features": [
> >         "webgl",
> >         "accelerated_video_decode"
> >       ]
> >     }
> >   ],
> >   "features": [
> >     "all"
> >   ]
> > }
> > 
> > I already thought about b) but it was not possible because of current
> > implementation of ControlList::MakeDecision + Entry::Contain logic.
> > 
> > But I think what you suggest is something similar to a) but this cannot be
> > exactly a) because this "features" is a list so it cannot contains a key+val
> > unless I am mistaken.
> > 
> > So can you provide an example for the format ? Thx.
> 
> I was thinking about a), but we have to modify the gpu_control_list
> implementation to make it possible. The existing semantics won't allow that. 
> That's why I suggest to use the current json file change you did, 

Ah ok I understand so I rebased the CL and uploaded it in patch set 5. Please
have a look.

> and do this in a separate CL.

I started to have a look, will submit something once I have first draft.

[Zhenyao Mo, 2016-04-26 17:31:31]

lgtm

[Julien Isorce Samsung, 2016-04-26 17:44:28]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-04-26 17:44:38]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1548893004/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1548893004/80001

[commit-bot: I haz the power, 2016-04-26 19:24:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-26 19:24:57]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-04-26 20:53:12]

Description was changed from

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still wont't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-04-26 20:54:31]

The CQ bit was checked by j.isorce@samsung.com

[commit-bot: I haz the power, 2016-04-26 20:54:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1548893004/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1548893004/80001

[commit-bot: I haz the power, 2016-04-26 21:04:23]

Description was changed from

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[commit-bot: I haz the power, 2016-04-26 21:04:24]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-04-26 21:06:24]

Description was changed from

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Allow WebGL readback for Mesa llvmpipe driver

Currently llvmpipe driver from Mesa is black listed.
It is fast and stable enough to allow using the gpu
process. But only enable WebGL, other features still won't
use the gpu process. For example the 2D Compositing Skia is
faster than gpu compositing on software GL driver.

BUG=571899

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1 chrome
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel

Committed: https://crrev.com/883c491b1d8a92b3b46d3c8689dd0720e72900e7
Cr-Commit-Position: refs/heads/master@{#389879}
==========

[commit-bot: I haz the power, 2016-04-26 21:06:25]

Patchset 5 (id:??) landed as
https://crrev.com/883c491b1d8a92b3b46d3c8689dd0720e72900e7
Cr-Commit-Position: refs/heads/master@{#389879}