Kai, could you try to reproduce this on your workstation? Thanks.

I'm able to reproduce on 60.0.3112.50 on my MacBook Air:

> gl.getParameter(gl.ALIASED_POINT_SIZE_RANGE)
Float32Array(2) [1, 255.875]

I'm trying to do a bisect but even in 57.0.2987.133 I'm seeing the same results.


Graphics Feature Status
Canvas: Hardware accelerated
CheckerImaging: Disabled
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
add_and_true_to_loop_condition
adjust_src_dst_region_for_blitframebuffer
decode_encode_srgb_for_generatemipmap
disable_framebuffer_cmaa
disable_multimonitor_multisampling
disable_webgl_rgb_multisampling_usage
emulate_abs_int_function
get_frag_data_info_bug
init_two_cube_map_levels_before_copyteximage
msaa_is_slow
pack_parameters_workaround_with_pack_buffer
rebind_transform_feedback_before_resume
regenerate_struct_names
remove_invariant_and_centroid_for_essl3
rewrite_texelfetchoffset_to_texelfetch
scalarize_vec_and_mat_constructor_args
set_zero_level_before_generating_mipmap
unfold_short_circuit_as_ternary_operation
unpack_alignment_workaround_with_unpack_buffer
unpack_image_height_workaround_with_unpack_buffer
use_intermediary_for_copy_texture_image
use_unused_standard_shared_blocks
avoid_stencil_buffers
Problems Detected
Multisampling is buggy on OSX when multiple monitors are connected: 237931
Applied Workarounds: disable_multimonitor_multisampling
Unfold short circuit on Mac OS X: 307751
Applied Workarounds: unfold_short_circuit_as_ternary_operation
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Mac drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
Applied Workarounds: msaa_is_slow
glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499
Applied Workarounds: set_zero_level_before_generating_mipmap
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777
Applied Workarounds: use_intermediary_for_copy_texture_image
Multisample renderbuffers with format GL_RGB8 have performance issues on Intel GPUs.: 607130
Applied Workarounds: disable_webgl_rgb_multisampling_usage
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
glGetFragData{Location|Index} works incorrectly on Max: 638340
Applied Workarounds: get_frag_data_info_bug
glResumeTransformFeedback works incorrectly on Intel GPUs: 638514
Applied Workarounds: rebind_transform_feedback_before_resume
Result of abs(i) where i is an integer in vertex shader is wrong: 642227
Applied Workarounds: emulate_abs_int_function
Rewrite texelFetchOffset to texelFetch for Intel Mac: 642605
Applied Workarounds: rewrite_texelfetchoffset_to_texelfetch
Rewrite condition in for and while loops for Intel Mac: 644669
Applied Workarounds: add_and_true_to_loop_condition
Decode and encode before generateMipmap for srgb format textures on macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Init first two levels before CopyTexImage2D for cube map texture on Intel Mac 10.12: 648197
Applied Workarounds: init_two_cube_map_levels_before_copyteximage
Insert statements to reference all members in unused std140/shared blocks on Mac: 618464
Applied Workarounds: use_unused_standard_shared_blocks
Tex(Sub)Image3D performs incorrectly when uploading from unpack buffer with GL_UNPACK_IMAGE_HEIGHT greater than zero on Intel Macs: 654258
Applied Workarounds: unpack_image_height_workaround_with_unpack_buffer
adjust src/dst region if blitting pixels outside read framebuffer on Mac: 644740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Mac driver GL 4.1 requires invariant and centroid to match between shaders: 639760, 641129
Applied Workarounds: remove_invariant_and_centroid_for_essl3
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Certain Apple devices leak stencil buffers: 713854
Applied Workarounds: avoid_stencil_buffers
Checker-imaging has been disabled via finch trial or the command line.
Disabled Features: checker_imaging
Version Information
Data exported	7/10/2017, 11:06:49 AM
Chrome version	Chrome/60.0.3112.50
Operating system	Mac OS X 10.12.5
Software rendering list version	13.7
Driver bug list version	10.91
ANGLE commit id	3e6a61fecba9
2D graphics backend	Skia/60 a46f69bf6f3283c8ee71674617f3eb27ad905565-
Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	177
In-process GPU	false
Passthrough Command Decoder	false
Supports overlays	false
Sandboxed	true
GPU0	VENDOR = 0x8086, DEVICE= 0x1626 *ACTIVE*
Optimus	false
Optimus	false
AMD switchable	false
Driver vendor	
Driver version	10.25.13
Driver date	
Pixel shader version	4.10
Vertex shader version	4.10
Max. MSAA samples	8
Machine model name	MacBookAir
Machine model version	7.2
GL_VENDOR	Intel Inc.
GL_RENDERER	Intel(R) HD Graphics 6000
GL_VERSION	4.1 INTEL-10.25.13
GL_EXTENSIONS	GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Window system binding vendor	
Window system binding version	
Window system binding extensions	
Direct rendering	Yes
Reset notification strategy	0x0000
GPU process crash count	0
Compositor Information
Tile Update Mode	Zero-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRX_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
RGBA_F16	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
YVU_420	Software only
YUV_420_BIPLANAR	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
UYVY_422	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT

Maybe the value I'm getting on mac is correct, then. I'll try to repro on ubuntu.

Okay, able to bisect on Linux. It seems to appear between 57.0 and 58.0 for me.

Bisect pointed to:
https://chromium.googlesource.com/chromium/src/+/ff06d6bb2507b7d412a0ccb283ed977c10023110

This seems to be a difference between core and compatibility profiles, or something like that. Unfortunately the GL_VERSION is the same across both builds.

> You are probably looking for a change made after 452816 (known good), but no later than 452817 (first known bad).

The only differences in the about:gpu for these two are:

452816: ANGLE commit id 34bf2d937d54, GL_ARB_compatibility
452817: ANGLE commit id 6a6b09c9b62b, no GL_ARB_compatibility

Not sure why the ANGLE commit changed (it actually seems to have gone backward). Maybe these two revisions are on different branches?

https://chromium.googlesource.com/angle/angle/+/34bf2d937d54..6a6b09c9b62b

cwallez: you know more about the core/compatibility differences. Can you tell if this is a valid issue?

I think ALIASED_POINT_SIZE_RANGE was removed from the Core Profile. Maybe Chrome's emulation of the query is wrong?

ah, I think you're right. let me look into that.

Don't we disable point size > 1 because of the scissor / viewport test for AMD vs. the rest of the world?

This ALIASED_POINT_SIZE_RANGE query only exists from OpenGL 3.2 compatibility and forward. I wasn't able to find it in OpenGL 3.1 but the spec language mentioning a queriable implementation dependent value for the point size appears in section 3.4.1.

The core profile doesn't have this language anymore, so we should emulate things there.

Also here's the relevant ANGLE code:

    if (functions->standard == STANDARD_GL_DESKTOP &&
        (functions->profile & GL_CONTEXT_CORE_PROFILE_BIT) != 0)
    {
        // Desktop GL core profile deprecated the GL_ALIASED_POINT_SIZE_RANGE query.  Use
        // GL_POINT_SIZE_RANGE instead.
        caps->minAliasedPointSize = QueryGLFloatRange(functions, GL_POINT_SIZE_RANGE, 0);
        caps->maxAliasedPointSize = QueryGLFloatRange(functions, GL_POINT_SIZE_RANGE, 1);
    }
    else
    {
        caps->minAliasedPointSize = QueryGLFloatRange(functions, GL_ALIASED_POINT_SIZE_RANGE, 0);
        caps->maxAliasedPointSize = QueryGLFloatRange(functions, GL_ALIASED_POINT_SIZE_RANGE, 1);
    }

No, we didn't enforce a maximum point size of 1.0 due to the issue of clipping of large points on AMD -- that was deemed a too heavy-handed workaround. In fact I think that behavioral difference is still in the code base.

(forgot to send earlier) The code responsible for this is here:
https://cs.chromium.org/chromium/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?l=6946&rcl=ee095bcb2656c72ca3411b9a2c98cb19e789bdd5

Chrome without ANGLE does the same thing: ALIASED_POINT_SIZE_RANGE is transformed into POINT_SIZE_RANGE. This seems valid to me?

Is is_desktop_core_profile being computed correctly on GLVersionInfo on Linux?

Actually I'm not sure there actually is an issue, the ES 2.0 says that the returned values are floats. See this paste of the implementation dependent values table:

ALIASED_POINT_SIZE_RANGE 2×R+ GetFloatv 1,1 Range (lo to hi) of point sizes

So returning floats is fine, and we're above the required minimum values so unless there is something else, I think this should be closed.

> Is is_desktop_core_profile being computed correctly on GLVersionInfo on Linux?

It seems fine. cwallez's change to use the core profile on Linux caused that `if (... && is_desktop_core_profile)` to pass, switching to the emulation path for ALIASED_POINT_SIZE_RANGE.

> So returning floats is fine, and we're above the required minimum values so unless there is something else, I think this should be closed.

I'm pretty sure this is the best we can do against a Core profile. The reporter's expected value of [1, 2047] no longer exists in Core profile since ALIASED_POINT_SIZE_RANGE is removed.

Closing, we can reopen if it turns out that [1, 189.875] isn't valid.

I will try to simplify my previous explanation to ensure this may be an error. Indeed, usage of ALIASED_POINT_SIZE_RANGE seems to be the only way to check maximum available point size in a WebGL application.

Extract from OpenGL ES 2.0 specifications :

"Point  size  is  taken  from  the  shader  builtin gl_PointSize and  clamped  to  the implementation-dependent point size range. If the value written to gl_PointSize is less than or equal to zero, results are undefined. The range is determined by the ALIASED_POINT_SIZE_RANGE and  may  be  queried  as  described  in  chapter  6. The maximum point size supported must be at least one."

It is OK if the returned value is a float, it is not if the returned value doesn't correspond to the maximum point size.

Here is a quick and dirty JSFiddle to show the problem : https://jsfiddle.net/Ludobaka/ro1nv0yk/4/

In the following attachment, the green sprite has the maximum point size value returned by gl.getParameter(gl.ALIASED_POINT_SIZE_RANGE). The red one has a bigger size and so should not be visible if ALIASED_POINT_SIZE_RANGE is accurate.

Deleted: debug_point_size_range.png 17.0 KB

	debug_point_size_range.png 17.0 KB View Download

You're right, I understand. Marking Available, I can't take this immediately.

I'm not exactly sure how desktop Core OpenGL is supposed to work. I would expect non-aliased POINT_SIZE_RANGE to be the actual max point size, but this is evidently not true. Maybe ALIASED_POINT_SIZE_RANGE can be computed from POINT_SIZE_RANGE?

This looks like a driver bug to me, that gl_PointSize isn't clamped to POINT_SIZE_RANGE on certain core profile drivers.

We should add a conformance test similar to the one provided in comment #18 and see how many drivers suffer from this.

A workaround I can think of is to insert code into the shader to always clamp before assigning values to gl_PointSize.

Do you mean clamping gl_PointSize to maximum ALIASED_POINT_SIZE_RANGE ? Sure you will not see the red sprite in my testcase, but it will constraint my GPU that can handle point sizes below 2047. So it will not represent GPU capabilities.

About driver issues, that may be the case, even if it occured on NVIDIA and ATI GPUs.

This problem is far beyond my knowledge but I'm at your disposal for any help. Indeed this issue is critical in our software. 

If the driver reports a smaller number in POINT_SIZE_RANGE, even if you successfully draw beyond that number, it's a risk I don't think you want to take.

As for now, one thing you can do is pass the maximum ALIASED_POINT_SIZE_RANGE as a uniform to the shader and make sure in the shader you clamp to that value.  Chrome workaround will basically do the same thing behind the scene.

Adding NVidia colleague to this bug.  Maybe it's a bug in reporting POINT_SIZE_RANGE that can easily be fixed?  So far I fail to see how the max point size is decided (the number seems random to me).

After further reading of the spec and discussion with cwallez, I do think this is a driver bug in the system's OpenGL driver.

Prior to Core Profile, there was SMOOTH_POINT_SIZE_RANGE and ALIASED_POINT_SIZE_RANGE. These referred to the size ranges of 'smooth' (round) points vs 'aliased' (square, sprite-style) points.

Smooth points are deprecated in Core Profile. As such, the SMOOTH_ and ALIASED_ versions were removed, leaving only POINT_SIZE_RANGE. However, POINT_SIZE_RANGE ought to report the (formerly) ALIASED_ value, but instead, I suspect it's reporting the (formerly) SMOOTH_ value.

> If the driver reports a smaller number in POINT_SIZE_RANGE, even if you successfully draw beyond that number, it's a risk I don't think you want to take.

The OpenGL spec does specify that the value written to gl_PointSize will be clamped to the implementation-dependent POINT_SIZE_RANGE.

zmo@ I'd be hesitant in adding a uniform to the shader as it would add a bunch of complexity. In this case all we need to do is a gl_PointSize = clamp(context-wide-constant, other-constant, gl_PointSize) to the end of the shader, which is a bit simpler.

I just tested kainino's assumption on my computer about POINT_SIZE_RANGE reporting SMOOTH_POINT_SIZE_RANGE instead of ALIASED_POINT_SIZE_RANGE in OpenGL. It is the case in my computer, however I still can draw sprites with size > max(POINT_SIZE_RANGE).

Debugged values :
* OpenGL POINT_SIZE_RANGE : [1.000000,189.875000]
* OpenGL SMOOTH_POINT_SIZE_RANGE : [1.000000,189.875000]
* OpenGL ALIASED_POINT_SIZE_RANGE : [1.000000,2047.000000]

By looking at the attached screenshot :
* Green size is POINT_SIZE_RANGE[1]
* Red size is > POINT_SIZE_RANGE[1]
* Blue size is ALIASED_POINT_SIZE_RANGE[1]
* Purple (not visible) size is > ALIASED_POINT_SIZE_RANGE[1]

So OpenGL is definitely clipping and point size value above ALIASED_POINT_SIZE_RANGE and not POINT_SIZE_RANGE.

You will find attached a simple OpenGL example. First time coding some OpenGL, so it's coded with old fixed pipeline.

Deleted: OpenGL_point_size_range.png 8.3 KB

	OpenGL_point_size_range.png 8.3 KB View Download

Deleted: test.c 2.7 KB

test.c 2.7 KB View Download

I have reported the issue to the NVIDIA GL driver team.

I can look into fixing this in ANGLE. If there's no workaround, this would regress when switching from DX to GL backend.

The GL 4.5 spec does mention that "Additional point widths may also be supported", though probably the intention is still that only point widths within the reported range are supported. It would be nice to get the spec clarified as well.

After doing some spec archaeology, I think I understand how this bug came to be (and why it exists in multiple drivers):

#define GL_POINT_SIZE_RANGE               0x0B12
#define GL_SMOOTH_POINT_SIZE_RANGE        0x0B12
#define GL_ALIASED_POINT_SIZE_RANGE       0x846D

OpenGL 1.0: POINT_SIZE_RANGE defined for smooth points
OpenGL 1.2: POINT_SIZE_RANGE deprecated. SMOOTH_POINT_SIZE_RANGE and ALIASED_POINT_SIZE_RANGE introduced.
OpenGL 3.0: Smooth points (POINT_SMOOTH, SMOOTH_POINT_SIZE_RANGE) deprecated.
OpenGL 3.1: Seems to have removed SMOOTH_POINT_SIZE_RANGE.
OpenGL 3.2 Core Profile: Smooth points removed. SMOOTH_POINT_SIZE_RANGE and POINT_SIZE_RANGE removed.
OpenGL 3.3 Core Profile: POINT_SIZE_RANGE redefined to refer to aliased points since they are the only kind of point (even though the enum still has the same value as SMOOTH_POINT_SIZE_RANGE).
OpenGL 3.3 Compatibility Profile: POINT_SIZE_RANGE still refers to smooth points for compatibility, AFAICT.

In short, POINT_SIZE_RANGE should refer to aliased points on 4.5 Core Profile, but to smooth points on 4.5 Compatibility Profile. But the drivers assume it refers to smooth points in both Core and Compatibility.

Meanwhile,

OpenGL ES 1.0: has SMOOTH_POINT_SIZE_RANGE, and ALIASED_POINT_SIZE_RANGE. POINT_SIZE_RANGE appears in the spec, but it doesn't exist in the headers.
OpenGL ES 2.0: removed SMOOTH_POINT_SIZE_RANGE, leaving only ALIASED_POINT_SIZE_RANGE. POINT_SIZE_RANGE no longer appears in the spec.

I took a more thorough look at the GL spec and it seems like the "additional point widths" can't refer to point widths outside the reported range - the GL spec does say that gl_PointSize is "clamped to the implementation-dependent point size range" in section 14.4.

ANGLE change is in review here: https://chromium-review.googlesource.com/c/574598/

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/ab918821c28501967fc2aff5738578a6610e72b8

commit ab918821c28501967fc2aff5738578a6610e72b8
Author: Olli Etuaho <oetuaho@nvidia.com>
Date: Wed Jul 19 18:31:00 2017

Clamp point size to maximum point size from the API on NVIDIA

NVIDIA OpenGL drivers have a bug where the point size range is being
reported incorrectly - it appears the core GL driver incorrectly gives
the range for smooth points, when it should be giving the range for
aliased points. Clamp the actual point size to the maximum point size
reported from the API so that the GLES spec is followed.

The same workaround seems to be necessary also on Android. The issue
was revealed by the trybots, and has not been fully diagnosed though.

The newly added test fails on AMD OpenGL.

As a part of this change, the existing tests in PointSpritesTest are
refactored to use gl_raii.

BUG=chromium:740560
TEST=angle_end2end_tests

Change-Id: Ic4a66c9ea16f5ae76beb3bb6577716d10c3b226e
Reviewed-on: https://chromium-review.googlesource.com/574598
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>

[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/RewriteTexelFetchOffset.cpp
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/include/GLSLANG/ShaderLang.h
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/IntermNode_util.cpp
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/IntermNode_util.h
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/Compiler.cpp
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/libANGLE/renderer/gl/ShaderGL.cpp
[add] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/ClampPointSize.h
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/tests/gl_tests/PointSpritesTest.cpp
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler.gypi
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/libANGLE/renderer/gl/renderergl_utils.cpp
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/libANGLE/renderer/gl/WorkaroundsGL.h
[modify] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/libANGLE/Compiler.cpp
[add] https://crrev.com/ab918821c28501967fc2aff5738578a6610e72b8/src/compiler/translator/ClampPointSize.cpp

There's now a workaround in ANGLE that makes sure that the point size limit is enforced, so it's spec-compliant. A fix to the NVIDIA GL driver is also in the works, so the full hardware capability will be unlocked again once that lands.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ff42baac92fc285e57d7da0a83c3337771706ad

commit 9ff42baac92fc285e57d7da0a83c3337771706ad
Author: Frank Henigman <fjhenigman@chromium.org>
Date: Thu Jul 20 22:11:52 2017

Roll ANGLE 4cff8d6..0d2ecb4

https://chromium.googlesource.com/angle/angle.git/+log/4cff8d6..0d2ecb4

BUG= 2110 ,,chromium:740560

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Change-Id: Ifb40c58cbb5f6438e6518d1a639aa5fb0a84273f
Reviewed-on: https://chromium-review.googlesource.com/580399
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488434}
[modify] https://crrev.com/9ff42baac92fc285e57d7da0a83c3337771706ad/DEPS

Tested the issue on ubuntu 14.04 using chrome M61 #61.0.3163.13 and M59 #59.0.3071.115 and same behavior is observed .

 As per cooment #18 , opened the jsfiddle "https://jsfiddle.net/Ludobaka/ro1nv0yk/4/" and observed that no red color is seen and only green color is visible.

Attched screenshot for reference.

@Could someone check attached screenshot and confirm us if this is the expected or if we have missed any steps in verifying the issue or please help us by providing the steps to reproduce the issue.

Thanks!

Deleted: 740560.png 144 KB

	740560.png 144 KB View Download

I think it is the expected behavior if you want to be compliant with the specifications. The browser is now clipping at maximum ALIASED_POINT_SIZE_RANGE value.

However, there is still an error here about POINT_SIZE_RANGE returning the wrong value (comments #25 / #27 / #30). Where should I send this issue to make it fixed ?

Sorry for the slow reply. In #31, oetuaho said this is already reported for NVIDIA.

Adding separate AMD, NVIDIA, and Qualcomm labels because there seem to be separate issues on all of these platforms. But on AMD and Qualcomm they still need to be investigated and reported. I'll try to take care of this eventually.

Reassigning to myself since I said I would take care of it.

On my Pixel 2016 (Qualcomm), the reported max point size is 1023, but the point size is actually clamped to about 4095 or so. This explains the testing failure on the Android bots. My spec archaeology does not explain why Qualcomm has a bug here, but this seems not to be tested by dEQP, which does explain it. ;P

Also, we never enabled the SH_CLAMP_POINT_SIZE option in Chrome, so this workaround is not taking effect in WebGL. So, TODO +=:
* Enable SH_CLAMP_POINT_SIZE in Chrome on necessary platforms.
* Write a WebGL test case.
* Write a dEQP test case. I'll try to tackle this one now.

In order to test ES implementations (Qualcomm seems to have a bug here for some reason) as well as ANGLE, I'm adding a dEQP test case:

https://android-review.googlesource.com/c/platform/external/deqp/+/597853

With Olli's workaround (#30) disabled, this reproduces the bug on Linux/NVIDIA. It also reproduces a bug on Android/Qualcomm.

I'm pretty sure this test will also expose some extra platform(s) which need the ANGLE workaround enabled - namely, at least, Linux/AMD. Further testing on Win/AMD and some other platforms (Mac/AMD, Linux/AMD, */Intel, */ARM) would be valuable so we can make sure to inform all of the necessary vendors.

Turns out this also affects NVIDIA Vulkan drivers. And it might be a recent regression. Turned up a test failure with the new driver upgrade in issue 887241 . 

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Exp%20Release%20%28NVIDIA%29/20489

angle_end2end_tests on NVIDIA GPU on Windows on Windows-10

failing PointSpritesTest.PointSizeAboveMaxIsClamped/ES2_VULKAN

CC'ing Kimmo from the NVIDIA driver team. I'll send out an email later on.

The OpenGL bug is NVIDIA bug number 1957867. (oetuaho mentioned this in comment 26). Unfortunately no real progress has been made on this. I'll try to move this forward.

The Vulkan bug is NVIDIA bug number 2446777.