From: Tom Li <tomli@tomli.me> To: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com>, linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU. Date: Tue, 2 Apr 2019 00:26:18 +0800 [thread overview] Message-ID: <20190401162618.GB15736@localhost.localdomain> (raw) In-Reply-To: <20190331180947.s44eznujdeucnl7f@debian> On Sun, Mar 31, 2019 at 07:09:47PM +0100, Sudip Mukherjee wrote: > On Fri, Mar 22, 2019 at 01:17:55PM +0800, Yifeng Li wrote: > I didnot notice any performace improvement in my system. Infact, I have > never seen the performance problem that you mentioned. But, it will be > good to have the 2D feature back again. Are you using sm712fb under the Linux tty console? If you are using X, Qt or DirectFB or something similar, these 2D code won't have any effect at all, because they are only used by the Linux VT console internally. Please try testing it under a Linux tty. Another possibility is that you are using a high-performance CPU with high clock/bus frequencies, which writing to the framebuffer directly can break-even/outperform the 2D acceleration. But I'm not sure about it. Please let me know more about your setup. > If it is a big endian, acceleration is disabled, but you are still > calling smtcfb_reset_accel() which will "enable Zoom Video Port, > 2D Drawing Engine and Video Processor". Will that not create any problem > in a big endian system? Personally, I don't think there's an issue, because smtc_seqw() only does 8-bit I/O, and is known to be safe under Big-Endian. But I agree, calling this function should be avoided since it's not tested. > > + if (unlikely(info->state != FBINFO_STATE_RUNNING)) > > + return; > > Did you measure the performance difference with and without "unlikely"? > Quoting GregKH from https://lkml.org/lkml/2018/11/7/36 > "don't do stuff like this unless you can actually measure the > difference". In the old days, these two macros are used liberally, everywhere. I learned about them by reading drivers code in fbdev/. Thanks for informing me the new policy regarding the use of them. I'll remove them. > <snip> > > + * & HIGH with 0xffffffff (all ones, and we have already set > > + * that in smtcfb_init_accel). Since the color of this mono > > + * pattern is controlled by DPR_FG_COLOR, BITBLTing it with > > + * ROP_COPY is effectively a rectfill(). > > + */ > > + smtc_dprw(DPR_FG_COLOR, color); > > + smtc_dprw(DPR_DST_COORDS, DPR_COORDS(dx, dy)); > > I will need some more time to verify all these and other registers with > the datasheet and test again. No problem. But again, the 2D code is only used by Linux VT code internally, if you are not using VT console, the behavior cannot be tested properly. Are you testing it under the Linux tty console? And does your dmesg log says, "2D acceleration is enabled"? Running the "fbtest" testsuit is also a good way to "smoke-test" the fbdev code. Thanks, Tom Li
WARNING: multiple messages have this Message-ID (diff)
From: Tom Li <tomli@tomli.me> To: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com>, linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU. Date: Mon, 01 Apr 2019 16:26:18 +0000 [thread overview] Message-ID: <20190401162618.GB15736@localhost.localdomain> (raw) In-Reply-To: <20190331180947.s44eznujdeucnl7f@debian> On Sun, Mar 31, 2019 at 07:09:47PM +0100, Sudip Mukherjee wrote: > On Fri, Mar 22, 2019 at 01:17:55PM +0800, Yifeng Li wrote: > I didnot notice any performace improvement in my system. Infact, I have > never seen the performance problem that you mentioned. But, it will be > good to have the 2D feature back again. Are you using sm712fb under the Linux tty console? If you are using X, Qt or DirectFB or something similar, these 2D code won't have any effect at all, because they are only used by the Linux VT console internally. Please try testing it under a Linux tty. Another possibility is that you are using a high-performance CPU with high clock/bus frequencies, which writing to the framebuffer directly can break-even/outperform the 2D acceleration. But I'm not sure about it. Please let me know more about your setup. > If it is a big endian, acceleration is disabled, but you are still > calling smtcfb_reset_accel() which will "enable Zoom Video Port, > 2D Drawing Engine and Video Processor". Will that not create any problem > in a big endian system? Personally, I don't think there's an issue, because smtc_seqw() only does 8-bit I/O, and is known to be safe under Big-Endian. But I agree, calling this function should be avoided since it's not tested. > > + if (unlikely(info->state != FBINFO_STATE_RUNNING)) > > + return; > > Did you measure the performance difference with and without "unlikely"? > Quoting GregKH from https://lkml.org/lkml/2018/11/7/36 > "don't do stuff like this unless you can actually measure the > difference". In the old days, these two macros are used liberally, everywhere. I learned about them by reading drivers code in fbdev/. Thanks for informing me the new policy regarding the use of them. I'll remove them. > <snip> > > + * & HIGH with 0xffffffff (all ones, and we have already set > > + * that in smtcfb_init_accel). Since the color of this mono > > + * pattern is controlled by DPR_FG_COLOR, BITBLTing it with > > + * ROP_COPY is effectively a rectfill(). > > + */ > > + smtc_dprw(DPR_FG_COLOR, color); > > + smtc_dprw(DPR_DST_COORDS, DPR_COORDS(dx, dy)); > > I will need some more time to verify all these and other registers with > the datasheet and test again. No problem. But again, the 2D code is only used by Linux VT code internally, if you are not using VT console, the behavior cannot be tested properly. Are you testing it under the Linux tty console? And does your dmesg log says, "2D acceleration is enabled"? Running the "fbtest" testsuit is also a good way to "smoke-test" the fbdev code. Thanks, Tom Li
next prev parent reply other threads:[~2019-04-01 16:26 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-22 5:17 [PATCH v2 0/7] implement 2D acceleration, minor cleanups, doc updates Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-22 5:17 ` [PATCH v2 1/7] fbdev: sm712fb: use type "u8" for 8-bit I/O Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 17:16 ` Sudip Mukherjee 2019-03-31 17:16 ` Sudip Mukherjee 2019-03-31 17:16 ` Sudip Mukherjee 2019-03-22 5:17 ` [PATCH v2 2/7] fbdev: sm712fb: add 2D-related I/O headers and functions Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 17:25 ` Sudip Mukherjee 2019-03-31 17:25 ` Sudip Mukherjee 2019-04-01 16:04 ` Tom Li 2019-04-01 16:04 ` Tom Li 2019-03-22 5:17 ` [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 18:09 ` Sudip Mukherjee 2019-03-31 18:09 ` Sudip Mukherjee 2019-04-01 16:26 ` Tom Li [this message] 2019-04-01 16:26 ` Tom Li 2019-04-02 20:53 ` Sudip Mukherjee 2019-04-02 20:53 ` Sudip Mukherjee 2019-03-22 5:17 ` [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 18:33 ` Sudip Mukherjee 2019-03-31 18:33 ` Sudip Mukherjee 2019-04-01 16:41 ` Tom Li 2019-04-01 16:41 ` Tom Li 2019-04-02 20:59 ` Sudip Mukherjee 2019-04-02 20:59 ` Sudip Mukherjee 2019-03-22 5:17 ` [PATCH v2 5/7] Documentation: fb: sm712fb: add information mainly about 2D Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 18:54 ` Sudip Mukherjee 2019-03-31 18:54 ` Sudip Mukherjee 2019-03-31 18:54 ` Sudip Mukherjee 2019-04-01 17:30 ` Tom Li 2019-04-01 17:30 ` Tom Li 2019-04-02 21:03 ` Sudip Mukherjee 2019-04-02 21:03 ` Sudip Mukherjee 2019-04-02 21:03 ` Sudip Mukherjee 2019-03-22 5:17 ` [PATCH v2 6/7] fbdev: sm712fb: Kconfig: add information about docs Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 19:01 ` Sudip Mukherjee 2019-03-31 19:01 ` Sudip Mukherjee 2019-04-01 17:33 ` Tom Li 2019-04-01 17:33 ` Tom Li 2019-03-22 5:17 ` [PATCH v2 7/7] MAINTAINERS: sm712fb: list myself as one maintainer Yifeng Li 2019-03-22 5:17 ` Yifeng Li 2019-03-31 19:08 ` Sudip Mukherjee 2019-03-31 19:08 ` Sudip Mukherjee 2019-03-31 19:08 ` Sudip Mukherjee 2019-04-01 17:41 ` Tom Li 2019-04-01 17:41 ` Tom Li 2019-04-02 21:09 ` Sudip Mukherjee 2019-04-02 21:09 ` Sudip Mukherjee 2019-04-02 21:09 ` Sudip Mukherjee 2019-04-03 13:53 ` Bartlomiej Zolnierkiewicz 2019-04-03 13:53 ` Bartlomiej Zolnierkiewicz 2019-04-05 22:11 ` Sudip Mukherjee 2019-04-05 22:11 ` Sudip Mukherjee 2019-04-05 22:11 ` Sudip Mukherjee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190401162618.GB15736@localhost.localdomain \ --to=tomli@tomli.me \ --cc=b.zolnierkie@samsung.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=sudipm.mukherjee@gmail.com \ --cc=teddy.wang@siliconmotion.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.