1

As the title may not be fully clear, here's a complete description of the problem.

I've written a small library for the linux framebuffer usingmmap and some (higher) drawing routines, effectlively copying specific bytes to specific offsets in the mapped memory.

To measure the output latency I need to determine the moment that follows my memcpy command (copied n bytes into the framebuffer) to eventually generate output on the Raspberry's HDMI port.

According to the image below, the next step that follows the framebuffer memory copy is the Hardware Video Scaler (HVS), again followed by the FIFO and HDMI encoder.

RPI fb schematics Source: https://blog.benjdoherty.com/2019/05/21/Exploring-Hardware-Compositing-With-the-Raspberry-Pi/

I now want to determine the time it takes after the framebuffer memcpy as close as possible. In other words, how long it takes for the graphics processsing unit and all other steps to produce the HDMI output from by framebuffer input (moments marked as t1 and t2 in the image below).

Is this even possible? Would you (re)write some kernel code to achieve that or is it possible from userland (or even within some C code)?

Time needed


Meta data

  1. Raspberry PI 4 latest
  2. OS: Raspbian Buster Lite Programming
  3. language: C
1
  • At a glance (I did not read the blog), what "HVS" implies to me is that everything after T1 actually takes place in hardware, which almost certainly means there is absolutely no way to do this in code, kernel or otherwise.
    – goldilocks
    Nov 20 '19 at 15:57
1

T1 can be estimated reasonably well by toggling a GPIO pin.

T2 can be measured with an HDMI analyzer or a high-end oscilloscope. Don't expect this to be cheap.

I bet Broadcom have already measured the delay themselves but unfortunately I have no idea what it takes to get such information from them. Some companies (like TI) are quite cool and send you a lot of datasheets even if you buy a few thousand chips, others will not disclose much to low-volume customers.

1
  • To be clear, I'm in control of the memcpy command etc, as I'm writing the framebuffer library on my own. So T1 is indeed really easy to capture. The problem is everything between T1 and T2. Unfortunately, a HDMI analyzer etc. is not possible as everything (the measurements) need to be done within the raspberry device.
    – elasticman
    Nov 20 '19 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.