Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sun, 4 Apr 2021 10:00:16 GMT, Jayathirth D V wrote: >>> We need to use appropriate encoder(where scissor is set) to honour clip in >>> copyArea. >> >> It is quite interesting that blitting with or without clipping does not have >> any difference. thank you for confirmation. but probably our perf tests are >> not good enough. > > @mrserb Are there any more inputs/review comments? nop, it is fine. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov wrote: >>> > I am not getting what do you mean by 'new "round trip" '. Please >>> > elaborate. >>> > Regarding performance metrics i have captured the details in the bug and >>> > there is no degradation. >>> >>> The new code path which takes care of the clip, if there is no degradation >>> means that we get it for free? >> >> Before this change we used to get blitEncoder from same commandbuffer(and >> same CommandQueue) as we are doing now. And then commit the commandbuffer, >> so from computational perspective we are not holding or doing anything extra >> in new implementation. We need to use appropriate encoder(where scissor is >> set) to honour clip in copyArea. >> >> Since we are not seeing any difference in performance numbers (especially in >> swingmark where we do lot of scrolling/copyArea) we are basically getting >> clipping in copyArea without any degradation. Also in Netbeans i have done >> good amount scrolling test and i dont see any degradation. Also i expected >> improvement in performance (we are seeing little improvement in swingmark >> numbers) because we are actually doing less amount of copy operation now. > >> We need to use appropriate encoder(where scissor is set) to honour clip in >> copyArea. > > It is quite interesting that blitting with or without clipping does not have > any difference. thank you for confirmation. but probably our perf tests are > not good enough. @mrserb Are there any more inputs/review comments? - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov wrote: > > We need to use appropriate encoder(where scissor is set) to honour clip in > > copyArea. > > It is quite interesting that blitting with or without clipping does not have > any difference. thank you for confirmation. but probably our perf tests are > not good enough. Exactly i suspect we are not hitting threshold of GPU computing in our tests. If we hit GPU threshold with larger clip bounds i expect performance to be on higher side after the fix. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 05:02:24 GMT, Jayathirth D V wrote: > We need to use appropriate encoder(where scissor is set) to honour clip in > copyArea. It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 03:51:29 GMT, Sergey Bylokhov wrote: > > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > > Regarding performance metrics i have captured the details in the bug and > > there is no degradation. > > The new code path which takes care of the clip, if there is no degradation > means that we get it for free? Before this change we used to get blitEncoder from same commandbuffer(and same CommandQueue) as we are doing now. And then commit the commandbuffer, so from computational perspective we are not holding or doing anything extra in new implementation. We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. Since we are not seeing any difference in performance numbers (especially in swingmark where we do lot of scrolling/copyArea) we are basically getting clipping in copyArea without any degradation. Also in Netbeans i have done good amount scrolling test and i dont see any degradation. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Sat, 3 Apr 2021 02:56:48 GMT, Jayathirth D V wrote: > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > Regarding performance metrics i have captured the details in the bug and > there is no degradation. The new code path which takes care of the clip, if there is no degradation means that we get it for free? - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Fri, 2 Apr 2021 22:43:36 GMT, Sergey Bylokhov wrote: > Just curious how this new "round trip" will affect the performance when the > clip is set and when not? is it cheap? I am not getting what do you mean by 'new "round trip" '. Please elaborate. Regarding performance metrics i have captured the details in the bug and there is no degradation. - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Thu, 1 Apr 2021 15:50:50 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Refactor code to use drawTex2Tex > > Marked as reviewed by psadhukhan (Reviewer). Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap? - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
On Thu, 1 Apr 2021 14:15:37 GMT, Jayathirth D V wrote: >> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state >> information because of which we ignore clip parameters set in rect clip and >> shape clip. We need to query and use encoders from EncoderManager to honour >> clip states in copyArea. > > Jayathirth D V has updated the pull request incrementally with one additional > commit since the last revision: > > Refactor code to use drawTex2Tex Marked as reviewed by psadhukhan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3283
Re: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state > information because of which we ignore clip parameters set in rect clip and > shape clip. We need to query and use encoders from EncoderManager to honour > clip states in copyArea. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Refactor code to use drawTex2Tex - Changes: - all: https://git.openjdk.java.net/jdk/pull/3283/files - new: https://git.openjdk.java.net/jdk/pull/3283/files/9b4a90ab..91e068b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3283=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3283=02-03 Stats: 35 lines in 1 file changed: 0 ins; 22 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3283/head:pull/3283 PR: https://git.openjdk.java.net/jdk/pull/3283
