Hi
Maybe I have not made myself clear I have run a configuration with macbook pro 13 and mini with display either non connected or connected directly to the unit this because I had an LG ultrafine monitor that only had a thunderbolt port so I was exactly in the situation of this post for 12 months using a Razer X powered by a Vega 64 Nitro
During those 12 months I always experienced laggy playback of my original media in the browser (Panasonic AVC intra 200/400 mbps HD/4K) from high sierra to Catalina from FCP 10.4.3 to 10.4.7
After discussing with Apple again and having looked on the eGPU forum and again on the developer documentation I decided to get rid of the LG monitor and get a display that can connect to the Razer through displayport or HDMI.
Since I have run a configuration with the display attached to the eGPU I have no longer any problem
Now just for the sake of this post I restored final cut 10.4.6 from back up and identified a library I have not touch since months I have connected the display using thunderbolt to the mini and detached the display port cable.
I have then run 10.4.6 with Prefer GPU setting and disabled background rending and then played back some original media in the browser as well as some project media rendered and not.
As I was experiencing before with my original media (that despite apple claim cannot be edited native) stutters and playback drops frames in 10.4.6 as it used to be. The activity monitor shows Vega utilisation of 0% confirming the eGPU is not used for live tasks. Only when playing back some project media and going through the occasional title I see some movement on the eGPU but essential what the documentation says about Final Cut is correct the live tasks are managed by the GPU that drives the display. To confirm I have connected the display to the eGPU and back to fast performance
Attached screenshot of 10.4.6 with eGPU usage at zero during playback and stop due to dropped frames
So at this point the claim that the eGPU was accelerating live tasks in the browser was clearly not true and what I have been experiencing for one year confirmed which is the mini can't play decently media not optimised nor timelines fully rendered in prores.
Moving on I updated the library and opened with 10.4.8 and checked the situation with exactly the same source media still with rendering disabled and display connected to the mini not the eGPU screenshot below
The eGPU remains at zero as before and actually it does not even move a little when it finds a title and the iGPU is now at 24% while in 10.4.6 it was much lower for playback
Conclusion: the performance of 10.4.8 is rubbish in playing my media as it was in 10.4.6 when the display is connected to the mini however now it accomplishes the same poor performance with much higher internal GPU utilization which is rather bizarre. When I use a configuration with the display connected to the eGPU the performance is outstanding in both 10.4.6 and 10.4.8 frankly is so fast I can't even tell if there is a deterioration
In terms of rendering the two version both pass it to the external GPU when the monitor is connected to the mini as this is a background task I don't know if there is a deviation or not in performance
So I think your claim that the eGPU was accelerating the internal display is not founded and consistent to the documentation and other sources eGPU is only used for background tasks so there is nothing that Apple can do as the functionality was never there.
For what concerns rendering in background there appear to be no differences that I can see on my past and new set up between the two versions.
Finally for sharing I am not planning to bother doing any tests because the H264 encoder of final cut is pathetic and although fast has terrible quality and should not be used. Also to clarify encoding is a CPU task as the newer apple hardware have hardware decoding and encoding in the CPU using Intel Quick Sync Video so they don't use the GPU at all. The GPU internal or external is only used if there are parts still left to render and as background rendering should be active on an eGPU set up when you get to that point there should be little left to render anyway