oizma / angleproject Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/angleproject
License: Other
Automatically exported from code.google.com/p/angleproject
License: Other
Name: ANGLE URL: https://code.google.com/p/angleproject/ Version: 2422 License: BSD License File: LICENSE Description: ANGLE is a conformant implementation of the OpenGL ES 2.0 specification that is hardware‐accelerated via Direct3D.
Originally reported there:
https://bugzilla.mozilla.org/show_bug.cgi?id=601086
What steps will reproduce the problem?
1. Make sure ANGLE assertions are enabled (debug build).
2. Load attached testcase in a WebGL-enabled browser that uses ANGLE for shader
translation/validation.
What is the expected output? What do you see instead?
Expected: no crash (and the shader should be rejected as non-GLSL-ES compliant).
Actual: crash in ANGLE in TranslatorGLSL::compile() in TOutputGLSL::visitLoop.
What version of the product are you using? On what operating system?
Using ANGLE r385, Mozilla's copy (under gfx/angle/), on Windows 7.
Original issue reported on code.google.com by [email protected]
on 1 Oct 2010 at 7:35
Attachments:
What steps will reproduce the problem?
1. Execute function with following parameters
glTexImage2D(GL_TEXTURE_2D, 1, GL_RGBA, 2048, 2048, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
This will produce GL_INVALID_VALUE, because there is a check:
if (width > (gl::MAX_TEXTURE_SIZE >> level) || height > (gl::MAX_TEXTURE_SIZE >> level))
{
return error(GL_INVALID_VALUE);
}
inside src\libGLESv2\libGLESv2.cpp (4438)
What is the expected output? What do you see instead?
The OpenGL ES 2.0 documentation states:
"GL_INVALID_VALUE is generated if width or height is less than 0 or greater
than GL_MAX_TEXTURE_SIZE when target is GL_TEXTURE_2D or
GL_MAX_CUBE_MAP_TEXTURE_SIZE when target is not GL_TEXTURE_2D."
Nothing is mentioned that when specifying data for level = 1, the max width or
max height supposed to be (gl::MAX_TEXTURE_SIZE >> level)...
It doesn't matter for what level-of-detail you're specifying texture data, the
max width and max height stays the same.
So in short, GL_INVALID_VALUE should not be produced
What version of the product are you using? On what operating system?
Using rev 414
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 12:11
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about deprecated conversion from string constant to ‘char*’
What do you see instead?
gfx/angle/generated/glslang_tab.cpp:
4547: warning: deprecated conversion from string constant to ‘char*’
4690: warning: deprecated conversion from string constant to ‘char*’
What version of the product are you using?
Please provide any additional information below.
I believe that the safe/correct thing to do is to mark the parameter as const
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 1:09
Attachments:
In order to legally access the gl_PointCoord built-in variable in fragment
shaders, ANGLE must emit the version string "#version 120" in its GLSL backend.
It may be safer to emit this string conditionally, only if gl_PointCoord is
actually referenced in the fragment shader.
Original issue reported on code.google.com by [email protected]
on 16 Sep 2010 at 5:33
It will be nice from debugging point of view to preserve line numbers between
original and translated shader source.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 6:50
EXT_texture_formatBGRA8888 matches the D3D9 A8R8G8B8 format directly, and as
such texture upload and ReadPixels() can be made much faster, turning into a
simple memcpy. The attached patch implements this extension in ANGLE.
Original issue reported on code.google.com by [email protected]
on 31 Jul 2010 at 7:00
Attachments:
In Context::applyState, multisampling isn't turned on unless GL_SAMPLE_COVERAGE
is enabled. According to the GLES2 spec, enabling this only causes the
fragment's coverage value to be ANDed with the GL_SAMPLE_COVERAGE_VALUE.
Multisampling should be turned on regardless of this value, if the frame buffer
is multisampled.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 5:10
If I have a frame buffer with no depth render target attached, ANGLE doesn't
properly call SetDepthStencilSurface(NULL). This incorrectly leaves the
previous depth stencil buffer set.
This appears to be because markAllStateDirty resets the applied depth buffer
serial to 0, which also happens to be the signifier for "depth surface already
set to NULL".
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 4:51
For the following set of vertex and fragment shaders, ANGLE returns incorrect
attrib/uniform info:
VERTEX SHADER:
uniform vec4 uPosition[2];
void main() {
gl_Position = uPosition[0] + uPosition[1];
}
FRAGMENT SHADER:
precision mediump float;
struct FogParams {
vec4 color;
};
uniform FogParams fog[2];
void main() {
gl_FragColor = fog[0].color + fog[1].color;
}
ANGLE returns two uniforms:
1. name: uPosition size: 2
2. name: fog.color size: 1
What is the expected output? What do you see instead?
It should return three uniforms:
1. name: uPosition[0] size: 2
2. name: fog[0].color size: 1
3. name: fog[1].color size: 1
Original issue reported on code.google.com by [email protected]
on 20 Sep 2010 at 6:29
What steps will reproduce the problem?
1. How does this engine compare to Google's O3D?
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 20 Mar 2010 at 5:41
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about unused variable ‘ret’
What do you see instead?
glslang.cpp:
In function ‘int PaParseStrings(char**, int*, int, TParseContext&)’:
2683: warning: unused variable ‘ret’
What version of the product are you using?
On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1
Please provide any additional information below.
While 'out' is unused, it seems like yakk would appreciate the failure from
yyparse being propagated
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 12:53
Attachments:
What steps will reproduce the problem?
1. Add the line "precision highp float;" to a VERTEX shader.
2. Compile
What is the expected output?
It should not compile.
What do you see instead?
It compiles.
It's not 100% clear to me that it should not compile but the issue is the
statement makes it through to the GL driver and depending on the driver it
fails to compile.
Original issue reported on code.google.com by [email protected]
on 2 Aug 2010 at 5:22
OpenGL ES shading language does not support implicit conversions between types.
Shaders containg any of the following should fail:
float f = int(1);
bool b = int(1);
int i = float(1.0f);
bool b = float(1.0f);
int i = bool(1);
float f = bool(1);
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 6:45
For the following fragment shader:
FRAGMENT SHADER:
precision highp float;
varying vec2 v_texCoord;
uniform sampler2D diffuse;
void main() {
vec4 diffuse = texture2D(diffuse, v_texCoord);
gl_FragColor = diffuse;
}
TRANSLATED HLSL SHADER:
static float2 _v_texCoord = {0, 0};
static float4 gl_Color[1] = {float4(0, 0, 0, 0)};
uniform sampler2D _diffuse;
float4 gl_texture2D(sampler2D s, float2 t)
{
return tex2D(s, t);
}
void gl_main()
{
float4 _diffuse = gl_texture2D(_diffuse, _v_texCoord);
(gl_Color[0] = _diffuse);
}
The translated code fails to compile with this error message:
error X3017: 'gl_texture2D': cannot implicitly convert from 'float4' to
'sampler2D'
What is the expected output? What do you see instead?
I am not sure if the input shader is valid. It seems valid under the assumption
that assignment happens from right to left. So when rhs is evaluated _diffuse
has not be redefined yet - it is still a sampler2D. All the OpenGL drivers I
have tested accept the input shader as valid. Apparently HLSL has different
semantics.
If the input shader is valid, the translated HLSL shader should compile.
Original issue reported on code.google.com by [email protected]
on 20 Sep 2010 at 6:56
What steps will reproduce the problem?
1. Run the WebGL conformance test for uniforms
file:///C:/src/khronos/webgl/sdk/tests/conformance/gl-get-active-uniform.html
What is the expected output? What do you see instead?
The types returned for sampler2D and samplerCube should be GL_SAMPLER_2D and
GL_SAMPLER_CUBE. ANGLE returns GL_INT
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 10:05
What steps will reproduce the problem?
1. Attempt to compile the shader below on OSX
What is the expected output?
It should compile
What do you see instead?
It gets an error at line 45
The issue is some parens have been moved in such a way to change precedence.
This line:
result +=
clamp((hand_radius_2 - length_2(Z - r_h)) / threshold, 0.0, 1.0) *
(Z.y < r_h.y ? 1.0 : 0.0) * right_hand_color +
clamp((hand_radius_2 - length_2(Z - l_h)) / threshold, 0.0, 1.0) *
(Z.y < l_h.y ? 1.0 : 0.0) * left_hand_color;
Is translated to this
(result +=
(
(
(clamp
(
(
(hand_radius_2 - length_2
(
(Z - r_h)
)
) / threshold
), 0.0, 1.0
) *
(
(Z[1] < r_h[1])
) ? (1.0) : (0.0)
) * right_hand_color
) +
(
(clamp
(
(
(hand_radius_2 - length_2
(
(Z - l_h)
)
) / threshold
), 0.0, 1.0
) *
(
(Z[1] < l_h[1])
) ? (1.0) : (0.0)
) * left_hand_color
)
)
);
Notice that the ternary parts have changed precedence.
Here's the entire shader:
---------------------------------------
precision highp float;
varying vec2 v_texCoord;
uniform float theta;
uniform float num;
float length_2(vec2 v) {
return dot(v, v);
}
// Draw the balls in a single arc.
// Returns 1 if the pixel is within a ball, 0 if it isn't, and a value in
// between for pixels right on the edge, for antialiasing.
float drawBallsInArc(float pi,
vec4 offset,
vec2 source_hand,
vec2 dest_hand,
float height_factor,
float baseline,
float ball_radius_2,
float hand_throw_offset,
vec2 Z,
float threshold) {
// Map theta from its current range of [0, 2 * num * pi) onto [0, (num - 1))
// by scaling, adding offset, and modding, then map that to [0, 1) by scaling.
// The first mapping tells us where in the repeating cycle we are, and the
// second mapping simplifies the calculation of the parabola.
// The vector offset is used to distinguish between balls in the same arc, but
// out of phase. At the beginning of this function, all the operations are
// vectorized to save instructions; we get to calculate 4 ball positions for
// the price of 1.
// The reason for the (num - 1) in the expression below is that with num
// balls, each ball spends (num - 1) beats in the air, then one in the hand.
// So (num - 1) is the length of time a parabola takes.
vec4 time = mod(theta / pi + offset, (num - 1.0)) / (num - 1.0);
float dx = dest_hand.x - source_hand.x;
vec4 x = time * dx + source_hand.x - hand_throw_offset;
vec4 y = time * (1.0 - time);
y = y * height_factor + baseline;
vec4 ZX = vec4(Z.x);
vec4 ZY = vec4(Z.y);
vec4 len_2 = (ZX - x) * (ZX - x) + (ZY - y) * (ZY - y);
// This antialiasing fuzzes the balls just a bit larger than they would
// otherwise be.
vec4 temp = clamp((len_2 - ball_radius_2) / threshold, 0.0, 1.0);
// One minus the product of all entries in temp.
temp.xy = temp.xy * temp.zw;
return 1.0 - temp.x * temp.y;
}
vec4 drawAirborneBalls(float pi,
vec4 offset,
vec2 right_hand,
vec2 left_hand,
float height_factor,
float baseline,
float ball_radius_2,
float hand_swing_radius,
vec2 Z,
float threshold) {
float value =
// balls going right to left
(drawBallsInArc(pi, offset, right_hand, left_hand, height_factor,
baseline, ball_radius_2, hand_swing_radius, Z, threshold) +
// balls going left to right
drawBallsInArc(pi, offset + 1.0, left_hand, right_hand, height_factor,
baseline, ball_radius_2, -hand_swing_radius, Z, threshold));
return vec4(value, value, value, value);
}
/**
* pixelShaderMain - pixel shader
*/
void main() {
float pi = 3.14159265;
float baseline = -1.4;
vec2 right_hand = vec2(0.8, baseline);
vec2 left_hand = vec2(-0.8, baseline);
float hand_swing_radius = 0.25;
float hand_radius = 0.15;
float hand_radius_2 = hand_radius * hand_radius;
float ball_radius = 0.08;
float ball_radius_2 = ball_radius * ball_radius;
vec4 right_hand_color = vec4(1, 0, 0, 1);
vec4 left_hand_color = vec4(0, 0, 1, 1);
vec4 background_color = vec4(0, 0, 0, 0);
float threshold = 0.002; // Used in clamp for antialiasing.
float height_factor = num * 0.75;
vec2 Z = v_texCoord;
// Coerce to the range [0, 2 * Pi * num].
vec2 r_h = hand_swing_radius * vec2(-cos(theta), sin(theta)) + right_hand;
vec2 l_h = hand_swing_radius * vec2(-cos(theta), -sin(theta)) + left_hand;
// Initialize color of pixel to background_color. Background color has an
// alpha of 0. Color of objects each have alpha 1, so multiplying by
// (1-alpha) before adding the color ensures that nothing gets overdrawn.
// It's kind of like a rudimentary z-buffer.
vec4 result = background_color;
// Draw the hands. The antialiasing here fuzzes the hands just a little bit
// smaller than they would otherwise be. That's the opposite of what we do
// for the balls, just because it happens to be cheaper here to do smaller and
// cheaper in drawBallsInArc to do larger.
float temp = (Z.y < r_h.y ? 1.0 : 0.0); // TODO(luchen): figure out why ternary fails
float temp2 = (Z.y < l_h.y ? 1.0 : 0.0);
result +=
clamp((hand_radius_2 - length_2(Z - r_h)) / threshold, 0.0, 1.0) *
(Z.y < r_h.y ? 1.0 : 0.0) * right_hand_color +
clamp((hand_radius_2 - length_2(Z - l_h)) / threshold, 0.0, 1.0) *
(Z.y < l_h.y ? 1.0 : 0.0) * left_hand_color;
// Draw the ball in the hand. There is always a ball in exactly one hand, and
// which hand that is alternates.
vec2 hand;
if (mod(floor(theta / pi), 2.0) > 0.5) {
hand = r_h;
} else {
hand = l_h;
}
// The antialiasing here fuzzes the balls just a bit bigger than they would
// otherwise be. This is more work than making them smaller [the extra
// subtraction in the "1 - clamp..." below], but inverting it in
// drawBallsInArc would be more expensive, and they have to match so that the
// balls are all the same size.
result += (1.0 - result.a) *
(1.0 - clamp((length_2(Z - hand) - ball_radius_2) / threshold, 0.0, 1.0));
// Draw airborne balls.
vec4 offset = vec4(0, 2, 4, 6);
result += (1.0 - result.a) * drawAirborneBalls(pi,
offset,
right_hand,
left_hand,
height_factor,
baseline,
ball_radius_2,
hand_swing_radius,
Z,
threshold);
// For each up-to-4 pairs of balls you want to add, increment offset by
// (8, 8, 8, 8) and call drawAirborneBalls again.
offset += 8.0;
result += (1.0 - result.a) * drawAirborneBalls(pi,
offset,
right_hand,
left_hand,
height_factor,
baseline,
ball_radius_2,
hand_swing_radius,
Z,
threshold);
gl_FragColor = result;
}
Original issue reported on code.google.com by [email protected]
on 22 Jul 2010 at 9:25
http://codereview.appspot.com/1301041 introduced a bug where the removal of
extraneous semicolons is too aggressive. This is causing failures in the OpenGL
ES 2.0 conformance tests.
The shader fragment which seems to be translated incorrectly is
(j>k)?( result1 = true ):( result1 = false );
(y<n)?( result2 = true ):( result2 = false );
And from recollection this is being translated to
(j>k)?( result1 = true ):( result1 = false )(y<n)?( result2 = true ):( result2 = false );
The name of the failing test is "selection_frag_test".
Original issue reported on code.google.com by [email protected]
on 7 Jun 2010 at 11:13
The WebGL 1.0 specification states that the minimum requirements for control
flow and indexing (sections 4 and 5 of Appendix A of the GLSL ES specification)
are enforced. For example, the upper bound of the loop must be a constant
expression (it can not involve the value of a uniform variable), and indexing
of uniform arrays in fragment shaders must only allow
constant-index-expressions (i.e., no expressions involving uniform or varying
values).
An option is needed in the ANGLE shader translator to strictly enforce these
minimum requirements. This could be folded into the existing WebGL language
support, or exposed as another capability.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2010 at 5:59
What steps will reproduce the problem?
1. Vertex shader program where texture2D function is used.
What is the expected output? What do you see instead?
Actually I'd expect that desktop OpenGL would be used in Chrome by default.
When linking the code, I get
error X3004: undeclared identifier 'gl_Texture2D'
I think there should be a better error message, or if possible
gl_Texture2D should be defined for vertex shaders (requires
shader model 3?).
What version of the product are you using? On what operating system?
Chrome Canary Build 7.0.521.0
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 13 Sep 2010 at 12:16
We have recently started using an OpenGL type interface which makes it
inconsistent with the older API. Due to inter-dependencies between ANGLE,
webkit, and chromium there is a desire to keep the API fairly stable.
Make the API consistent so that there are fewer chances of making changes in
the future.
Original issue reported on code.google.com by [email protected]
on 27 Sep 2010 at 8:54
A shader used by http://www.nihilogic.dk/labs/webgl_musical_solar_system/
crashes in ShCompileShader, due to a null deref. The shader source seems to be:
#version 120
attribute vec3 aVertex;
uniform mat4 uModelViewMatrix;
uniform mat4 uProjMatrix;
uniform float uTime;
uniform float uMusicNoise;
uniform float uEqData[16];
uniform float uEqNormData[16];
varying vec3 vPosition;
void Transform() {
vec3 nv = vec3(aVertex.xy * 1.5 + uTime * 0.0005, 0) + uTime * 0.0005;
float y = clamp((aVertex.y * 0.5) + 0.5, 0.0, 1.0);
// int l = int(round(15.0 * y));
int l = int(floor(15.0 * y));
float n = uEqNormData[l] * sqrt(uEqData[15-l]);
vec3 pos = aVertex;
pos.xz *= 1.0 + n * 0.15 * uMusicNoise;
vPosition = pos;
gl_Position = uProjMatrix * uModelViewMatrix * vec4(pos, 1.0);
}
Original issue reported on code.google.com by [email protected]
on 14 Aug 2010 at 7:46
Hi, this is forwarded from https://bugzilla.mozilla.org/show_bug.cgi?id=597946
Steps:
1. Launch Firefox 4 on any platform EXCEPT Linux 64bit. Check in about:config
that webgl.enabled_for_all_sites and that webgl.shader_validator are true.
2. Go to http://gyu.que.jp/private/badshader.html
Expected: A messagebox prints the Shader InfoLog.
Actual: Graphics driver crashes (confirmed here on Windows/NVIDIA and by the
original reported on a Mac).
Disabling the ANGLE translator/validator in Firefox makes this issue disappear.
This is using the copy of ANGLE that we have in Mozilla-central. Let me know if
you think that it's worth updating it.
Original issue reported on code.google.com by [email protected]
on 20 Sep 2010 at 1:01
Shader compiler code is hard-coded to only support ESSL to HLSL conversion.
We should break it down into FrontEnd and multiple BackEnd modules.
Original issue reported on code.google.com by [email protected]
on 10 Mar 2010 at 4:32
Assembly code in src/compiler/preprocessor/scanner.c is MSC-specific, but
protected by _WIN32 guard, causing problems with compilation on mingw. The
attached patch fixes the problem.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2010 at 12:02
Attachments:
const char* ShGetInfoLog(const ShHandle);
const char* ShGetObjectCode(const ShHandle);
These functions return null-terminated strings which can be exploited by a
compromised process. Change the interface to be more like OpenGL shader
functions:
enum ShCompilerInfo {
SH_COMPILE_STATUS,
SH_INFO_LOG_LENGTH,
SH_DEBUG_LOG_LENGTH,
SH_OBJECT_CODE_LENGTH,
}
int ShGetCompilerInfo(ShHandle compiler, ShCompilerInfo param);
void ShGetCompilerInfoLog(ShHandle compiler, int maxLength, int* length, char*
infoLog);
void ShGetCompilerDebugLog(ShHandle compiler, int maxLength, int* length, char*
debugLog);
void ShGetCompilerObjectCode(ShHandle compiler, int maxLength, int* length,
char* objectCode);
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 7:09
What steps will reproduce the problem?
1.compile angle trunk code with SunStudio 12
What is the expected output? What do you see instead?
Expected:
Intermediate.cpp should be compiled with SunStudio 12.
But actually, it doesn't
What version of the product are you using? On what operating system?
I saw this problem when building firefox trunk code.
I use OpenSolaris build 142.
The attachment is a patch.
Original issue reported on code.google.com by [email protected]
on 21 Jul 2010 at 2:02
Attachments:
This was with the Canary 7.0.530.0 Chrome build. Call stack from an XP box:
Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000052 )
0x00000052
0x014551b3 [libGLESv2.dll - context.cpp:2373] gl::Context::clear(unsigned
int)
0x01445f41 [libGLESv2.dll - libglesv2.cpp:611] glClear
0x01c521e9 [chrome.dll - gles2_cmd_decoder.cc:2220]
gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x01c4fbb9 [chrome.dll - cmd_parser.cc:56]
gpu::CommandParser::ProcessCommand()
0x01c4f9fb [chrome.dll - gpu_processor.cc:104]
gpu::GPUProcessor::ProcessCommands()
0x01ed42fe [chrome.dll - callback.h:119]
CallbackImpl<SafeBrowsingStoreFile,void (
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x01c4f3dd [chrome.dll - callback.h:79] CallbackRunner<Tuple0>::Run()
0x01c4eec8 [chrome.dll - command_buffer_service.cc:90]
gpu::CommandBufferService::Flush(int)
0x01d6e774 [chrome.dll - gpu_command_buffer_stub.cc:129]
GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)
Another example from a Win 7 box:
Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_EXEC @ 0x4dff00b6 )
0x4dff00b6
0x6b6651b3 [libGLESv2.dll - context.cpp:2373] gl::Context::clear(unsigned
int)
0x6b655f41 [libGLESv2.dll - libglesv2.cpp:611] glClear
0x657c21e9 [chrome.dll - gles2_cmd_decoder.cc:2220]
gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x657bfbb9 [chrome.dll - cmd_parser.cc:56]
gpu::CommandParser::ProcessCommand()
0x657bf9fb [chrome.dll - gpu_processor.cc:104]
gpu::GPUProcessor::ProcessCommands()
0x65a442fe [chrome.dll - callback.h:119]
CallbackImpl<SafeBrowsingStoreFile,void (
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x657bf3dd [chrome.dll - callback.h:79] CallbackRunner<Tuple0>::Run()
0x657beec8 [chrome.dll - command_buffer_service.cc:90]
gpu::CommandBufferService::Flush(int)
0x658de774 [chrome.dll - gpu_command_buffer_stub.cc:129]
GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)
One more Windows 7 box:
Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_EXEC @ 0xfffffffffc4d8b66 )
0xfc4d8b66
0x6eef51b3 [libGLESv2.dll - context.cpp:2373] gl::Context::clear(unsigned
int)
0x6eee5f41 [libGLESv2.dll - libglesv2.cpp:611] glClear
0x657c21e9 [chrome.dll - gles2_cmd_decoder.cc:2220]
gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x657bfbb9 [chrome.dll - cmd_parser.cc:56]
gpu::CommandParser::ProcessCommand()
0x657bf9fb [chrome.dll - gpu_processor.cc:104]
gpu::GPUProcessor::ProcessCommands()
0x65a442fe [chrome.dll - callback.h:119]
CallbackImpl<SafeBrowsingStoreFile,void (
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x657bf3dd [chrome.dll - callback.h:79] CallbackRunner<Tuple0>::Run()
0x657beec8 [chrome.dll - command_buffer_service.cc:90]
gpu::CommandBufferService::Flush(int)
0x658de774 [chrome.dll - gpu_command_buffer_stub.cc:129]
GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)
Original issue reported on code.google.com by [email protected]
on 22 Sep 2010 at 9:37
Add capability to validate WebGL shaders. Specifically reject shaders with
_webgl and _webgl_ identifiers. WebGL capability should be behind an optional
flag because ANGLE provides GLES2 implementation.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2010 at 4:42
Appendix A, section 5 of the GLSL ES specification states that arbitrary
indexing of uniform arrays in vertex shaders is mandated. This is specifically
to support skinning, where matrix indices come in to the shader via vertex
attributes.
At least for WebGL implementations, and likely for other client libraries using
the shader translator, an option is needed to guarantee that these indexing
operations will not go outside the region of the array.
This can be trivially achieved by injecting clamp instructions around the index
when the index expression references attributes or uniform values. For indexing
expressions involving only constants or loop indices, it can be determined at
compile time whether the expression can go out of range, and it should always
be an error to compile such shaders.
Ideally, the shader translator would be able to provide information to the
caller about the range of legal values for vertex attributes that are used in
indexing expressions. For example, a shader like
attribute int index;
uniform vec4 positions[4];
void main() {
gl_Position = positions[index];
}
would report that the legal range for the "index" attribute is [0..3]. If the
indexing expression were instead "positions[2*index]", the legal range would be
[0..1]. Since WebGL and other libraries using the shader translator tend to
need to know the maximum value in buffers anyway, these libraries could decide
whether a "safe" version of the shader with the injected clamp instructions
must be used, or whether the unmodified shader could be used for higher
performance.
The reporting of legal ranges for attributes can be fixed in a separate issue
as it will likely involve significantly more engineering. Optional injection of
clamp instructions for the appropriate indexing expressions is the most
immediate need.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2010 at 6:18
I need to pass this through to client programs.
I need to know what it implements. What are the differences between
GL_EXT_framebuffer_multisample and GL_ANGLE_framebuffer_multisample?
If there's some docs somewhere just point me to them. Thanks.
Original issue reported on code.google.com by [email protected]
on 23 Sep 2010 at 10:37
What steps will reproduce the problem?
1. Make a shader something like this
float foo(float a, float b) {
return a * b;
}
void main () {
float foo = 1.0;
float a = 2.0;
float b = 3.0;
float bar = foo(a, b);
..
}
2. Compile it
What is the expected output?
Either (a) I should get an error for foo exiting twice or (b) the function call
to "foo" should fail because at that scope, "foo" is not a function.
What do you see instead?
The code passes the validator.
Original issue reported on code.google.com by [email protected]
on 2 Aug 2010 at 5:20
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about deprecated conversion from string constant to ‘char*’
What do you see instead?
gfx/angle/generated/glslang_tab.cpp:
4547: warning: deprecated conversion from string constant to ‘char*’
4690: warning: deprecated conversion from string constant to ‘char*’
What version of the product are you using?
Please provide any additional information below.
I believe that the safe/correct thing to do is to mark the parameter as const
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 1:08
Attachments:
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about signedness while compiling
What do you see instead?
gfx/angle/src/compiler/preprocessor/atom.c:
In function ‘InitAtomTable’:
664: warning: comparison between signed and unsigned
gfx/angle/src/compiler/preprocessor/symbols.c:
In function ‘NewSymbol’:
gfx/angle/src/compiler/preprocessor/symbols.c:
173: warning: comparison between signed and unsigned
gfx/angle/src/compiler/preprocessor/tokens.c:
In function ‘RecordToken’:
230: warning: pointer targets in assignment differ in signedness
What version of the product are you using?
On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 12:19
Attachments:
It appears that some expressions are being incorrectly parenthesized in the
GLSL backend, which is leading to failures in the OpenGL ES 2.0 conformance
tests.
One such expression being incorrectly translated is:
if( (setval+=11) == 40)
which is translated as
if ((setval += 11 == 40))
It is unclear whether this is the reason for this conformance test failure, but
it appears likely.
Original issue reported on code.google.com by [email protected]
on 7 Jun 2010 at 11:23
What steps will reproduce the problem?
1. Execute glTexImage2D (GL_TEXTURE_2D, 12, GL_RGBA, 2048, 2048, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL);
2. Crash
What is the expected output? What do you see instead?
GL_INVALID_VALUE is expected, but instead the library crashes.
According to OpenGL ES 2.0 documentation:
"GL_INVALID_VALUE may be generated if level is greater than log 2 max ,
where max is the returned value of GL_MAX_TEXTURE_SIZE when target is
GL_TEXTURE_2D or GL_MAX_CUBE_MAP_TEXTURE_SIZE when target is not GL_TEXTURE_2D."
So in this case max possible level value is 11
I saw that there are checks like level > gl::MAX_TEXTURE_LEVELS in
src\libGLESv2\libGLESv2.cpp, though it should be
level >= gl::MAX_TEXTURE_LEVELS instead
But there's no check in glTexImage2D function
What version of the product are you using? On what operating system?
Using rev 414
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 12:38
1) StretchRect type checks are more strict than the DX9 docs specify. Right
now, only Colorbuffer objects with the exact same type can be blitted, but
according to the docs, render texture and render buffers can always be blitted
to each other.
2) The blit function checks for color format equivalence, but doesn't set the
format on the proxy Colorbuffer for the render texture. This also makes it
impossible to resolve from a render target to a render texture.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 5:07
What steps will reproduce the problem?
1.In windows, open Chrome (top-of-tree), and goto
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/object-deletion-behaviour.html, see the test failing.
2. If open Chrome with --use-gl=desktop flag, the test passes.
3.
What is the expected output? What do you see instead?
If a shader is attached to a program, or a program is the current bound one,
deleteShader() or deleteProgram() should only mark the name as deleted, but the
true deletion will be delayed.
However, current ANGLE implementation delete shader/program immediately upon
deleteShader() or deleteProgram().
What version of the product are you using? On what operating system?
Top of tree chrome, in Windows Vista.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 28 Sep 2010 at 2:57
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about bar will be initialized after foo
What do you see instead?
gfx/angle/src/compiler/PoolAlloc.h:
In constructor ‘TPoolAllocator::tHeader::tHeader(TPoolAllocator::tHeader*, size_t)’:
176: warning: ‘TPoolAllocator::tHeader::lastAllocation’ will be initialized
after
173: warning: ‘TPoolAllocator::tHeader* TPoolAllocator::tHeader::nextPage’
gfx/angle/src/compiler/PoolAlloc.h:159: warning: when initialized here
gfx/angle/src/compiler/parseConst.cpp:
In constructor ‘TConstTraverser::TConstTraverser(ConstantUnion*, bool, TOperator, TInfoSink&, TSymbolTable&, TType&)’:
39: warning: ‘TConstTraverser::symbolTable’ will be initialized after
21: warning: ‘bool TConstTraverser::error’
15: warning: when initialized here
What version of the product are you using?
On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 12:42
Attachments:
Add a version number for shader translator library so that a client application
can target multiple versions.
The version number will be updated whenever the shader translator API changes.
The shader library would not be expected to be backward compatible however. It
is just to help client applications upgrade to the newer version in stages.
Original issue reported on code.google.com by [email protected]
on 27 Sep 2010 at 8:51
What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7
What is the expected output?
no warnings about unused variable ‘out’
What do you see instead?
gfx/angle/src/compiler/OutputGLSL.cpp:
In member function ‘virtual bool TOutputGLSL::visitUnary(Visit, TIntermUnary*)’:
307: warning: unused variable ‘out’
In member function ‘virtual bool TOutputGLSL::visitBranch(Visit, TIntermBranch*)’:
649: warning: unused variable ‘out’
What version of the product are you using?
On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 Jul 2010 at 12:47
Attachments:
Add documentation on how to get and use source for GLSL ES to GLSL translator.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 8:33
Implement a GLSL backend for translating ESSL to GLSL
Original issue reported on code.google.com by [email protected]
on 10 Mar 2010 at 4:34
Remove unsupported functions from ShaderLang.h so that it is easier to
understand.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 7:10
What steps will reproduce the problem?
1. Write a simple shader which has uniforms of type sampler2D or samplerCUBE
2. Compile the shader
3. When executing function glGetActiveUniform (GLuint program, GLuint index,
GLsizei bufsize, GLsizei* length, GLint* size, GLenum* type, GLchar* name);
The type for specified uniforms will be GL_INT, which is incorrect.
What is the expected output? What do you see instead?
The type for specified uniforms should be GL_SAMPLER_2D or GL_SAMPLER_CUBE accordingly
What version of the product are you using? On what operating system?
I'm using Angle project with revision 414
Please provide any additional information below.
Attached modified Simple_VertexShader project
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 10:48
Attachments:
For a compiled shader, provide the following information about attribs and
uniforms:
1. name
2. type
3. size
Original issue reported on code.google.com by [email protected]
on 23 Aug 2010 at 7:21
What steps will reproduce the problem?
1. Set locale to something that uses a decimal comma, e.g. French
2. Use non-integer float literals like 0.4 and 1.8 in a shader
What is the expected output? What do you see instead?
Expected output is for 0.4 to parse as 0.4, but it is parsed as 0.0. 1.8 is
parsed as 1.0.
What version of the product are you using? On what operating system?
The version in Firefox Minefield nightly 2010-9-11, Windows 7.
Please provide any additional information below.
The reason for the misparsing of floats is that the lexer seems to be using
atof for string-to-float conversions and atof uses the current locale to
determine the radix character.
http://code.google.com/p/angleproject/source/browse/trunk/src/compiler/glslang.l
#178
Original issue reported on code.google.com by [email protected]
on 11 Sep 2010 at 5:08
On hardware that is capable of supporting derivative instructions (supplied via
the OES_standard_derivatives extension), we need ANGLE to accept the dFdx and
dFdy instructions.
Original issue reported on code.google.com by [email protected]
on 19 Aug 2010 at 5:27
What steps will reproduce the problem?
1. Run the WebGL glClear conformance test using ANGLE
What is the expected output? What do you see instead?
The test should pass. It doesn't. It does pass in OpenGL
Note, this is a semi follow up to this issue
http://code.google.com/p/angleproject/issues/detail?id=31
This is the cause of why some of the demos are brighter in ANGLE than in
OpenGL. At the end of the frame of nearly all the demos I do this
// Set the alpha to 255.
gl.colorMask(false, false, false, true);
gl.clearColor(0,0,0,1);
gl.clear(gl.COLOR_BUFFER_BIT);
But based on certain state which so far I haven't been able to figure out ANGLE
doesn't clear to 255. I've stepped through their code in the debugger and I see
that when colorMask is not (true,true,true,true) ANGLE draws a quad with the
D3D Fixed Function Pipeline instead of calling Clear(). I can't tell why it's
not clearing correctly though.
I've run ANGLE in PIX and I see where the clear happens. I see the vertices
have the correct color and I also see what PIX calls the pixel shader is
producing the bad color (even though there isn't a pixel shader. Then again,
maybe there is internally)
In the aquarium it ends up clearing to 147 which means the entire scene gets
composited with the canvas background color which is grey. If you set the
canvas's background color to RED then you really see the bug.
To verify I added these 3 lines to the demo
var buf = new Uint8Array(4);
gl.readPixels(0, 0, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, buf);
tdl.log(buf[3]);
And it prints 147.
Anyway, I tried to write a gl.clear WebGL conformance test and found more bugs
apparently.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/gl-clear.html
Here's the results of the test in OpenGL
Test clear.
On success, you will see a series of "PASS" messages, followed by "TEST
COMPLETE".
PASS getError was expected value: NO_ERROR : Should be no errors from setup.
PASS should be 0,0,0,0
PASS should be 255,255,255,255
PASS should be 0,0,0,0
PASS should be 0,0,0,255
PASS should be 128,128,128,192
PASS should be 128,128,128,255
PASS successfullyParsed is true
TEST COMPLETE
And on ANGLE
Test clear.
On success, you will see a series of "PASS" messages, followed by "TEST
COMPLETE".
PASS getError was expected value: NO_ERROR : Should be no errors from setup.
FAIL should be 0,0,0,0
expected: 0,0,0,0 was 0,0,0,128
PASS should be 255,255,255,255
PASS should be 0,0,0,0
FAIL should be 0,0,0,255
expected: 0,0,0,255 was 0,0,0,128
PASS should be 128,128,128,192
FAIL should be 128,128,128,255
expected: 128,128,128,255 was 128,128,128,192
PASS successfullyParsed is true
TEST COMPLETE
I notice that the initial alpha color is whatever was left over from the last
call to clear in a previous program. That suggests something.
Original issue reported on code.google.com by [email protected]
on 16 Sep 2010 at 1:49
What steps will reproduce the problem?
1. Run any OpenGL program with OpenGL
2. Run the same program with ANGLE
What is the expected output?
The colors should be the same
What do you see instead?
The colors on the ANGLE program are much brighter.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 1:34
resetInfoLog doesn't null out mInfoLog, leading to crashes in Program::validate
if appendToInfoLog is called when there was a previous info log. (That's not
the most clear explanation; basically there's a double-free going on.)
Simple patch is attached, against r405. (WebGL test suite caught this, debug
win32 build.)
Original issue reported on code.google.com by [email protected]
on 30 Aug 2010 at 11:46
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.