-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WebGL] Fix Vao usage for parallel compile feature #7587
Conversation
The problem is caused by #6913, which is trying to bind VAO before each webgl program execution. I think the idea makes sense, even though TFJS's vertex shaders are same, because users may use the same canvas and write their own webgl program with different vertex shaders. |
@@ -1277,6 +1277,7 @@ export class MathBackendWebGL extends KernelBackend { | |||
|
|||
getUniformLocations() { | |||
for (const binary of Object.values(this.binaryCache)) { | |||
this.gpgpu.buildVao(binary.webGLProgram); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not make sense to add this code within getUniformLocations
and theoratically we should move it to a new function, like 'setVao'. However, since we have told some users to use this to utilize parallel compilation feature, making setVao
and requiring users to call it are breaking change for them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can you add a TODO here explaining this? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for fixing the issue!
@@ -253,6 +254,7 @@ export function runProgram<T extends Tensor, K extends Tensor>( | |||
outTex.texture, outTexShape[0], outTexShape[1]); | |||
} | |||
gpgpu.setProgram(binary.webGLProgram); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this two line be the same as just call gpgpu.buildVao(binary.webGLProgram)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IICU, buildVao
is to initialize VAO, while here it is using initialized VAO. Specifically, VAO initialization has to bind all attributes, while using initialized VAO does not need to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a nit.
@@ -1277,6 +1277,7 @@ export class MathBackendWebGL extends KernelBackend { | |||
|
|||
getUniformLocations() { | |||
for (const binary of Object.values(this.binaryCache)) { | |||
this.gpgpu.buildVao(binary.webGLProgram); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can you add a TODO here explaining this? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for adding the TODO.
For #7577
Problem
If we create VAO for each webgl program, then we have to set VAO for each program and bind it before execution. Right now, setting VAO happens in
createProgram
andcreateProgram
is involved in compilation stage. However, setting VAO has blocking-callgetAttribLocation
, so setting VAO should be called after compilation stage.This should work similar as what we do for
getUniformLocations
. We movedgetUniformLocations
call out ofcreateProgram
/compilation-stage, because it has blocking-call.Evaluation
before #6913 is merged (tfjs 4.0.0)
checkCompileCompletion
takes the majority time for warm up.after #6913 is merged (tfjs 4.1.0)
checkCompileCompletion
takes the trivial time for warm up.getAttribLocation
is blocking in the compilation stage.after this PR
checkCompileCompletion
takes the majority time for warm up.codes
I used the following codes to reproduce the problem
To see the logs from the Cloud Build CI, please join either our discussion or announcement mailing list.
This change is