BCMVideo system locks

This is related to the issues I reported with Overlays in this post.

You can either run as-is and wait for a lock, or remove the WAIT for a near-instant lock.

I do not believe the issues are related to Overlays, but more likely something to do with mailbox messaging. It’s also very timing specific, only occurring when the GraphicsV calls occur around the same time as VSync based on what I’m seeing with ADFFS.

Repro (tested on a Pi3 @ 50Hz)

DIM code% 1024

width%=640:height%=512
PROCassm
SYS "OS_ScreenMode",11,-1 TO ,A%
!current_driver%=A%

A%=width%:B%=height%:CALL create_overlay%
ON ERROR CALL remove_overlay%:PRINT REPORT$;" at line ";ERL:END

REPEAT
  FOR bank%=0 TO 2
    A%=RND(width% DIV 2)
    B%=RND(height% DIV 2)
    C%=A%+32+RND(width%)
    D%=B%+32+RND(width%)
    CALL transform_overlay%
    C%=bank%
    CALL display_overlay%
    WAIT
  NEXT
UNTIL INKEY(-99)

CALL remove_overlay%
END


DEF PROCassm
FOR A%=0 TO 2 STEP 2
P%=code%
[OPT A%
.setup_reg%
STMFD R13!, {R0, R14}
LDR   R0, current_driver%
MOV   R8, R0, LSL #24

LDR   R0, overlay_id%
CMN   R0, #1
ORRNE R8, R8, R0, LSL #16
MOV   R9, #42
LDMFD R13!, {R0, PC}


.remove_overlay%
STMFD R13!, {R0-R12, R14}
BL    setup_reg%
LDMEQFD R13!, {R0-R12, PC}

ORR   R4, R8, #21          ;destroy
SWI   "XOS_CallAVector"
TEQ   R4, #0
MVNEQ R1, #0
STREQ R1, overlay_id%
LDMFD R13!, {R0-R12, PC}


.create_overlay%
STMFD R13!, {R0-R12, R14}
BL   setup_reg%
BLNE remove_overlay%

ADR   R10, overlay_mode%
STR   R0, [R10, #4]        ;width
STR   R1, [R10, #8]        ;height
ORR   R1, R1, R1, LSL #16  ;aspect ratio
MOV   R0, R10
MOV   R2, #1               ;scaling required
MOV   R3, #%1              ;head 1
ORR   R4, R8, #20          ;create
SWI   "XOS_CallAVector"
TEQ   R4, #0
LDMNEFD R13!, {R0-R12, PC}
STR   R0, overlay_id%
ORR   R8, R8, R0, LSL #16
LDMFD R13!, {R0-R12, PC}


.transform_overlay%
STMFD R13!, {R0-R12, R14}
BL   setup_reg%
LDMEQFD R13!, {R0-R12, PC}

ORR   R4, R8, #27
SUB   R5, R2, R0
SUB   R6, R3, R0
ORR   R7, R6, R5, LSL #16
SWI   "XOS_CallAVector"
LDMFD R13!, {R0-R12, PC}


.display_overlay%
STMFD R13!, {R0-R12, R14}
BL    setup_reg%
LDMEQFD R13!, {R0-R12, PC}

STR   R0, overlay_pos%+4
STR   R1, overlay_pos%+8
ADR   R0, overlay_pos%
MOV   R1, #1         ;1 entry in the array
ORR   R4, R8, #22
SWI   "XOS_CallAVector"
LDMFD R13!, {R0-R12, PC}


.current_driver%
 DCD 0

.overlay_pos%
 DCD 1
 DCD 0
 DCD 0

.overlay_id%
 DCD -1

.overlay_mode%
 DCD 1      ;flags
 DCD 0      ;width
 DCD 0      ;height
 DCD 5      ;log2bpp
 DCD -1     ;hz
 DCD 0
 DCD 0      ;framebuffer format - 32bpp ABGR
 DCD 3
 DCD -1     ;ncolour
 DCD 13
 DCD 3      ;banks
 DCD -1
]
NEXT
ENDPROC

Thanks – I’ll take a look at this in the new year once I’m back from Christmas break.

Much appreciated. If you’d me to email you a copy of ADFFS that exhibits issues mentioned in the other thread, let me know.

EDIT: ADFFS 2.84 along with the threaded versions that trigger the issues are posted here

Going to MODE 13 at a Supervisor prompt should be enough to cause stuck overlays when you return to the desktop.

Jeffrey, did you manage to reproduce this issue?

I haven’t had a look at it yet, sorry. I’ll try and have a look in the next few days.

There were a few different issues:

• The BASIC test you posted above was locking up because it was sometimes shrinking the overlay down to zero width or height and triggering a division-by-zero infinite loop in BCMVideo. Fixed in BCMVideo by adding some extra checks and having it hide zero width/height overlays.
• The threaded ADFFS module was failing (e.g. leaving the overlay on screen after MODE 13) because it’s making some of the overlay calls from an IRQ handler. Officially the GraphicsV overlay calls only support calls from the foreground, e.g. the actual foreground, or callbacks, or RTSupport threads. See the “Context” column of the main GraphicsV doc for the restrictions for the different calls (I guess that info should really also be on the individual pages). Calling BCMVideo’s overlay code from an IRQ handler was causing it to fail in all kinds of horrible ways, resulting in things like overlays being left on screen after they’d been hidden/destroyed, and probably a few of the issues which you mentioned in this post. “Fixed” in BCMVideo by having it ignore calls to the overlay ops which are being made from IRQ handlers. This protects BCMVideo from breaking, but also means the threaded ADFFS now won’t display the overlay at all. The default ADFFS overlay module seems to still work fine.
• There were also some cases where overlay update requests were being ignored by the GPU, presumably because they were coming at an inconvenient time and the GPU was already busy doing something else. Possibly this relates to the timing-related issues you mentioned over here, but I was also seeing issues with a modified version of the above BASIC test (with the WAIT removed, sometimes when quitting the overlay would be left on screen). A closer look at the BCMVideo sources revealed that although the hardware pointer overlay code was designed to deal with “GPU ignores the request” situations, the GraphicsV overlay code wasn’t. So that’s now been fixed by reworking some of the overlay code and adding a retry loop to try and make sure the updates actually go through. If you completely spam the GPU with updates then it can still occasionally fail (and will also cause the pointer movement to be laggy), so some more improvements would be nice (probably queueing up the changes so that they can be performed in batches by an RTSupport thread), but this should be a lot better than it used to be.

The BCMVideo fixes are currently pending merge; hopefully they’ll get approved in the next few days.

https://gitlab.riscosopen.org/RiscOS/Sources/Video/HWSupport/BCMVideo/-/merge_requests/5

Thank you for looking into the issues. I’ll retest once the change is in the ROM.

The threaded ADFFS module was failing (e.g. leaving the overlay on screen after MODE 13) because it’s making some of the overlay calls from an IRQ handler.

The threaded version makes the call to change the overlay during GraphicsV 1.

The unthreaded Module uses a Callback, but does result in delayed and dropped frames as Callback’s aren’t that useful when something needs to happen immediately.

Unfortunately most of the calls to GraphicsV have to be made under IRQ as they’re all made within the GraphicsV driver. I’ll have to put my thinking cap on to figure out a workaround.

I’ve switched the latest ADFFS 2.84 beta to perform the overlay transform / display to an RTSupport thread and given the latest ROM build a quick test.

Although I’m no longer seeing the locks or stuck overlays, it can sometimes take a while to display the overlay. This is quite evident via F12 / MODE 13 where you can sometimes just get a blank screen, repeated mode changes will eventually display it though.

The overlay is switching through three banks at 50fps, so my initial thought is the GPU is possibly busy and the request is being dropped repeatedly. To avoid spamming the driver, I’m only passing the initial overlay transform once and it’s not sent again until the video geometry changes. If that request gets dropped the overlay will never display.

I’m going to perform some more thorough testing, I suspect games that change their geometry every frame will probably stutter like crazy without the overlay changes occurring during VSync, but for everything else I think overlays are probably now viable on the Pi.

Thanks once again.

Jeffrey, I’ve noticed another odd issue today.

GraphicsV 23 sometimes return unclaimed. I’m having to call it every VSync until it returns R4=0.

I have now formally released ADFFS 2.84, which uses GPU overlays by default if the current GraphicsV driver supports them.

Although I believe ADFFS complies with the restrictions placed on BCMVideo overlays by moving all overlay code to a separate RTSupport thread, there is still the issue of the overlay contents sometimes not appearing on-screen for minutes – which I can’t explain. This is easily reproduce by switching to a legacy mode when shelled out of the desktop, eventually it will result in a black screen.

I can’t tell where the issue is, except GraphicsV is claiming the requests (except for GraphicsV 23 noted in my previous post), so I presume BCMVideo is passing the requests on via mailbox. If the initial overlay creation fails, ADFFS shuts down its blitter and displays an error on-screen, but this never happens, so I believe the overlay is being created but possibly the banks are either not pointing to the correct memory location or the size/scale isn’t being set.