Closed GoogleCodeExporter closed 9 years ago
Please test again with a recent revision. There have been some significant
changes to the geometry management code.
It looks like these artifacts might be caused by the lack of support for 32-bit
indices by the hardware. Previously we faked support for it in ANGLE, but that
code was untested. The latest code won't expose support for 32-bit indices
unless supported by the hardware.
Note that this might mean it doesn't render at all now... The application would
have to use 16-bit indices if this is the case.
Original comment by nicolas....@gmail.com
on 20 Jan 2011 at 7:57
I don't see how that's possible. OpenGL ES 2.0 does not support 32bit indices
and our emulation of it has never supported 32bit indices.
Original comment by g...@google.com
on 20 Jan 2011 at 6:48
Core OpenGL ES 2.0 doesn't support 32-bit indices, but it has been exposed as
the GL_OES_element_index_uint extension for a very long time now. So I believe
some WebGL samples do use 32-bit indices.
Original comment by nicolas....@gmail.com
on 28 Feb 2011 at 3:38
Nicolas: yes it's available as an extension for GLES2, but I don't think that
extension has been exposed via WebGL yet. Until that's done it shouldn't be
possible for a webgl app to pass in 32-bit indices.
Original comment by dan...@transgaming.com
on 28 Feb 2011 at 6:23
Correct, GL_OES_element_index_uint has not been exposed in WebGL, and as it
isn't supported on any iOS hardware to date there are no current plans to
expose it.
Original comment by kbr@chromium.org
on 28 Feb 2011 at 6:58
This demo does not and never has used 32 bit indies. WebGL doesn't even support
32 bit indices.
It still gets on same results on Chrome 14.0.835.186 m
Original comment by g...@google.com
on 22 Sep 2011 at 7:43
The artifact goes away when toggling off 'fog' in the controls on the left. The
fog calculations essentially consist of clamp(pow(z / w, 14.5), 0, 1), in the
fragment shader. Unfortunately the GMA 950 can't handle a large range of
floating-point values in the pixel shader, which leads me to believe it
overflows/underflows seemingly randomly and this causes some triangles to have
maximum fog while others have none (with a 'reset' happening between
triangles). This is just speculation, but in any case it seems doubtful that
it's an ANGLE bug causing this. The GMA 950 definitely has severe hardware
limitations and driver stability issues.
That said, glGetShaderPrecisionFormat currently reports full 32-bit
floating-point precision, since there is no way to tell what the supported
precision is for Shader Model 2.0 hardware through Direct3D 9 (Shader Model 3.0
has to support 32-bit precision). We could report the lowest known precision
for Shader Model 2.0 hardware, but that won't automatically fix the actual
WebGL application of course. Any thoughts on changing
glGetShaderPrecisionFormat?
Note that with Chrome the GMA 950 is actually blacklisted and it falls back to
SwiftShader, which renders things at the same performance (on a Core Duo 1.66
GHz), but flawlessly.
Original comment by nicolas....@gmail.com
on 4 Jun 2012 at 6:50
I don't think it's worth changing the results of glGetShaderPrecisionFormat --
as you mention, doing so won't actually solve anything.
Blacklisting this GPU and falling back to SwiftShader sounds like the best
workaround.
Original comment by kbr@chromium.org
on 4 Jun 2012 at 7:12
Closing as wont fix since it already appears to be blacklisted.
Original comment by dan...@transgaming.com
on 5 Jun 2012 at 6:01
Original issue reported on code.google.com by
g...@chromium.org
on 14 Jan 2011 at 7:39Attachments: