BCMVideo system locks
Jon Abbott (1421) 2641 posts |
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 |
Jeffrey Lee (213) 6048 posts |
Thanks – I’ll take a look at this in the new year once I’m back from Christmas break. |
Jon Abbott (1421) 2641 posts |
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. |
Jon Abbott (1421) 2641 posts |
Jeffrey, did you manage to reproduce this issue? |
Jeffrey Lee (213) 6048 posts |
I haven’t had a look at it yet, sorry. I’ll try and have a look in the next few days. |
Jeffrey Lee (213) 6048 posts |
There were a few different issues:
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 |
Jon Abbott (1421) 2641 posts |
Thank you for looking into the issues. I’ll retest once the change is in the ROM.
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. |
Jon Abbott (1421) 2641 posts |
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. |
Jon Abbott (1421) 2641 posts |
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. |
Jon Abbott (1421) 2641 posts |
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. |