BCMVideo GraphicsV 2 timing

Is it possible to get GraphicsV 2 to apply the resolution change during flyback on the Pi? The GPU appears to apply the resolution change mid-scan even when GraphicsV 2 is issued at VSync.

I’m trying to figure out how to change the screen geometry every frame without flickering.

EDIT: I’d also like to know if GraphicsV 2 actively clears the screen – or if its blanking the screen as a side effect of reallocating GPU memory.

The GPU appears to apply the resolution change mid-scan even when GraphicsV 2 is issued at VSync.

Remember that (to avoid blocking or additional frame lag during palette updates or bank switches), BCMVideo generates the VSync event at about halfway through the frame.

Now that we have GPU mode control it might be possible to tweak the VSync timing so that it occurs nearer to the end of the frame (preferably at the start of the blanking period, depending on exactly when the deadline is for getting the messages over to the GPU). The only problem is that for your use case (GPU mode changes disabled) that might be a bit tricky since I don’t think we have an easy way of getting the mode timings the GPU is using (worst-case, the driver could just have a lookup table for converting GPU mode numbers to VSync offsets). Or I guess we could check with the Pi firmware team to see if they can provide a more useful VSync interrupt.

EDIT: I’d also like to know if GraphicsV 2 actively clears the screen – or if its blanking the screen as a side effect of reallocating GPU memory.

That’ll be the GPU clearing it when it reallocates the framebuffer. There’s no requirement/expectation in the GraphicsV spec that memory should be cleared by the driver.

BCMVideo generates the VSync event at about halfway through the frame

That’s possibly not an issue, provided the geometry is changed during flyback by the GPU. My guess is it’s acted on immediately, would delaying the mailbox until the next physical VSync resolve the flickering? I believe its possible to schedule a mailbox for the next VSync, could BCMVideo do this for GraphicsV 2?

we could check with the Pi firmware team to see if they can provide a more useful VSync interrupt

I thought it was raised at flyback, but too late to pass anything to the GPU via mailbox for that frame.

That’ll be the GPU clearing it when it reallocates the framebuffer

popcornmix committed a change back in 2014 so FBIOPUT_VSCREENINFO doesn’t clear the frame if the allocated size doesn’t change. Not sure if that’s the physical or virtual size though. Here’s the GitHub issue that covers some of this.

Here’s a repro that shows the issue:

DIM code% 1024

FOR A%=0 TO 2 STEP 2
  P%=code%
  [OPT A%
  STMFD R13!, {R0-R12, R14}
  MOV R0, #19
  SWI "XOS_Byte"

  ADR R0, vidc3%
  MOV R9, #&2A
  MOV R4, #2
  SWI "XOS_CallAVector"

  SWI 256+31
  SWI 256+0
  SWI 256+0

  MOV R1, #ASC("0")
  MOV R2, #ASC("1")
  ._loop
    SWI "XOS_WriteS"
    EQUS "Line "
    EQUB 0
    ALIGN

    MOV R0, R1
    SWI "XOS_WriteC"
    MOV R0, R2
    SWI "XOS_WriteC"

    SWI 256+10
    SWI 256+13
    ADD R2, R2, #1
    TEQ R2, #10 + ASC("0")
    MOVEQ R2, #ASC("0")
    ADDEQ R1, R1, #1
    TEQ R1, #ASC("3")
  BNE _loop

  LDMFD R13!, {R0-R12, PC}

  .vidc3%
  ]
NEXT

FOR L%=0 TO 252 STEP 4:vidc3%!L%=0:NEXT
vidc3%!0=3
vidc3%!4=3
vidc3%!(5*4)=320
vidc3%!(16*4)=-1

MODE 13
REPEAT
  FOR H%=1 TO 255
    vidc3%!(11*4)=H%
    CALL code%
  NEXT
UNTIL 0

Here’s another example, that uses the SMI IRQ to lock to VSync.

It looks like the SMI IRQ is triggered shortly after the start of the scan though, as you can still see the frame being blanked by SetMode. It does at least lock to a set time from VSync though, which is an improvement on OS_Byte 19 which drifts out of sync (as visible in the repro above.)

ON ERROR PROCerror
DIM code% 1024

FOR A%=0 TO 2 STEP 2
  P%=code%
  [OPT A%
  STMFD R13!, {R0-R12, R14}

  ._vsyncWait
    LDR R0, vsyncOccurred
    TEQ R0, #0
  BEQ _vsyncWait
  MOV R0, #0
  STR R0, vsyncOccurred

  ADR R0, vidc3%
  MOV R9, #&2A
  MOV R4, #2
  SWI "XOS_CallAVector"

  SWI 256+31
  SWI 256+0
  SWI 256+0

  MOV R1, #ASC("0")
  MOV R2, #ASC("1")
  ._loop
    SWI "XOS_WriteS"
    EQUS "Line "
    EQUB 0
    ALIGN

    MOV R0, R1
    SWI "XOS_WriteC"
    MOV R0, R2
    SWI "XOS_WriteC"

    SWI 256+10
    SWI 256+13
    ADD R2, R2, #1
    TEQ R2, #10 + ASC("0")
    MOVEQ R2, #ASC("0")
    ADDEQ R1, R1, #1
    TEQ R1, #ASC("3")
  BNE _loop

  LDMFD R13!, {R0-R12, PC}


  .ClaimTrueVSync
  STMFD R13!, {R0-R2, R14}
  MOV R0, #48
  ADD R0, R0, #1<<31
  ADR R1, vsyncTriggered
  ADR R2, vsyncOccurred
  SWI "XOS_ClaimDeviceVector"
  LDMFD R13!, {R0-R2, PC}

  .ReleaseTrueVSync
  STMFD R13!, {R0-R2, R14}
  MOV R0, #48
  ADR R1, vsyncTriggered
  ADR R2, vsyncOccurred
  SWI "XOS_ReleaseDeviceVector"
  LDMFD R13!, {R0-R2, PC}


  .vsyncTriggered
  STR R14, [R12, #0]
  MOV PC, R14

  .vsyncOccurred EQUD 0

  .vidc3%
  ]
NEXT

FOR L%=0 TO 252 STEP 4:vidc3%!L%=0:NEXT
vidc3%!0=3
vidc3%!4=3
vidc3%!(5*4)=320
vidc3%!(16*4)=-1

CALL ClaimTrueVSync

MODE 13
REPEAT
  FOR H%=1 TO 255
    vidc3%!(11*4)=H%
    CALL code%
  NEXT
UNTIL 0
END

DEF PROCerror
  ON ERROR LOCAL END
  CALL ReleaseTrueVSync
  END
ENDPROC

Remember that (to avoid blocking or additional frame lag during palette updates or bank switches), BCMVideo generates the VSync event at about halfway through the frame.

Correction: VSync occurs normally (i.e. whenever the GPU raises the SMI interrupt). Palette updates / bank switches get buffered by BCMVideo and are acted on halfway through the frame. The primary aim of this buffering is to avoid any blocking while waiting for the GPU because (at the time the code was written – 2014) the GPU seemed to only process palette updates (and bank switches?) at a rate of one message sequence per frame. And IIRC the halfway point was chosen because (a) I don’t know when the deadline is for getting the messages sent to the GPU in order to make sure they get acted on ready for the next frame, and (b) the ARM timer (which is what I’m using to generate the mid-frame interrupt) can have its frequency affected by changes to the main ARM clock, so precisely timing the mailbox send would have been difficult. (I also didn’t want to use HAL timer 1, since that would have left the system without any spare HAL timers for other code to use)

Mode change requests are acted on immediately, so the half-frame interrupt isn’t relevant. I haven’t tried looking into the mode change timing on the GPU side (changing the screen geometry every frame isn’t the typical use case!)

Correction: VSync occurs normally

If you compare the two examples I’ve included above, the first drifts out of sync (geometry is changed at VSync) and the second is locked (geometry is changed at SMI interrupt).

the GPU seemed to only process palette updates (and bank switches?) at a rate of one message sequence per frame

Is it the GPU? Or a restriction in the blob? There’s been a lot of changes to the GPU side, so this may have changed since we tested in 2014.

changing the screen geometry every frame isn’t the typical use case!

No, not a typical use case. I’m aware of it being used to dynamically stretch the screen in height. The original release of Stunt Racer 2000 used it during the intro and Cartoon Line pt.1 uses it to shake the screen when the bull appears.

The Pi appears to be capable of rapidly changing the geometry, but it does highlight the fact VSync doesn’t occur at flyback. You’d think that would be fixed by now – unless the GPU simply doesn’t generate an event at flyback.

If you compare the two examples I’ve included above, the first drifts out of sync (geometry is changed at VSync) and the second is locked (geometry is changed at SMI interrupt).

I haven’t got round to running those yet – hopefully tonight. In both cases it should be the SMI interrupt that’s triggering your code. Maybe the OS_Byte 19 approach would see an extra random delay added, but I wouldn’t expect it to completely drift out of sync.

Is it the GPU? Or a restriction in the blob? There’s been a lot of changes to the GPU side, so this may have changed since we tested in 2014.

Almost certainly a restriction in the blob.

I’m aware of it being used to dynamically stretch the screen in height. The original release of Stunt Racer 2000 used it during the intro

“letterbox” might be a more accurate description. With Stunt Racer the mode timings being sent to the monitor remained the same, it just used the VIDC border controls to change the dimensions and position of the displayed framebuffer. The scale remained the same. If you were to try the same thing by adjusting the screen height on the Pi (even if you were to supply border parameters in the VIDC list) then there’s a good chance it will also affect the scale of the image. To get the same effect via the Pi’s framebuffer functionality I think we’d need a way of translating the border settings into overscan settings; the overscan settings can be modified via the mailbox interface, the tricky bit is working out when they should be used.

“letterbox” might be a more accurate description

It must be a bug in my code then as the blitter handles any letterboxing, it shouldn’t be pass any geometry changes to the GPU.

EDIT: It was indeed a bug in my code, the check for geometry changes was checking hdisp/vdisp instead of HCR/VCR.

Running your test code on a Pi 1 with RC15, the two seemed to behave pretty much identically. The flickering band of black was at the same location near the top of the screen. It did seem like the first program (OS_Byte 19) had an increased chance of the band being larger than normal, but no obvious signs of things being completely out of sync.