#rnx
#rb none
#ROBOMERGE-OWNER: ryan.durand
#ROBOMERGE-AUTHOR: ryan.durand
#ROBOMERGE-SOURCE: CL 10869210 via CL 10869511 via CL 10869900
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870549 by ryan durand in Main branch]
This change also resolves the remaining issues from the recent //UE4/Main -> //UE4/Dev-Rendering merge involving the RHI Lock/Unlock buffer API changes.
#rb Matt.Kuhlenschmidt
[CL 7661147 by Luke Thatcher in Dev-Rendering branch]
Rollbacked FDeferredCleanUpInterface use to ensure it wont crash for the moment
[REVIEW] Matt.Kuhlenschmidt
#rnx
#ROBOMERGE-SOURCE: CL 7642056 via CL 7642098 via CL 7642101 via CL 7644279
#ROBOMERGE-BOT: (v372-7473910)
[CL 7644420 by mickael gilabert in Main branch]
Removed FlushRenderingCommands in destructor and defer destruction of BufferData and VertexBuffer
Keep a reference of VertexBufferRHI in RHI command in case VertexBufferRHI gets modified on RT by being resized
#rb matt.kuhlenschmidt
#rnx
#ROBOMERGE-SOURCE: CL 7617028 via CL 7617479 via CL 7617521 via CL 7625651
#ROBOMERGE-BOT: (v372-7473910)
[CL 7625726 by mickael gilabert in Main branch]
This change makes it possible to remove the layout and painting overhead that Slate performs every frame. The system is off by default as we continue to iterate on it.
However, this includes massive changes to batching, rendering, hit testing, and invalidation panels which are permanent changes and cannot be disabled.
#rb chris.gagnon, nick.darnell
[CODEREVIEW] nick.darnell
#ROBOMERGE-OWNER: matt.kuhlenschmidt
#ROBOMERGE-AUTHOR: matt.kuhlenschmidt
#ROBOMERGE-SOURCE: CL 7232617 via CL 7235502
#ROBOMERGE-BOT: (v367-6836689)
[CL 7235503 by matt kuhlenschmidt in Main branch]
RHIs can now make use of the RHICmdList.IsTopOfPipe() and RHICmdList.IsBottomOfPipe() functions to determine if lock/unlock operations should be deferred or not:
- If IsTopOfPipe() returns true, the code is executing on the rendering thread (RT), whilst the RT is recording commands into the immediate RHI command list. Buffer renames etc may need to be deferred down the pipe using RHICmdList.EnqueueLambda().
- If IsBottomOfPipe() returns true, the code is replaying previously recorded commands (or we are Bypass()ing the command list recording). As such, we should behave like we are running on the RHI thread (RHIT) and access GPU resources directly. It is possible for IsBottomOfPipe() to return true whilst we are on the RT, if running in "-norhithread" mode, since the RT both records and plays back the immediate command list. This is why it is important to use the IsTopOfPipe/IsBottomOfPipe functions to provide the execution context in the RHI, rather than using threading functions like IsInRenderingThread(). It is also more optimal to use these new functions, as the IsIn*Thread() functions require accessing TLS data which can be slow on some platforms.
The rest of this change refactors the RHI lock/unlock API to allow the FRHICommandListImmediate to be passed all the way into the RHI implementation. RHIs now have a choice of which buffer lock functions to implement. Either:
- Implement the FDynamicRHI::RHILock*Buffer and FDynamicRHI::RHIUnlock*Buffer functions. These can be called on *both* the top and bottom of pipe. The RHI is required to use the passed-in RHICmdList to determine execution context. This is the most optimal approach as it gives the RHI the opportunity to return GPU memory (e.g. upload heap memory) in the Lock function directly, minimizing the number of memcpy()s needed to update a buffer. It is however the more complex solution as the RHI needs to use the RHICmdList.IsTopOfPipe/IsBottomOfPipe functions to determine if lock operations should be deferred with EnqueueLambda().
- Implement the FDynamicRHI::Lock*Buffer_BottomOfPipe and FDynamicRHI::Unlock*Buffer_BottomOfPipe functions. This is the simplest solution. RHIs can assume these functions will always be called at the bottom of the pipe (hence the name), and so can access GPU resources directly without having to defer operations via EnqueueLambda, nor check the IsTopOfPipe/IsBottomOfPipe functions. It is less optimal though, as its implementation relies on the base class implementation of FDynamicRHI::RHILock*Buffer, which returns temporary CPU memory on Lock(), and does a memcpy() and free on Unlock.
This change also modifies the global resolve shader. Various platform RHIs were doing what was effectively a manual draw user primitives, by creating, locking and unlocking a vertex buffer just to fill it with vertices for a full screen resolve. This is now handled with a global, immutable vertex buffer and uniform parameters.
#rb Rolando.Caloca, Marcus.Wassmer
#jira none
[CL 7039544 by Luke Thatcher in Dev-Rendering branch]
