I have a misunderstanding using glClientWaitSync function.
Admit I am using something like that :
glDraw(...);
sync = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
glDraw(...);
glClientWaitSync(sync, GL_SYNC_FLUSH_COMMANDS_BIT, 1000000000);
glDeleteSync(sync);
If I well understand OpenGL Wiki, we have two cases
First case : OpenGL 4.5 : In this case, after the glClientWaitSync, we are sure that only the first draw is performed because it is write on the wiki :
In OpenGL 4.5, this flush is made special. If it's the first time that you are waiting on that particular sync object, and the wait is in the same context that created the sync object, the flush will behave as if you had issued it immediately after the sync object. So if you had issued other OpenGL commands after the sync object was created, they will not be flushed.
Second cases : OpenGL 4.4 or inferior : We are sure that both draw are performed because this function have "globally" the same behavior than glFlush function? Going that way, how really use persistent mapping using round robin fashion with OpenGL 4.4 if all the command buffer is flushed ?
"Flush" does not mean "has finished". It merely means "will eventually be executed by the GPU, without further OpenGL calls."
The 4.4 behavior will flush everything up to the glClientWaitSync command. The 4.5 behavior will only flush everything up to and including the glFenceSync call.
But in both cases, if glClientWaitSync returns without timing out or erroring, the only thing you know about the state of the GPU is that all of the commands before the glFenceSync call have completed.
Going that way, how really use persistent mapping using round robin fashion with OpenGL 4.4 if all the command buffer is flushed ?
If you just want to flush the fence sync, then that's what you have to do in 4.4. That is, glFlush immediately after creating the fence, but don't flush when using glClientWaitSync. This will give you the effect of the 4.5 behavior.