On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
wrote:
> The timeline is similar to what I called a fence context. Each command stream
> on a gpu can have a context. Because
> nvidia hardware can have 4095 separate timelines, I didn't want to keep the
> bookkeeping for each timeline, although
On Fri, Mar 1, 2013 at 12:21 AM, Erik Gilling wrote:
> On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote:
>> Given its the sync driver, its most obvious choice, but I agree its likely
>> to collide with filesystem related or other sync_ named functions that don't
>&g
On Fri, Mar 1, 2013 at 12:21 AM, Erik Gilling wrote:
> On Thu, Feb 28, 2013 at 7:59 PM, John Stultz
> wrote:
>> Given its the sync driver, its most obvious choice, but I agree its likely
>> to collide with filesystem related or other sync_ named functions that don't
>
On Fri, Mar 1, 2013 at 5:55 AM, Greg KH wrote:
> On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote:
>> As John pointed out, the exynos and msm display and code uses them. I
>> know nvidia is working on adding suport to their tegra tree. My knee
>> jerk reaction
On Fri, Mar 1, 2013 at 5:55 AM, Greg KH wrote:
> On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote:
>> As John pointed out, the exynos and msm display and code uses them. I
>> know nvidia is working on adding suport to their tegra tree. My knee
>> jerk reaction
On Thu, Feb 28, 2013 at 5:59 PM, Greg KH wrote:
> On Thu, Feb 28, 2013 at 04:42:56PM -0800, John Stultz wrote:
>> Erik also provided a nice background on the patch set in his
>> reply yesterday, which I'll quote here:
>
> Mind if I put that in the 1/30 changelog body for future people to see?
Ple
On Thu, Feb 28, 2013 at 5:59 PM, Greg KH wrote:
> On Thu, Feb 28, 2013 at 04:42:56PM -0800, John Stultz wrote:
>> Erik also provided a nice background on the patch set in his
>> reply yesterday, which I'll quote here:
>
> Mind if I put that in the 1/30 changelog body for future people to see?
Ple
On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote:
>>> +EXPORT_SYMBOL(sync_timeline_create);
>>
>> As these are now global, should they be a bit more "specific"? "sync_"
>> seems pretty broad.
>
>
> Given its the sync driver, its most obvious choice, but I agree its likely
> to collide with file
On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote:
>>> +EXPORT_SYMBOL(sync_timeline_create);
>>
>> As these are now global, should they be a bit more "specific"? "sync_"
>> seems pretty broad.
>
>
> Given its the sync driver, its most obvious choice, but I agree its likely
> to collide with file
On Wed, Feb 27, 2013 at 6:14 PM, John Stultz wrote:
> Also note: I've done this so far without any feedback from the Android devs
> (despite my reaching out to Erik a few times recently), so if they object to
> pushing it to staging, in deference to it being their code I'll back off,
> even though
On Wed, Feb 27, 2013 at 6:14 PM, John Stultz wrote:
> Also note: I've done this so far without any feedback from the Android devs
> (despite my reaching out to Erik a few times recently), so if they object to
> pushing it to staging, in deference to it being their code I'll back off,
> even though
On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter wrote:
>> I think this is an approach worth investigating. I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it. Actually, that could work really
>> well. Consider:
>>
>> * Ea
On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> The alternate is to not associate sync objects with buffers and
> have them be distinct entities, exposed to userspace. This gives
> userpsace more power and flexibility and might allow for use-cases
> which an implicit synchronization mechanism
On Thu, Jun 7, 2012 at 10:52 AM, Maarten Lankhorst
wrote:
> I do agree you need some way to synch userspace though, but I
> think adding a new api for userspace is not the way to go.
I'm not sure I understand how you propose to expose the functionality
to userspace in a way that does not depend o
On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter wrote:
>> I think this is an approach worth investigating. ?I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it. ?Actually, that could work really
>> well. Consider:
>>
>> * Ea
On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> The alternate is to not associate sync objects with buffers and
> have them be distinct entities, exposed to userspace. This gives
> userpsace more power and flexibility and might allow for use-cases
> which an implicit synchronization mechanism
On Thu, Jun 7, 2012 at 10:52 AM, Maarten Lankhorst
wrote:
> I do agree you need some way to synch userspace though, but I
> think adding a new api for userspace is not the way to go.
I'm not sure I understand how you propose to expose the functionality
to userspace in a way that does not depend o
On Wed, Jun 6, 2012 at 6:33 AM, John Reitan wrote:
>> But maybe instead of inventing something new, we can just use 'struct
>> kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
>> If the user needs some extra args they can embed 'struct
>> kthread_work' in their own struct an
On Wed, Jun 6, 2012 at 6:33 AM, John Reitan wrote:
>> But maybe instead of inventing something new, we can just use 'struct
>> kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
>> ?If the user needs some extra args they can embed 'struct
>> kthread_work' in their own struct an
19 matches
Mail list logo
