1863133 - DISCARD_RASTERIZER and TransformFeedback buffers

Status: UNCONFIRMED

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[contact]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0

Steps to reproduce:

I implemented a physical simulator with webgl2.

The physic computation is done in the vertex shader. I use TransformFeedback to store position and velocity and use a swapping buffer technique to memorize position and velocity. I compute delta T at each frame to update the physical data and pass it to the vertex shader through uniform.

I want to update physics more often than drawing. I call drawarrays every animation frame (note : same unexpected behaviour with requestanimationframe or with a timer). Let's say 60FPS. I disable the fragment shader with DISCARD_RASTERIZER and enable it only 25FPS.

Actual results:

The physical simulator is slower ("slow motion effect"), as if the TransformFeeback buffers were updated only when the fragment shader is turned on.

If I make a call to clear (0) at each frame (even if it should not be useful because I should clear it only when drawing), the physical simulator works at the desired speed.

I concluded that the TransformFeedback buffers are not updated when the fragment shader is turn off with DISCARD_RASTERIZER.

It is not the expected behaviour.

Expected results:

The physical simulator should give the same simulation speed. Only the display should be slower.

I saw there was some issues related to "clear" and "DISCARD_RASTERIZER". May be it is linked ?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[contact]

NOTE : it works in chrome.

DOCUMENTATION of DISCARD_RASTERIZER :

"When enabled, primitives are discarded immediately before the rasterization stage, but after the optional transform feedback stage "

Comment 3

[Mayank Bansal]

Is there a publicly visible link you can share here?

Comment 4

[contact]

http://public.yvesgufflet.fr/particles/index_OK.html
line 836 is modified so that the fragment shader is never disabled

http://public.yvesgufflet.fr/particles/index_NOK.html
line 836 allows to disable the fragment shader : it is not working as expected
physic simulation is slower

http://public.yvesgufflet.fr/particles/index_NOK_withclear.html
line 846 is added to call clear (0) and it is working as expected
physic simulation is normal

Comment 5

[Mayank Bansal]

Profiles:
(In reply to contact from comment #4)

http://public.yvesgufflet.fr/particles/index_OK.html
line 836 is modified so that the fragment shader is never disabled
https://share.firefox.dev/3Qo29Vn (very smooth)

http://public.yvesgufflet.fr/particles/index_NOK.html
line 836 allows to disable the fragment shader : it is not working as expected
physic simulation is slower

https://share.firefox.dev/40o2MTE (jerky animation but it doesnt use much more CPU/GPU) . This demo is jerky on Chrome too.

http://public.yvesgufflet.fr/particles/index_NOK_withclear.html
line 846 is added to call clear (0) and it is working as expected
physic simulation is normal

https://share.firefox.dev/3u48QVd (same as above). This demo is jerky on Chrome too.

Comment 6

[contact]

Thanks for your detailed feedback that I need to explore.

The jerky animation are due to the fact that there is intentionaly only 25 frames per second : meanwhile 25 frames is quite a lot and I am surprised that it render like that.

However the main point of my initial request is to take a look at the physic simulation which is realized in the vertex shader.

In the 2nd example, the physic is slower, particles move much more slowly as if the transform buffers were not updated when fragment shader is off. in the 3rd example, even if the animation is jerky, the physic simulation is the same speed : the refresh rate is just lower than in the 1st working example (vertex and fragment shader on).

The only difference between the 2nd and the 3rd example is the call to clear (0) when the fragment shader is off.

In chrome Version 119.0.6045.105 (Build officiel) (64 bits), the 2nd and 3rd example are "jerky" because of the choosen lower display refresh rate, but the physic run at the same speed.