From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: I.MX6 HDMI support in v4.2
Date: Tue, 15 Sep 2015 15:29:13 +0100 [thread overview]
Message-ID: <20150915142913.GV21084@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <m3wpvs0wvu.fsf@t19.piap.pl>
On Tue, Sep 15, 2015 at 01:01:25PM +0200, Krzysztof Ha?asa wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > Let's not forget that Dove hardware is slower than iMX6, so I think that
> > iMX6 should manage to comfortably achieve the 16.6ms required for
> > frame-by-frame display from your program.
>
> Interestingly, i.MX6 seems to achive about 3.2 ms, which is much faster.
> If not for the missing color planes (and scaling), it would be perfect.
> (and I only need 30 FPS).
That means iMX6 isn't synchronising to the vertical sync, so would be
subject to tearing.
>
> > Now, as for using the GPU, X server analysis:
> > - Again about 1ms between select() and read() of the event
> > - 1ms to the first WAIT_VBLANK ioctl on the display adapter to read the
> > last VSYNC time
> > - 200us later to map the user pointer
> > - 300us to the WAIT_VBLANK ioctl to wait for the vblank (which takes in this
> > instance 3.5ms to fire)
> > - 130us to first attempt to submit the GPU queue, which returns -EAGAIN
> > after 6.4ms
> > - second attempt takes 9.5ms to complete successfully
> > - 1ms (with intervening SIGALRM handler) to wait for the GPU to finish,
> > which takes 11.5ms
> > - 450us to ask DRM to release the user pointer buffer, which takes 9.4ms
> > - 1ms (with intervening SIGALRM handler) to report completion of the operation
> > - The X server then takes about 4ms to get back to calling select().
>
> Sure, I know it has to be slower.
>
> So this takes (on Dove) about 50 ms (at 1024x768), thus is way too slow
> to display video at this (or higher) resolution and frame rate.
> On i.MX6q, it takes about 66 - 74 ms, depending on actual clock speed
> (frequency scaling, up to 1 GHz).
It's interesting that iMX6 takes longer - without analysing what's going
on, I'd guess that will be because the GC320's memory bandwidth is
throttled compared to Dove.
iMX6 seems to have a problem with the bus arbitration in that each master
which can access DDR is given a fixed timeslot, whether or not there are
any other masters wanting access. Performance measurement with 64-bit
DDR has shown that out of iMX6Q,D,DL,S the iMX6DL performs the best for
raw IO as there are fewer masters (fewer CPUs and fewer peripherals
wanting DDR access), so the timeslots are bigger.
I've found that it is very difficult to get iMX6's GPUs to out-perform
neon optimised libpixman in terms of performance measurements - and I
think the reason for this is because both Neon optimised libpixman and
the GPUs are running up against the same bottleneck - the available
DDR bandwidth. However, what you do get is CPU offload of that effort
- filling one of those non-CPU DDR access timeslots with useful work,
freeing up the CPU DDR timeslot to do other tasks.
I have no idea how much truth there is to this, this is all based upon
performance measurement, and drawing conclusions from those measurements.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-09-15 14:29 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 10:55 I.MX6 HDMI support in v4.2 Krzysztof Hałasa
2015-09-07 11:25 ` Russell King - ARM Linux
2015-09-07 14:04 ` Krzysztof Hałasa
2015-09-08 9:16 ` Russell King - ARM Linux
2015-09-08 11:01 ` Krzysztof Hałasa
2015-09-08 12:57 ` Russell King - ARM Linux
2015-09-08 14:59 ` Krzysztof Hałasa
2015-09-10 10:25 ` Krzysztof Hałasa
2015-09-10 10:49 ` Russell King - ARM Linux
2015-09-10 11:29 ` Krzysztof Hałasa
2015-09-17 7:21 ` Philipp Zabel
2015-09-17 8:38 ` Krzysztof Hałasa
2015-09-17 9:23 ` Russell King - ARM Linux
2015-09-08 10:45 ` Krzysztof Hałasa
2015-09-08 10:56 ` Lucas Stach
2015-09-08 11:01 ` Russell King - ARM Linux
2015-09-08 11:07 ` Lucas Stach
2015-09-08 11:29 ` Russell King - ARM Linux
2015-09-08 12:43 ` Lucas Stach
2015-09-08 13:40 ` Russell King - ARM Linux
2015-09-08 14:17 ` Robert Nelson
2015-09-08 14:45 ` Krzysztof Hałasa
2015-09-08 14:48 ` Lucas Stach
2015-09-08 15:55 ` Russell King - ARM Linux
2015-09-08 17:07 ` Jon Nettleton
2015-09-08 11:06 ` Krzysztof Hałasa
2015-09-14 8:39 ` Krzysztof Hałasa
2015-09-15 8:24 ` Krzysztof Hałasa
2015-09-15 10:12 ` Russell King - ARM Linux
2015-09-15 11:01 ` Krzysztof Hałasa
2015-09-15 14:29 ` Russell King - ARM Linux [this message]
2015-09-15 16:53 ` Krzysztof Hałasa
2015-09-15 15:53 ` Lucas Stach
2015-09-15 16:36 ` Russell King - ARM Linux
2015-09-15 16:53 ` Lucas Stach
2015-09-15 17:04 ` Russell King - ARM Linux
2015-09-15 19:01 ` Lucas Stach
2015-09-28 14:48 ` xf86-video-armada + etnaviv (Was: Re: I.MX6 HDMI support in v4.2) Lucas Stach
2015-09-28 15:24 ` Russell King - ARM Linux
2015-09-28 15:40 ` Lucas Stach
2015-09-28 16:50 ` Russell King - ARM Linux
2015-09-29 8:28 ` Lucas Stach
2015-09-29 8:41 ` Russell King - ARM Linux
2015-09-29 9:01 ` Lucas Stach
2015-09-15 16:57 ` I.MX6 HDMI support in v4.2 Krzysztof Hałasa
2015-09-16 7:57 ` Krzysztof Hałasa
2015-09-16 15:52 ` Lucas Stach
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=20150915142913.GV21084@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).