On Wed, 30 Mar 2011 11:07:08 -0400, Jerome Glisse wrote:
> What kind of usage didn't played well with synchronous upload/download ? X,
> GL ?
Performing fallback rendering for X using a shadow buffer.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse wrote:
> On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson
> wrote:
> > On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie
> > wrote:
> >> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse
> >> wrote:
> >> > What i had in mind was something little bit
On Wed, Mar 30, 2011 at 10:07 AM, Chris Wilson
wrote:
> On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse
> wrote:
>> On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson
>> wrote:
>> > On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie
>> > wrote:
>> >> On Wed, Mar 30, 2011 at 7:04 AM, Jerome
On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson
wrote:
> On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie wrote:
>> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse wrote:
>> > What i had in mind was something little bit more advance that pwrite,
>> > somethings that would take width,height,pitch
On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie wrote:
> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse wrote:
> > What i had in mind was something little bit more advance that pwrite,
> > somethings that would take width,height,pitch of userpage and would be
> > able to perform proper blit. But
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse wrote:
> On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter wrote:
>> On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
>>> Short lived & small bo would definitly doesn't work well for this kind
>>> of API, it would all be a function of the
On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie airl...@gmail.com wrote:
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse j.gli...@gmail.com wrote:
What i had in mind was something little bit more advance that pwrite,
somethings that would take width,height,pitch of userpage and would be
able
On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie airl...@gmail.com wrote:
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse j.gli...@gmail.com wrote:
What i had in mind was something little bit more advance that pwrite,
On Wed, Mar 30, 2011 at 10:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie
On Wed, 30 Mar 2011 11:07:08 -0400, Jerome Glisse j.gli...@gmail.com wrote:
What kind of usage didn't played well with synchronous upload/download ? X,
GL ?
Performing fallback rendering for X using a shadow buffer.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
? 2011-03-29?? 10:22 -0400?Jerome Glisse???
> Killer solution would be to have no mapping and a decent
> upload/download ioctl that can take userpage.
Doesn't this sound like GEM's read/write interface implemented by e.g.
the i915 driver? But if I understand correctly, a mmap-like interface
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
> Short lived & small bo would definitly doesn't work well for this kind
> of API, it would all be a function of the ioctl cost. But i am not
> sure the drawback would be that big, intel tested with pread/pwrite
> and gived up don't
Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse:
> 2011/3/29 r6144 :
> > ? 2011-03-29?? 10:22 -0400?Jerome Glisse???
> >
> >> Killer solution would be to have no mapping and a decent
> >> upload/download ioctl that can take userpage.
> >
> > Doesn't this sound like GEM's read/write
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter wrote:
> On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
>> Short lived & small bo would definitly doesn't work well for this kind
>> of API, it would all be a function of the ioctl cost. But i am not
>> sure the drawback would be that
On Tue, Mar 29, 2011 at 2:01 PM, Lucas Stach wrote:
> Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse:
>> 2011/3/29 r6144 :
>> > ? 2011-03-29?? 10:22 -0400?Jerome Glisse???
>> >
>> >> Killer solution would be to have no mapping and a decent
>> >> upload/download ioctl that can take
2011/3/29 r6144 :
> ? 2011-03-29?? 10:22 -0400?Jerome Glisse???
>
>> Killer solution would be to have no mapping and a decent
>> upload/download ioctl that can take userpage.
>
> Doesn't this sound like GEM's read/write interface implemented by e.g.
> the i915 driver? But if I understand
On Mon, Mar 28, 2011 at 2:13 PM, Lucas Stach wrote:
> Hi,
>
> I have seen this too in some traces I have done with nouveau nvfx some
> time ago. (The report in kernel bugzilla is a outcome of this.) I'm
> strongly in favour of fixing the kernel side, as I think doing a
> workaround in userspace
On Mon, Mar 28, 2011 at 2:13 PM, Lucas Stach d...@lynxeye.de wrote:
Hi,
I have seen this too in some traces I have done with nouveau nvfx some
time ago. (The report in kernel bugzilla is a outcome of this.) I'm
strongly in favour of fixing the kernel side, as I think doing a
workaround in
2011/3/29 r6144 rainy6...@gmail.com:
在 2011-03-29二的 10:22 -0400，Jerome Glisse写道：
Killer solution would be to have no mapping and a decent
upload/download ioctl that can take userpage.
Doesn't this sound like GEM's read/write interface implemented by e.g.
the i915 driver? But if I
在 2011-03-29二的 10:22 -0400，Jerome Glisse写道：
Killer solution would be to have no mapping and a decent
upload/download ioctl that can take userpage.
Doesn't this sound like GEM's read/write interface implemented by e.g.
the i915 driver? But if I understand correctly, a mmap-like interface
Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse:
2011/3/29 r6144 rainy6...@gmail.com:
在 2011-03-29二的 10:22 -0400，Jerome Glisse写道：
Killer solution would be to have no mapping and a decent
upload/download ioctl that can take userpage.
Doesn't this sound like GEM's
On Tue, Mar 29, 2011 at 2:01 PM, Lucas Stach d...@lynxeye.de wrote:
Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse:
2011/3/29 r6144 rainy6...@gmail.com:
在 2011-03-29二的 10:22 -0400，Jerome Glisse写道：
Killer solution would be to have no mapping and a decent
upload/download
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
Short lived small bo would definitly doesn't work well for this kind
of API, it would all be a function of the ioctl cost. But i am not
sure the drawback would be that big, intel tested with pread/pwrite
and gived up don't
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
Short lived small bo would definitly doesn't work well for this kind
of API, it would all be a function of the ioctl cost. But i am not
sure the drawback would
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
Short lived small bo would definitly doesn't work well for this kind
of API, it would
Hi,
I have seen this too in some traces I have done with nouveau nvfx some
time ago. (The report in kernel bugzilla is a outcome of this.) I'm
strongly in favour of fixing the kernel side, as I think doing a
workaround in userspace is a bad hack. In fact doing so is on my long
"list of things to
Hello,
I am reporting a problem of significant desktop sluggishness caused by
mmap-related kernel algorithms. In particular, after a few days of use,
I encounter multiple-second delays switching between a workspace
containing Evolution and another containing e.g. firefox, which is very
annoying
Hello,
I am reporting a problem of significant desktop sluggishness caused by
mmap-related kernel algorithms. In particular, after a few days of use,
I encounter multiple-second delays switching between a workspace
containing Evolution and another containing e.g. firefox, which is very
annoying
Hi,
I have seen this too in some traces I have done with nouveau nvfx some
time ago. (The report in kernel bugzilla is a outcome of this.) I'm
strongly in favour of fixing the kernel side, as I think doing a
workaround in userspace is a bad hack. In fact doing so is on my long
list of things to
29 matches
Mail list logo
