From: Alyssa Rosenzweig <email@example.com> To: Steven Price <firstname.lastname@example.org> Cc: Rob Herring <email@example.com>, Tomeu Vizoso <firstname.lastname@example.org>, Neil Armstrong <email@example.com>, Maxime Ripard <firstname.lastname@example.org>, Robin Murphy <email@example.com>, Will Deacon <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, David Airlie <email@example.com>, firstname.lastname@example.org, "Marty E . Plummer" <email@example.com>, Sean Paul <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver Date: Fri, 5 Apr 2019 09:53:28 -0700 Message-ID: <20190405165328.GA9532@rosenzweig.io> (raw) In-Reply-To: <firstname.lastname@example.org> > Sorry - "Thread Local Storage" - e.g. registers spilled to memory from a > shader program. Gotcha, thank you. Register spilling isn't implemented yet, so I haven't run into this. (Partially because the blob's RA is very good so it's somewhat nontrivial to get it to spill... not that I've tried, the real reason is that the RA I have implemented right now works and I don't want to mess with it ;P) > At the moment I don't have any permission to share details which aren't > already public in the kbase driver. Hopefully that situation will > change. I'm also very much not an expert on anything but the kernel > driver (I tried to stay away from shader compilers and all that graphics > knowledge...). The details of the job descriptors is only really > publicly documented in terms of the "replay workaround" which is quite > limited. Alright, no worries! We'll see where the tide turns, indeed :) > I think we all felt like that :) Still the Nexus 10 wasn't a bad tablet, > and the Chromebook was an exciting first! *looks around to 2 Kevins and 2 Veyrons sprawled about* At first, indeeed.... ;) > You should be able to express the dependencies using fences. At the time > kbase was started there was no fence mechanism in the kernel. We > invented horrible things like UMP and KDS for cross-driver sharing. Ah-ha, I see; I didn't know if there was an explicit reason kbase didn't use fencing, but if it didn't exist, that's reason enough. > It all comes down to how small your job chains are - if you don't need > to squeeze too many through the hardware you should be fine. But there's > going to be some performance gain to be had implementing it. For sure. >  I forget what it actually stands for, but was an attempt to do > something like dma_buf Unified Memory Provider, iirc. > If you don't implement the replay workaround I'm very happy :) Pff. > The main missing part for the Arm user space is feature registers. That > and the lack of SAME_VA is horrible to emulate (keep allocating until it > happens to land in a free area of user space memory). Alright, both of those will probably be needed for us sooner or later, so no harm in implementing those. Thank you! > Arm user space also makes use of cached memory with explicit cache sync > operations. It of course works fine with uncached and ignoring the sync, > but again I'm not sure how much performance is being lost. I would be interested as well, since even when I used kbase for stuff, I set everything uncached/unsynced to keep myself sane, but that could be a very real performance issue on some workloads.
next prev parent reply index Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-01 7:47 [PATCH v2 0/3] Initial Panfrost driver Rob Herring 2019-04-01 7:47 ` [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format Rob Herring 2019-04-01 19:11 ` Robin Murphy 2019-04-05 10:02 ` Robin Murphy 2019-04-11 13:15 ` Joerg Roedel 2019-04-05 9:42 ` Steven Price 2019-04-05 9:51 ` Robin Murphy 2019-04-05 10:36 ` Steven Price 2019-04-08 8:56 ` Steven Price 2019-04-01 7:47 ` [PATCH v2 2/3] drm: Add a drm_gem_objects_lookup helper Rob Herring 2019-04-01 13:06 ` Daniel Vetter 2019-04-01 13:48 ` Chris Wilson 2019-04-01 15:43 ` Eric Anholt 2019-04-08 20:09 ` Rob Herring 2019-04-09 16:55 ` Eric Anholt 2019-04-01 16:59 ` Rob Herring 2019-04-01 18:22 ` Eric Anholt 2019-04-01 7:47 ` [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver Rob Herring 2019-04-01 8:24 ` Neil Armstrong 2019-04-01 19:17 ` Robin Murphy 2019-04-01 16:02 ` Eric Anholt 2019-04-01 19:12 ` Robin Murphy 2019-04-02 0:33 ` Alyssa Rosenzweig 2019-04-02 11:23 ` Robin Murphy 2019-04-03 4:57 ` Rob Herring 2019-04-05 12:57 ` Robin Murphy 2019-04-05 12:30 ` Steven Price 2019-04-05 16:16 ` Alyssa Rosenzweig 2019-04-05 16:42 ` Steven Price 2019-04-05 16:53 ` Alyssa Rosenzweig [this message] 2019-04-15 9:18 ` Daniel Vetter 2019-04-15 9:30 ` Steven Price 2019-04-16 7:51 ` Daniel Vetter 2019-04-08 21:04 ` Rob Herring 2019-04-09 15:56 ` Tomeu Vizoso 2019-04-09 16:15 ` Rob Herring 2019-04-10 10:28 ` Steven Price 2019-04-10 10:19 ` Steven Price 2019-04-10 11:50 ` Tomeu Vizoso 2019-04-01 15:05 ` [PATCH v2 0/3] Initial Panfrost driver Alyssa Rosenzweig
Reply instructions: You may reply publically 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=20190405165328.GA9532@rosenzweig.io \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git