Workaround Linux AMD driver bug where TEXTURE_MAX_ANISOTROPY init value is incorrect.

Workaround Linux AMD driver bug where TEXTURE_MAX_ANISOTROPY init value is incorrect.

So the first time we query this for a texture, we init it to 1 first before querying.

BUG=348237
TEST=webgl conformance tests on Linux AMD, gpu_unittests
R=bajones@chromium.org, kbr@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=254885

[Zhenyao Mo, 2014-03-04 00:27:53]

kbr, bajones: please review.

[Zhenyao Mo, 2014-03-04 00:29:12]

yzshen: ppapi/shared_impl/ppb_opengles2_shared.cc owner.

The change in this file is all auto-generated. No idea why it's not checked in
when the generator changed last time.

[bajones, 2014-03-04 00:47:15]

One change needed and one question, but otherwise LGTM

https://codereview.chromium.org/182413006/diff/1/gpu/config/gpu_driver_bug_li...
File gpu/config/gpu_driver_bug_list_json.cc (right):

https://codereview.chromium.org/182413006/diff/1/gpu/config/gpu_driver_bug_li...
gpu/config/gpu_driver_bug_list_json.cc:855: "description": "Linux AMD drivers
incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY",
Description appears to conflict with code logic. Should it be "Linux AMD drivers
*DO NOT* return an initial value of 1..."?

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
File ppapi/shared_impl/ppb_opengles2_shared.cc (right):

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
ppapi/shared_impl/ppb_opengles2_shared.cc:9: #include
"ppapi/shared_impl/ppb_opengles2_shared.h"
Does this file contain anything other than style tweaks? If so I couldn't find
it. (Style changes are fine, I just don't want to miss functionality changes in
my review.)

[Ken Russell (switch to Gerrit), 2014-03-04 00:47:19]

Have you verified that the texture behaves as though the TEXTURE_MAX_ANISOTROPY
parameter is set to 1.0 even if it's returning something different?

What is the value that's returned from the query when the bug happens?

[Zhenyao Mo, 2014-03-04 01:55:58]

https://codereview.chromium.org/182413006/diff/1/gpu/config/gpu_driver_bug_li...
File gpu/config/gpu_driver_bug_list_json.cc (right):

https://codereview.chromium.org/182413006/diff/1/gpu/config/gpu_driver_bug_li...
gpu/config/gpu_driver_bug_list_json.cc:855: "description": "Linux AMD drivers
incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY",
On 2014/03/04 00:47:15, bajones wrote:
> Description appears to conflict with code logic. Should it be "Linux AMD
drivers
> *DO NOT* return an initial value of 1..."?  

Ah right. Thx for catching this.

[Zhenyao Mo, 2014-03-04 01:58:52]

On 2014/03/04 00:47:19, Ken Russell wrote:
> Have you verified that the texture behaves as though the
TEXTURE_MAX_ANISOTROPY
> parameter is set to 1.0 even if it's returning something different?
> 
> What is the value that's returned from the query when the bug happens?

It returns 0 instead without the workaround, which is an invalid value for
ANISOTROPY.  The expected value is 1, which should have no effects on textures,
and which is exactly the case.  So I think the real value is actually 1, only
they return 0.

[Zhenyao Mo, 2014-03-04 01:59:31]

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
File ppapi/shared_impl/ppb_opengles2_shared.cc (right):

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
ppapi/shared_impl/ppb_opengles2_shared.cc:9: #include
"ppapi/shared_impl/ppb_opengles2_shared.h"
On 2014/03/04 00:47:15, bajones wrote:
> Does this file contain anything other than style tweaks? If so I couldn't find
> it. (Style changes are fine, I just don't want to miss functionality changes
in
> my review.)

I didn't touch this file at all.  It's all auto-generated.

[Ken Russell (switch to Gerrit), 2014-03-04 02:07:22]

OK, thanks for the information.

I would have suggested doing this during texture initialization, if the code
would have been simpler, but it looks OK as is. LGTM (I'm not an owner in this
directory, though.)

[yzshen1, 2014-03-04 05:51:15]

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
File ppapi/shared_impl/ppb_opengles2_shared.cc (right):

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
ppapi/shared_impl/ppb_opengles2_shared.cc:112: PP_Resource context_id, GLenum
srcRGB, GLenum dstRGB, GLenum srcAlpha,
Please note that the old code conforms to Chromium style while the new code
doesn't.

[Zhenyao Mo, 2014-03-04 15:58:08]

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
File ppapi/shared_impl/ppb_opengles2_shared.cc (right):

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
ppapi/shared_impl/ppb_opengles2_shared.cc:112: PP_Resource context_id, GLenum
srcRGB, GLenum dstRGB, GLenum srcAlpha,
On 2014/03/04 05:51:15, yzshen1 wrote:
> Please note that the old code conforms to Chromium style while the new code
> doesn't.

Which part?  The new code also conforms I think.

[Zhenyao Mo, 2014-03-04 16:13:16]

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
File ppapi/shared_impl/ppb_opengles2_shared.cc (right):

https://codereview.chromium.org/182413006/diff/1/ppapi/shared_impl/ppb_opengl...
ppapi/shared_impl/ppb_opengles2_shared.cc:1363: &ActiveTexture,
Ah, this should be 4-space instead of 2.

I'll leave this file out of this CL then.  Fixing the generated code style
should be in a separate followup CL from this one. Not sure how this gets in
previously though.  This file should never be manually edited.

[Zhenyao Mo, 2014-03-04 21:05:15]

Per discussion with dmichael, the format change happened in an effort to enforce
clang-format.

So the solution is for gpu/command_buffer/build_gles2_cmd_buffer.py to add
clang-format as the last step, and get rid of its own formatting logic.

But I'll do this in a separate CL.  For this CL, I'll leave
ppapi/shared_impl/ppb_opengles2_shared.cc untouched.

[Zhenyao Mo, 2014-03-04 21:10:56]

The CQ bit was checked by zmo@chromium.org

[commit-bot: I haz the power, 2014-03-04 21:13:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/zmo@chromium.org/182413006/20001

[Zhenyao Mo, 2014-03-05 00:12:08]

The CQ bit was unchecked by zmo@chromium.org

[Zhenyao Mo, 2014-03-05 00:27:01]

Committed patchset #2 manually as r254885 (presubmit successful).