All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Dave Airlie <airlied@gmail.com>
Cc: "Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/83] AMD HSA kernel driver
Date: Tue, 15 Jul 2014 10:29:33 -0400	[thread overview]
Message-ID: <20140715142931.GA2485@gmail.com> (raw)
In-Reply-To: <CAPM=9txM=0Rd8sP56X1v2sXhAYiRJDoz-j8+N0wXpam-+kYJ8Q@mail.gmail.com>

On Tue, Jul 15, 2014 at 02:35:19PM +1000, Dave Airlie wrote:
> On 14 July 2014 18:37, Christian König <deathsimple@vodafone.de> wrote:
> >> I vote for HSA module that expose ioctl and is an intermediary with the
> >> kernel driver that handle the hardware. This gives a single point for
> >> HSA hardware and yes this enforce things for any hardware manufacturer.
> >> I am more than happy to tell them that this is it and nothing else if
> >> they want to get upstream.
> >
> > I think we should still discuss this single point of entry a bit more.
> >
> > Just to make it clear the plan is to expose all physical HSA capable devices
> > through a single /dev/hsa device node to userspace.
> 
> This is why we don't design kernel interfaces in secret foundations,
> and expect anyone to like them.
> 

I think at this time this is unlikely to get into 3.17. But Christian had
point on having multiple device file. So something like /dev/hsa/*

> So before we go any further, how is this stuff planned to work for
> multiple GPUs/accelerators?

My understanding is that you create queue and each queue is associated
with a device. You can create several queue for same device and have
different priority btw queue.

Btw queue here means a ring buffer that understand a common set of pm4
packet.

> Do we have a userspace to exercise this interface so we can see how
> such a thing would look?

I think we need to wait a bit before freezing and accepting the kernel
api and see enough userspace bits to be confortable. Moreover if AMD
wants common API for HSA i also think that they at very least needs
there HSA partner to make public comment on the kernel API.

Cheers,
Jérôme

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <j.glisse@gmail.com>
To: Dave Airlie <airlied@gmail.com>
Cc: "Christian König" <deathsimple@vodafone.de>,
	"Bridgman, John" <John.Bridgman@amd.com>,
	"Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/83] AMD HSA kernel driver
Date: Tue, 15 Jul 2014 10:29:33 -0400	[thread overview]
Message-ID: <20140715142931.GA2485@gmail.com> (raw)
In-Reply-To: <CAPM=9txM=0Rd8sP56X1v2sXhAYiRJDoz-j8+N0wXpam-+kYJ8Q@mail.gmail.com>

On Tue, Jul 15, 2014 at 02:35:19PM +1000, Dave Airlie wrote:
> On 14 July 2014 18:37, Christian König <deathsimple@vodafone.de> wrote:
> >> I vote for HSA module that expose ioctl and is an intermediary with the
> >> kernel driver that handle the hardware. This gives a single point for
> >> HSA hardware and yes this enforce things for any hardware manufacturer.
> >> I am more than happy to tell them that this is it and nothing else if
> >> they want to get upstream.
> >
> > I think we should still discuss this single point of entry a bit more.
> >
> > Just to make it clear the plan is to expose all physical HSA capable devices
> > through a single /dev/hsa device node to userspace.
> 
> This is why we don't design kernel interfaces in secret foundations,
> and expect anyone to like them.
> 

I think at this time this is unlikely to get into 3.17. But Christian had
point on having multiple device file. So something like /dev/hsa/*

> So before we go any further, how is this stuff planned to work for
> multiple GPUs/accelerators?

My understanding is that you create queue and each queue is associated
with a device. You can create several queue for same device and have
different priority btw queue.

Btw queue here means a ring buffer that understand a common set of pm4
packet.

> Do we have a userspace to exercise this interface so we can see how
> such a thing would look?

I think we need to wait a bit before freezing and accepting the kernel
api and see enough userspace bits to be confortable. Moreover if AMD
wants common API for HSA i also think that they at very least needs
there HSA partner to make public comment on the kernel API.

Cheers,
Jérôme



  reply	other threads:[~2014-07-15 14:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 21:45 [PATCH 00/83] AMD HSA kernel driver Oded Gabbay
2014-07-10 22:24 ` Jerome Glisse
2014-07-10 22:24   ` Jerome Glisse
2014-07-10 22:51   ` Gabbay, Oded
2014-07-10 22:51     ` Gabbay, Oded
2014-07-11 21:18     ` Jerome Glisse
2014-07-11 21:18       ` Jerome Glisse
2014-07-12  9:24       ` Christian König
2014-07-12 11:10         ` Daniel Vetter
2014-07-12 11:10           ` Daniel Vetter
2014-07-12 16:49           ` Jerome Glisse
2014-07-13  9:42             ` Daniel Vetter
2014-07-13  9:42               ` Daniel Vetter
2014-07-13 16:40               ` Jerome Glisse
2014-07-13 16:40                 ` Jerome Glisse
2014-07-23 23:57                 ` Jesse Barnes
2014-07-24  7:16                   ` Daniel Vetter
2014-07-12 21:55       ` Gabbay, Oded
2014-07-12 21:55         ` Gabbay, Oded
2014-07-13  3:55         ` Jerome Glisse
2014-07-13  3:55           ` Jerome Glisse
2014-07-13 15:34           ` Bridgman, John
2014-07-13 15:34             ` Bridgman, John
2014-07-13 16:49             ` Jerome Glisse
2014-07-13 16:49               ` Jerome Glisse
2014-07-14  8:37               ` Christian König
2014-07-14  8:37                 ` Christian König
2014-07-15  4:35                 ` Dave Airlie
2014-07-15  4:35                   ` Dave Airlie
2014-07-15 14:29                   ` Jerome Glisse [this message]
2014-07-15 14:29                     ` Jerome Glisse
2014-07-15 17:06                   ` Bridgman, John
2014-07-15 17:06                     ` Bridgman, John
2014-07-15 17:23                     ` Bridgman, John
2014-07-15 17:23                       ` Bridgman, John
2014-07-15 17:37                     ` Jerome Glisse
2014-07-15 17:37                       ` Jerome Glisse
2014-07-15 17:53                       ` Bridgman, John
2014-07-15 17:53                         ` Bridgman, John
2014-07-15 18:04                         ` Jerome Glisse
2014-07-15 18:04                           ` Jerome Glisse
2014-07-16  8:27                           ` Daniel Vetter
2014-07-16  8:27                             ` Daniel Vetter
2014-07-16 14:52                             ` Jerome Glisse
2014-07-16 14:52                               ` Jerome Glisse
2014-07-16 15:25                               ` Daniel Vetter
2014-07-16 15:25                                 ` Daniel Vetter
2014-07-16  8:21                         ` Daniel Vetter
2014-07-16  8:21                           ` Daniel Vetter
2014-07-16 19:02                           ` Greg KH
2014-07-16 19:02                             ` Greg KH

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=20140715142931.GA2485@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Andrew.Lewycky@amd.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.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 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.