Graphics pipeline stall warning

[wdanilo]

Hi! I was searching for a way to async read pixels back to JS but I was constantly getting warnings. When I was running your example it indeed seems to work, but the warnings in console are the same:

performance warning: READ-usage buffer was read back without waiting on a fence. This caused a graphics pipeline stall.performance warning: READ-usage buffer was read back without waiting on a fence. This caused a graphics pipeline stall.

I don't get this warning in Firefox though. Do you know if it's a Chrome bug or something wrong with the implementation provided here?

I'm running Chrome 69.0.3497.72 (Official Build) beta (64-bit) on Linux.

[kainino0x]

Likely a bug in my code in Chrome, although don't remember if this demo is fully up-to-date. I'll look into it. Thanks!

[wdanilo]

@kainino0x I would be very thankful if you would find a little time to look at it and confirm if the demo is up to date or there is something wrong with the code. Your usage of fence + reading pixels back is the only one that I could find across the web and it looks very correct to me (unless I'm missing something). The application we create would strongly depend on this behavior and I would rather not throw hundreds of warnings to the users. If you need me to test anything or report an official bug in Chrome, I'd love to help!

[wdanilo]

@kainino0x moreover, do you know if anything in this matter would change in Chrome in near future? I've seen some topics about WEBGL_get_buffer_sub_data_async extension, but also information that this extension is "dead". Do you know if there are any plans for more "native" support here?

[kainino0x]

WEBGL_get_buffer_sub_data_async is dead - this optimization replaces it. Chrome has special code to implement it. However, I still have an open, unfinished proposal to transform WebGL fences/queries into Promises - let me know if that would help you.

No need to file a Chrome bug; I can file it if I need to track it. (I'm the one who implemented the optimization in Chrome and added that warning.)

I would love to hear more about your use case though, to make sure this is working well for you. Feel free to email me (kainino at google).

[kainino0x]

When I run my example on ChromeOS 71.0.3578.21 dev and on Windows with 70.0.3538.110, I see the warnings with "blocking getBufferSubData" but they stop when I use "nonblocking getBufferSubData."

Can you confirm whether this is the case for you too?

[wdanilo]

Thank you for looking at this topic. I've updated Chrome to 71 and warnings in your example disappeared. Moreover, they also disappeared in my code (Im using nonblocking getBufferSubData). I've also tested the code without fence and warnings are reported correctly then, so it seems to be actually working here.

To sum this up - I'm sorry for not updating Chrome to the newest possible version before asking this question, it may actually solve it. On the other side, I'm happy I've chatted with you, cause I'd love to tell you more about what we do, but I'll send you a mail in a day or two, cause I'm just traveling and I'm hardly reachable. As a short info, we are building a new rendering engine for our programming language (rendering engine for programming language sounds strange, right? :D ) : http://luna-lang.org

[kainino0x]

Aha, we did have a few releases where there were issues in the implementation. Glad to hear it's fixed! Looking forward to your mail.

[raj-sivakumar-zz]

Would it be possible to re-open this bug @kainino0x? I'm on Chrome Version 71.0.3578.98 and am running into this exact issue on Mac

[kainino0x]

Just to double check, does it continue producing new warning messages while you have it set to "nonblocking getBufferSubData"?