2012/1/31 Jerome Glisse :
> On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel D?nzer wrote:
>> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
>> > Userspace currently busywaits for fences to complete; on my workload, this
>> > busywait consumes 10% of the available CPU time.
>> >
>> >
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
> > Can you track down who is calling the connector->detect() callbacks
> > during suspend and resume?
>
> I got two different stack traces, see below.
>
> And to slightly amend my statement above, I'm only seeing the wrong
> status
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> Userspace currently busywaits for fences to complete; on my workload, this
> busywait consumes 10% of the available CPU time.
>
> Provide an ioctl so that userspace can wait for an EOP interrupt that
> corresponds to a previous
https://bugs.freedesktop.org/show_bug.cgi?id=28905
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31423
--- Comment #2 from aceman 2012-01-31 10:17:34 PST ---
On R600g, Mesa 8.0rc2 the stars seem to have proper colors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=30502
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
I've been working on
Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/17f2538e/attachment.pgp>
On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
> Hello,
>
> When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
> r600_fence_finish was taking 10% of my CPU time. I determined
Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/radeon/radeon_device.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
+ radeon_bo_kunmap(robj);
> +unpin:
> + radeon_bo_unpin(robj);
> +unreserve:
> + radeon_bo_unreserve(robj);
> +unreference:
> + drm_gem_object_unreference_unlocked(gobj);
> +
> + return r;
> +}
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/a6c775b9/attachment-0001.pgp>
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
> On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> > On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
> >>
> >>
> >> Some comments below.
> >>
> >> > + ? struct radeon_device *rdev = dev->dev_private;
> >> > + ?
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>>
>>
>> Some comments below.
>>
>> > + ? struct radeon_device *rdev = dev->dev_private;
>> > + ? struct drm_gem_object *gobj;
>> > + ? struct radeon_bo *robj;
>> > + ? void
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>
>
> Some comments below.
>
> > + struct radeon_device *rdev = dev->dev_private;
> > + struct drm_gem_object *gobj;
> > + struct radeon_bo *robj;
> > + void *buffer_data;
> > + uint32_t *fence_data;
> > + int r = 0;
> >
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel D?nzer wrote:
> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> > Userspace currently busywaits for fences to complete; on my workload, this
> > busywait consumes 10% of the available CPU time.
> >
> > Provide an ioctl so that
Some comments below.
> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
>
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
This currently doesn't work, hence the debug code piled in.
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
This code needs completion - in particular, we should fall back to
busywaiting (using the nokernel function that's in radeon_drm_bo.c) if the
kernel doesn't support the new interface.
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined experimentally
that changing from sched_yield() to os_time_sleep(10) fixed
ation on these
variables before mailing last time. :(
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/c047449b/attachment.pgp>
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
> Hi Sumit,
>
> > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
>
> [snip]
>
> > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> > *attach,
> > -struct
gt; > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> > *attach, -struct sg_table
*sg)
> > + struct sg_table *sg, enum dma_data_direction
write)
>
> s/write/dir/ (or direction) ?
>
:-) sure.
> > {
> > return;
> > }
>
> --
> Regards,
>
> Laurent Pinchart
Best regards,
-Sumit.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/399047b5/attachment-0001.html>
Hi Sumit,
> On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
> static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> -struct sg_table *sg)
> + struct sg_table *sg, enum dma_data_direction
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
> On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston freedesktop.org> wrote:
>> This fixes a failure in 'make check' found by the tinderbox when trying to
>> build this code on Linux/ppc. This code is only designed to run on
>> Intel
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Dave Airlie changed:
What|Removed |Added
Keywords||regression
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Bug #: 45432
Summary: memory errors on cayman with VM support + nexuiz
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
I'm sorry, my previous patch missed the fact that DP i2c buses are
handled separately so they need the same fix.
drivers/gpu/drm/radeon/radeon_i2c.c |
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
sweep sizes between 1 * to 16K * doubling
the size in each iteration; we get the same coverage, as
On Tue, Jan 31, 2012 at 9:27 AM, Ilija Hadzic
wrote:
>
>
> On Tue, 31 Jan 2012, Alex Deucher wrote:
>
>>>
>>> Signed-off-by: Ilija Hadzic
>>
>>
>> Reviewed-by: Alex Deucher
>>
>
> Thanks. There will be a v3, though to address one tirvial comment
> (whitespace between binary '*' operator) that I
On Mon, Jan 30, 2012 at 11:10 PM, Ilija Hadzic
wrote:
> copy_blit operation works only on integral number of pages
> so benchmarks shorter than one page size (4K) do not make sense
>
> v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
> ? ?sweep sizes between 1x to 16x doubling
> ?
On Tue, Jan 31, 2012 at 3:55 AM, Jean Delvare wrote:
> Properly set the parent device of DP i2c buses before registering them
> too.
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> I'm sorry, my previous patch missed the fact that DP
available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/f3b9dc7d/attachment.pgp>
On Tue, 31 Jan 2012, Alex Deucher wrote:
>>
>> Signed-off-by: Ilija Hadzic
>
> Reviewed-by: Alex Deucher
>
Thanks. There will be a v3, though to address one tirvial comment
(whitespace between binary '*' operator) that I received in E-mail sent
directly to me.
I guess the diff v2/v3 will
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Dave Airlie airl...@gmail.com
Cc: Alex Deucher alexdeuc...@gmail.com
---
I'm sorry, my previous patch missed the fact that DP i2c buses are
handled separately so they need
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
-struct sg_table *sg)
+ struct sg_table *sg, enum dma_data_direction
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Bug #: 45432
Summary: memory errors on cayman with VM support + nexuiz
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Dave Airlie airl...@freedesktop.org changed:
What|Removed |Added
Keywords||regression
--
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
-struct sg_table
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined experimentally
that changing from sched_yield() to os_time_sleep(10) fixed
On Tue, Jan 31, 2012 at 3:55 AM, Jean Delvare jdelv...@suse.de wrote:
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Dave Airlie airl...@gmail.com
Cc: Alex Deucher alexdeuc...@gmail.com
Reviewed-by: Alex Deucher
On Mon, Jan 30, 2012 at 11:10 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of magic 1024 number and
sweep sizes between
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
This code needs completion - in particular, we should fall back to
busywaiting (using the nokernel function that's in radeon_drm_bo.c) if the
kernel doesn't support the new interface.
On Tue, 31 Jan 2012, Alex Deucher wrote:
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Thanks. There will be a v3, though to address one tirvial comment
(whitespace between binary '*' operator) that I received in E-mail
On Tue, Jan 31, 2012 at 9:27 AM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
On Tue, 31 Jan 2012, Alex Deucher wrote:
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Thanks. There will be a v3, though to address one
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
This currently doesn't work, hence the debug code piled in.
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of magic 1024 number and
sweep sizes between 1 * page_size to 16K * page_size doubling
the size in each iteration; we get the
Alex Deucher pointed out an error on IRC; I'm not using
radeon_irq_kms_sw_irq_get and put to manage the IRQ enablement.
I've fixed this up (as per the partial hunk below), and my bug goes away. I
will be cleaning these patches up for proper submission.
Simon
On Tuesday 31 January 2012, Simon
On Tuesday 31 January 2012, Alan Swanson swan...@ukfsn.org wrote:
On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
jerem...@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to
build this code on Linux/ppc. This code is only designed to run on
Intel platforms, so don't even bother building it if we're not in
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous
https://bugs.freedesktop.org/show_bug.cgi?id=30502
aceman aceli...@atlas.sk changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31423
--- Comment #2 from aceman aceli...@atlas.sk 2012-01-31 10:17:34 PST ---
On R600g, Mesa 8.0rc2 the stars seem to have proper colors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=28905
aceman aceli...@atlas.sk changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Some comments below.
+ struct radeon_device *rdev = dev-dev_private;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ void *buffer_data;
+ uint32_t *fence_data;
+ int r = 0;
+ long timeout;
+ int ring = RADEON_RING_TYPE_GFX_INDEX;
+
+ /*
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
Some comments below.
+ struct radeon_device *rdev = dev-dev_private;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ void *buffer_data;
+ uint32_t *fence_data;
+ int r = 0;
+ long timeout;
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
Some comments below.
+ struct radeon_device *rdev = dev-dev_private;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ void
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
Some comments below.
+ struct radeon_device *rdev = dev-dev_private;
+ struct
2012/1/31 Jerome Glisse j.gli...@gmail.com:
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
On Tue, 31 Jan 2012 10:34:38 -0800, Jeremy Huddleston
jerem...@freedesktop.org wrote:
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
jerem...@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when
On -10.01.-28163 20:59, Jerome Glisse wrote:
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glissej.gli...@gmail.com wrote:
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
Some comments below.
+ struct radeon_device
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #11 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-01-31
16:35:53 PST ---
(In reply to comment #10)
(In reply to comment #9)
The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space
https://bugs.freedesktop.org/show_bug.cgi?id=45473
Bug #: 45473
Summary: vdpau-r300 requires softpipe
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #4 from Ian Romanick i...@freedesktop.org 2012-01-31 22:25:22 PST
---
(In reply to comment #2)
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
I can, but it won't be
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
jerem...@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to
build this code on Linux/ppc. This code is only designed to run on
Intel
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
Can you track down who is calling the connector-detect() callbacks
during suspend and resume?
I got two different stack traces, see below.
And to slightly amend my statement above, I'm only seeing the wrong
status returned on
68 matches
Mail list logo
