Alright then.
Dave, if you are reading this, feel free not to include the two
patches I sent you in the next pull request.
Marek
On Mon, Oct 24, 2011 at 7:28 PM, Thomas Hellstrom
wrote:
> Marek,
>
> The problem is that the patch adds a lot of complicated code where it's not
> needed, and I
Marek,
The problem is that the patch adds a lot of complicated code where it's
not needed, and I don't want to end up reverting that code and
re-implementing the new Radeon gem ioctl by myself.
Having a list of two fence objects and waiting for either of them
shouldn't be that complicated to
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the
On 10/24/2011 06:42 PM, Marek Ol??k wrote:
> On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom
> wrote:
>
>> On 10/08/2011 01:27 PM, Ville Syrj?l? wrote:
>>
>>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>>
>>>
On 10/08/2011 12:26 PM, Ville Syrj?l?
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom wrote:
> On 10/08/2011 01:27 PM, Ville Syrj?l? wrote:
>>
>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>
>>>
>>> On 10/08/2011 12:26 PM, Ville Syrj?l? wrote:
>>>
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas
On 10/08/2011 12:03 AM, Marek Ol??k wrote:
> On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom
> wrote:
>
>> OK. First I think we need to make a distinction: bo sync objects vs driver
>> fences. The bo sync obj api is there to strictly provide functionality that
>> the ttm bo subsystem is
On 10/08/2011 12:03 AM, Marek Olšák wrote:
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstromtho...@shipmail.org wrote:
OK. First I think we need to make a distinction: bo sync objects vs driver
fences. The bo sync obj api is there to strictly provide functionality that
the ttm bo subsystem
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas
On 10/24/2011 06:42 PM, Marek Olšák wrote:
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstromtho...@shipmail.org wrote:
On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the
Marek,
The problem is that the patch adds a lot of complicated code where it's
not needed, and I don't want to end up reverting that code and
re-implementing the new Radeon gem ioctl by myself.
Having a list of two fence objects and waiting for either of them
shouldn't be that complicated
Alright then.
Dave, if you are reading this, feel free not to include the two
patches I sent you in the next pull request.
Marek
On Mon, Oct 24, 2011 at 7:28 PM, Thomas Hellstrom tho...@shipmail.org wrote:
Marek,
The problem is that the patch adds a lot of complicated code where it's not
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
> On 10/08/2011 12:26 PM, Ville Syrj?l? wrote:
> > On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
> >
> >> Oh, and one more style comment below:
> >>
> >> On 08/07/2011 10:39 PM, Marek Ol??k wrote:
> >>
On 10/08/2011 01:27 PM, Ville Syrj?l? wrote:
> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>
>> On 10/08/2011 12:26 PM, Ville Syrj?l? wrote:
>>
>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>
>>>
Oh, and one more style comment
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
> Oh, and one more style comment below:
>
> On 08/07/2011 10:39 PM, Marek Ol??k wrote:
> >
> > +enum ttm_buffer_usage {
> > +TTM_USAGE_READ = 1,
> > +TTM_USAGE_WRITE = 2,
> > +TTM_USAGE_READWRITE = TTM_USAGE_READ |
On 10/08/2011 12:26 PM, Ville Syrj?l? wrote:
> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>
>> Oh, and one more style comment below:
>>
>> On 08/07/2011 10:39 PM, Marek Ol??k wrote:
>>
>>> +enum ttm_buffer_usage {
>>> +TTM_USAGE_READ = 1,
>>> +
On 10/07/2011 11:30 PM, Marek Ol??k wrote:
> On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse wrote:
>
>> I should have look at the patch long ago ... anyway i think a better
>> approach would be to expose fence id as 64bits unsigned to each
>> userspace client. I was thinking of mapping a page
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom
wrote:
> OK. First I think we need to make a distinction: bo sync objects vs driver
> fences. The bo sync obj api is there to strictly provide functionality that
> the ttm bo subsystem is using, and that follows a simple set of rules:
>
> 1) the
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse wrote:
> I should have look at the patch long ago ... anyway i think a better
> approach would be to expose fence id as 64bits unsigned to each
> userspace client. I was thinking of mapping a page readonly (same page
> as the one gpu write back) at
On Fri, Oct 7, 2011 at 3:42 PM, Jerome Glisse wrote:
> Forget to mention that we would need a new wait_fence ioctl to wait
> for a specific fence seq on a specific ring
We need a wait_fence ioctl anyway and even with a timeout parameter.
It's a mandatory OpenGL feature. r600g uses a loop with
On 10/07/2011 11:30 PM, Marek Olšák wrote:
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glissej.gli...@gmail.com wrote:
I should have look at the patch long ago ... anyway i think a better
approach would be to expose fence id as 64bits unsigned to each
userspace client. I was thinking of mapping
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum ttm_buffer_usage {
+TTM_USAGE_READ = 1,
+TTM_USAGE_WRITE = 2,
+TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum ttm_buffer_usage {
+TTM_USAGE_READ = 1,
+TTM_USAGE_WRITE = 2,
+
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum
On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
Oh, and one more style comment below:
On 08/07/2011
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the
On 10/07/2011 03:24 PM, Alex Deucher wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Ol??k wrote:
>
> +enum ttm_buffer_usage {
> +TTM_USAGE_READ = 1,
> +TTM_USAGE_WRITE = 2,
> +TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
> +};
>
>
Please don't use enums for bit operations.
#define
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom
wrote:
> On 10/07/2011 03:24 PM, Alex Deucher wrote:
>>
>> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
On 10/07/2011 12:42 AM, Marek Ol??k wrote:
> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
> wrote:
>
>> In any case, I'm not saying fences is the best way to flush but since the bo
>> code assumes that signaling a sync object means "make the buffer contents
>> available for CPU read /
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> ?wrote:
>>>
In any case, I'm not saying fences is the best way to
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote:
> In any case, I'm not saying fences is the best way to flush but since the bo
> code assumes that signaling a sync object means "make the buffer contents
> available for CPU read / write", it's usually a good way to do it; there's
> even a
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org wrote:
In any case, I'm not saying fences is the best way to flush but since the bo
code assumes that signaling a sync object means make the buffer contents
available for CPU read
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum ttm_buffer_usage {
+TTM_USAGE_READ = 1,
+TTM_USAGE_WRITE = 2,
+TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
+};
Please don't use enums for bit operations.
#define
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences is the best way to flush but since the
bo
code assumes that
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences is the best way to flush but since the
bo
code assumes that
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not
On 10/07/2011 03:24 PM, Alex Deucher wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 03:24 PM, Alex Deucher wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org
wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse j.gli...@gmail.com wrote:
I should have look at the patch long ago ... anyway i think a better
approach would be to expose fence id as 64bits unsigned to each
userspace client. I was thinking of mapping a page readonly (same page
as the one gpu
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
OK. First I think we need to make a distinction: bo sync objects vs driver
fences. The bo sync obj api is there to strictly provide functionality that
the ttm bo subsystem is using, and that follows a simple set of
On 10/05/2011 04:08 AM, Marek Ol??k wrote:
> On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom
> wrote:
>
>> Bah, I totally missed this patch and thus never reviewed it :( Probably on
>> vacation.
>>
>> There are a couple of things I'd like to point out.
>>
>> 1) The bo subsystem may never
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom wrote:
> Bah, I totally missed this patch and thus never reviewed it :( Probably on
> vacation.
>
> There are a couple of things I'd like to point out.
>
> 1) The bo subsystem may never assume that fence objects are ordered, so that
> when we unref
On 08/07/2011 10:39 PM, Marek Ol??k wrote:
> Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
> However, sometimes it would be more useful to be able to query whether
> a buffer is busy and being either read or written, and wait until it's stopped
> being either read
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom tho...@shipmail.org wrote:
Bah, I totally missed this patch and thus never reviewed it :( Probably on
vacation.
There are a couple of things I'd like to point out.
1) The bo subsystem may never assume that fence objects are ordered, so that
On 10/05/2011 04:08 AM, Marek Olšák wrote:
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstromtho...@shipmail.org wrote:
Bah, I totally missed this patch and thus never reviewed it :( Probably on
vacation.
There are a couple of things I'd like to point out.
1) The bo subsystem may never
On Fri, Aug 12, 2011 at 7:21 PM, Jerome Glisse wrote:
>> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> index 3832fe1..0438296 100644
>> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> @@ -223,6
On Sun, Aug 7, 2011 at 4:39 PM, Marek Ol??k wrote:
> Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
> However, sometimes it would be more useful to be able to query whether
> a buffer is busy and being either read or written, and wait until it's stopped
> being
On Sun, Aug 7, 2011 at 4:39 PM, Marek Olšák mar...@gmail.com wrote:
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
54 matches
Mail list logo
