Hey, I was reading your code of the libDrmRenderer and I was wondering about one thing, maybe you can help me out.
In libDrmRenderer the schedule-buffer-for-page-flip-function is called right away when we get the page-flip-done event. If I am right, this means the next buffer to display is read out of queue and scheduled for page-flip right after the page-flip of the previous buffer happens. This seems to me to add some delay, because there could have been a new buffer between the time I schedule the buffer for page-flip and the actual page flip event. (with 60Hz display, the delay could be 16ms.)
Am I wrong with my assumption and is there maybe a better way to do this to reduce delay? Can I use VBlank callback or use waitForVBlank function to schedule my buffer for page-flip or is it already to late when vblank callback ist called?
Best regards,
jb
EDIT:
I have found in the documentation a note:
" drmModePageFlip does not wait for rendering to complete, nor is future rendering blocked until the flip completes. This differs from KMS based implementations that utilize implicit synchronization. When using EGLOutput together with DRM-NVDC, synchronization is handled internally."
Does that mean I can call this function again with a new buffer so that the old one will be overwritten? This would be different from other implementations I have read about where it will return -EBUSY if called already before the next flip was done.
Hi,
In NvDrmRender the function drmModePageFlip() is called for every frame and the frame is rendered in next vsync. So if it it called between vsync there should be no latency.
Hi, thanks for your fast response.
I’ll try to be more precise.
I am not interested in displaying every frame, but more interested in displaying the latest frame possible. That’s why I was asking myself if it is possible to call drmModePageFlip() again if I get a new frame in the time slot between my first call of that function and the next v-sync. If it is the case it is possible I can just always call this function when a new frame is ready.
Thanks for the hint, but the patch is actually based on my own topic, so I already came across this and have the patch already applied.
I have one other question, if you prefer, I could open another topic for this:
We have a lot of this in NvDrmRenderer.cpp:
/* TODO:
* We get new FDs from camera consumer. Don’t do mapping until
* we can resolve that.
*/
// map_list.insert(std::make_pair(fd, fb));
Since I am using 4 cycling buffers to use this, can I uncomment this? What is the advantage of mapping? I guess it is more efficient to not always create a new fb from the buffer. Does is decrease latency also?
Hi,
By default NvDrmRender renders every frame. If you would like to render the latest frame, you may customize NvDrmRender to put out-of-date frames into freeBuffers queue directly and render latest frame. It the queue is handled properly, it should work fine.