[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing performance with metal renderi
From:       Alexey Ushakov <avu () openjdk ! org>
Date:       2022-06-24 9:19:58
Message-ID: bXSV6Cm5aXU0fOu5YoI_KsZQAmyd9sdWup_dsksdlXA=.a627c399-657f-459f-a29c-10bdfe205cb8 () github ! com
[Download RAW message or body]

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas <aghaisas@openjdk.org> wrote:

> > J2DBench test option files attached to \
> > [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing \
> > performance on macOS with Metal rendering pipeline as compared to OpenGL \
> > rendering pipeline. 
> > **Analysis :** 
> > Current implementation of 2D primitives (Line, Rectangle, Parallelogram - \
> > Draw/Fill operations) in Metal rendering pipeline follow below structure- 1) End \
> > points (vertices) required for the primitive drawing are put in a buffer. 2) The \
> > data prepared in above step is sent to GPU using MTLRenderCommandEncoder \
> > `setVertexBytes()` call 3) A draw command is issued using MTLRenderCommandEncoder \
> > `drawPrimitives()` call 4) Primitive Color is set (repeated when encoder or color \
> > changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in \
> > MTLRenderCommandEncoder state update. 
> > **Root Cause of slower performance :**
> > It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` \
> > by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data \
> > each time slows down the rendering. 
> > **Fix :** 
> > MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
> > The primitive drawing logic is modified to collate adjacent draw calls as below -
> > 1) A buffer of size approximately equal to 4KB is created - this is treated as \
> > common vertex buffer which is reused again and again 2) For each primitive draw \
> > call - the vertices needed for that draw call are added to the above buffer 3) \
> > When the buffer is full OR some other condition occurs ( e.g. breakage of draw \
> > primitive sequence, some other operation as change of color etc) -  a) Vertex \
> > data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` \
> > call. b) A single (or multiple) draw command(s) are issued using \
> > MTLRenderCommandEncoder `drawPrimitives()` call. 
> > 
> > **More insight :** 
> > In general, an application requires a mix of 2D shapes, images and text of \
> > different color and sizes. The performance test that we have measure rendering \
> > performance of extreme cases such as - 1) J2DBench - tests the repeated drawing \
> > of the same type and same color in a time period - e.g. Find the rendering speed \
> > of repeated 2D Line draw operation in X mSec? 2) RenderPerf test - tests the \
> > drawing of N primitives of the same type but each instance with a different color \
> > and capture FPS. 
> > This PR optimizes the Java2D Metal rendering pipeline implementation for the \
> > first case where the same primitive is drawn repeatedly without changing its \
> > color. Our current architecture needs to be tweaked to address slower performance \
> > shown by RenderPerf tests.  If needed, that needs to be done separately.  
> > **Results :**
> > The performance results are attached to the JBS.
> 
> Ajit Ghaisas has updated the pull request incrementally with one additional commit \
> since the last revision: 
> make method inline + clean commented line

Looks good

-------------

Marked as reviewed by avu (Committer).

PR: https://git.openjdk.org/jdk/pull/9245


[prev in list] [next in list] [prev in thread] [next in thread]