[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Minefield brings system to halt - ANGLE problems



Am 21.09.2010 17:23, schrieb Benoit Jacob:
----- Original Message -----
Hi Benoit,

thank you for your fast response.

Am 21.09.2010 16:30, schrieb Benoit Jacob:
Another thing that's worth trying is setting webgl.shader_validator
to false, to see if it's an issue with our ANGLE copy or the way
that we're using it.

I first started testing in Firefox Beta: when disabling the shader validator both mentioned demos (the shadows and the cube map/ multi-texture shader) both work again as expected :-) (though the console still tells s.th. about "been bound to a different target").

This really hints to an ANGLE problem, because I then double checked
my
Chromium settings and remembered that there I have had to activate the
"--use-gl=desktop" flag to make it work (Chrome Beta is ok without)...

Ah! Very interesting.

I would like to report to ANGLE but this is quite nontrivial as we would probably need a small testcase. If we could bisect it to a precise shader, that would probably help!

Alternatively, there's a good hope that some ANGLE devs are reading this list anyway ... ;-)

Then let's hope - therefore I've added an additional "ANGLE problems" to the subject ;-)




Concerning NeedFakeVertexAttrib0() I'd assume that this check is simply too vague,

Well the check that results in the error message is in the part of the code that I elided. There are still questions that could not be easily explained by a bug there: - why does the VBO have no data when drawElements is called? Is it a race condition in loading resources, as was suspected last week on this list about the Caves demo? - why does drawElements get called to draw only 1 vertex?

For the latter point, the helper code is the best explanation.
However, I've just added a dbg msg in the JS code after calling
getActiveAttrib() and getAttribLocation() for the shader (based on these attribute names, the VBOs are then created for the respective vertex attributes), but the vertex positions have the location 0.
Perhaps the flag mAttribBuffers[0].enabled is simply set too early?


Cheers
Yvonne


Cheers, Benoit

since there hasn't been any problem with rendering before,
at
least on those machines with a fairly good GPU -- even in the case
attribute 0 wasn't set (what I admittedly don't know because I haven't
checked it as we dynamically assign the locations based on the name of
the respective attribute in the shader via getAttribLocation).

Cheers
Yvonne


-- Yvonne Jung Fraunhofer-IGD | Tel.: ++49-6151-155-290 Fraunhoferstr. 5 | Fax.: ++49-6151-155-196 64283 Darmstadt | email: yvonne.jung@igd.fraunhofer.de Germany | http://www.igd.fhg.de/igd-a4


--
Yvonne Jung
Fraunhofer-IGD    | Tel.: ++49-6151-155-290
Fraunhoferstr. 5  | Fax.: ++49-6151-155-196
64283 Darmstadt   | email: yvonne.jung@igd.fraunhofer.de
Germany           | http://www.igd.fhg.de/igd-a4
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: