Re: [PATCH] drm: introduce drm_can_sleep and use in intel/radeon drivers.

2012-01-06 Thread Dave Airlie 
>>
>> So we have a few places where the drm drivers would like to sleep to
>> be nice to the system, mainly in the modesetting paths, but we also
>> have two cases were atomic modesetting must take place, panic writing
>> and kernel debugger. So provide a central inline to determine if a
>> sleep or delay should be used and use this in the intel and radeon drivers.
>>
>> Based on patch from Michel Dänzer 
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>>
>> Signed-off-by: Dave Airlie 
>
> If MSLEEP is indeed unused, I think it should just die - we have way too
> much yelling cruft from dri1 yonder lying around that hides important
> details like this. Otherwise
>
> Reviewed-by: Daniel Vetter 

I've pushed the version that just drops MSLEEP since nobody used it.

Thanks,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Dave Airlie 
On Fri, Jan 6, 2012 at 3:11 AM,   wrote:
> From: Jerome Glisse 
>
> Virtual address space are per drm client (opener of /dev/drm).
> Client are in charge of virtual address space, they need to
> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>
> First 16M of virtual address space is reserved by the kernel.
>
> Once using 2 level page table we should be able to have a small
> vram memory footprint for each pt (there would be one pt for all
> gart, one for all vram and then one first level for each virtual
> address space).
>
> Plan include using the sub allocator for a common vm page table
> area and using memcpy to copy vm page table in & out. Or use
> a gart object and copy things in & out using dma.

Pushed all 3.

What happens if someone calls the VA ioctl on a non-VM system btw?

If thats an issue, please provide a follow up patch.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: merge window closed

2012-01-06 Thread Dave Airlie 
On Fri, Jan 6, 2012 at 2:24 AM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Jan 05, 2012 at 10:48:10AM +, Dave Airlie wrote:
>> Hi
>>
>> So Linus has released, so really whats in -next is really it
>>
>> I've two things outstanding,
>> the TTM/AGP fixes, from Jerome/Konrad, guys please cross-review asap,
>
> OK, so the two I posted:
>
> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
> don't try to free freed pages.
> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
>
> Should go in. Jerome took a look at both of them and Reviewed them.
>
> He has also posted:
> ttm: fix agp since ttm tt rework
>
> which looks OK to me and should have the Reviewed-by me flag stuck on. Let
> me respond to Jerome's email on that.
>
> Now on the move_notify work, that still does not work properly with nouveau.
> Ben did some work with ""drm/nouveau/ttm: fix crash as a result of a recent 
> ttm change"
> but I can still get the machine to crash so will have to dig on this a bit 
> more.

Okay I've merged the 3 you've mentioned here,

The move notify stuff if its still an issue please work it out with
Ben, all his stuff is in -core-next already.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44523] New: nexuiz perf regression since u_vbuf: implement another upload codepath which unrolls indices

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44523

 Bug #: 44523
   Summary: nexuiz perf regression since u_vbuf: implement another
upload codepath which unrolls indices
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: li...@andyfurniss.entadsl.com


d-r-t kernel, HD4890.

Since -

commit ce44bae366ade59fb2dbdfbfe5a1ab8d24518a57
Author: Marek Olšák 
Date:   Tue Jan 3 22:01:03 2012 +0100

u_vbuf: implement another upload codepath which unrolls indices

Improves performance from cca 1 fps to 23 fps in Cogs.
This new codepath is not always used, instead, there is a heuristic which
determines whether to use it. Using translate for uploads is generally
slower than what we have had already, it's a win only in a few cases.

I get quite a noticeable perf regression running demo1 in nexuiz.

Other games (openarena,ut2004 demo, etqw) seem unaffected 


91.2740132 fps, one-second fps min/avg/max: 50 99 231 (90 seconds)

to

55.6802612 fps, one-second fps min/avg/max: 19 69 231 (90 seconds)

Sometimes I saw a couple of short (1/4 sec) stalls as well, which gave worse
results, above was without stalls.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44032] drm-core-next + RV790 + ETQW = WARNING bisected

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44032

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Andy Furniss  2012-01-06 
04:07:24 PST ---
I can't trigger this with today's drm-core-next.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Christian König 

On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
[SNIP]

  #define RADEON_CHUNK_ID_RELOCS0x01
  #define RADEON_CHUNK_ID_IB0x02
  #define RADEON_CHUNK_ID_FLAGS 0x03

  /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
  #define RADEON_CS_KEEP_TILING_FLAGS 0x01
+#define RADEON_CS_USE_VM0x02
+/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the ring 
type */
+#define RADEON_CS_RING_GFX  0
+#define RADEON_CS_RING_COMPUTE  1
+/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
+/* 0 = normal, + = higher priority, - = lower priority */
+struct drm_radeon_cs_ring_priority {
+   int32_t priority;
+};
Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" 
is pretty much pointless.


My comment was going more into that direction:
struct drm_radeon_cs_flags {
uint32_t  flags;
uint32_t  ring_type;
int32_tpriority;
};

Anyway, the patch is finally committed, but I think we should fix 
(remove?) that before it goes further upstream.


Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
2012/1/6 Christian König :
> On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
> [SNIP]
>
>>  #define RADEON_CHUNK_ID_RELOCS        0x01
>>  #define RADEON_CHUNK_ID_IB    0x02
>>  #define RADEON_CHUNK_ID_FLAGS 0x03
>>
>>  /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
>> */
>>  #define RADEON_CS_KEEP_TILING_FLAGS 0x01
>> +#define RADEON_CS_USE_VM            0x02
>> +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
>> ring type */
>> +#define RADEON_CS_RING_GFX          0
>> +#define RADEON_CS_RING_COMPUTE      1
>> +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
>> priority */
>> +/* 0 = normal, + = higher priority, - = lower priority */
>> +struct drm_radeon_cs_ring_priority {
>> +       int32_t                 priority;
>> +};
>
> Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" is
> pretty much pointless.

I didn't have a struct for priority before, but someone suggested it
would be clearer what the 3rd dword was used for if I added a struct.
Basically just treat the third flag dword as a signed int32.

>
> My comment was going more into that direction:
> struct drm_radeon_cs_flags {
>    uint32_t      flags;
>    uint32_t      ring_type;
>    int32_t        priority;
> };
>
> Anyway, the patch is finally committed, but I think we should fix (remove?)
> that before it goes further upstream.

Would there be any issues if we need to extend the stuct to add an
extra field later?  Also, not all of the fields are necessary.  You
can just allocate 1 dword if you just need the flags dword.  I've fine
to just drop the struct.

Alex

>
> Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
On Fri, Jan 6, 2012 at 5:09 AM, Dave Airlie  wrote:
> On Fri, Jan 6, 2012 at 3:11 AM,   wrote:
>> From: Jerome Glisse 
>>
>> Virtual address space are per drm client (opener of /dev/drm).
>> Client are in charge of virtual address space, they need to
>> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>>
>> First 16M of virtual address space is reserved by the kernel.
>>
>> Once using 2 level page table we should be able to have a small
>> vram memory footprint for each pt (there would be one pt for all
>> gart, one for all vram and then one first level for each virtual
>> address space).
>>
>> Plan include using the sub allocator for a common vm page table
>> area and using memcpy to copy vm page table in & out. Or use
>> a gart object and copy things in & out using dma.
>
> Pushed all 3.
>
> What happens if someone calls the VA ioctl on a non-VM system btw?
>
> If thats an issue, please provide a follow up patch.


I'll double check.

Alex

>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon/kms: check if vm is supported in VA ioctl

2012-01-06 Thread alexdeucher 
From: Alex Deucher 

Add a VM manager enabled field and use it to check if
vm is enabled.

Signed-off-by: Alex Deucher 
Cc: jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon.h  |2 ++
 drivers/gpu/drm/radeon/radeon_cs.c   |4 ++--
 drivers/gpu/drm/radeon/radeon_gart.c |   10 +-
 drivers/gpu/drm/radeon/radeon_gem.c  |5 +
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7cb63cd..73e05cb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -668,6 +668,8 @@ struct radeon_vm_manager {
unsignednvm;
/* vram base address for page table entry  */
u64 vram_base_offset;
+   /* is vm enabled? */
+   boolenabled;
 };
 
 /*
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 17af0e8..435a3d9 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -234,8 +234,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
}
 
if ((p->cs_flags & RADEON_CS_USE_VM) &&
-   (p->rdev->family < CHIP_CAYMAN)) {
-   DRM_ERROR("VM not supported on asic!\n");
+   !p->rdev->vm_manager.enabled) {
+   DRM_ERROR("VM not active on asic!\n");
if (p->chunk_relocs_idx != -1)
kfree(p->chunks[p->chunk_relocs_idx].kdata);
if (p->chunk_flags_idx != -1)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 3ef58ca..8597d2c 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -286,6 +286,8 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 {
int r;
 
+   rdev->vm_manager.enabled = false;
+
/* mark first vm as always in use, it's the system one */
r = radeon_sa_bo_manager_init(rdev, &rdev->vm_manager.sa_manager,
  rdev->vm_manager.max_pfn * 8,
@@ -295,7 +297,12 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
(rdev->vm_manager.max_pfn * 8) >> 10);
return r;
}
-   return rdev->vm_manager.funcs->init(rdev);
+
+   r = rdev->vm_manager.funcs->init(rdev);
+   if (r == 0)
+   rdev->vm_manager.enabled = true;
+
+   return r;
 }
 
 /* cs mutex must be lock */
@@ -334,6 +341,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
radeon_vm_manager_suspend(rdev);
rdev->vm_manager.funcs->fini(rdev);
radeon_sa_bo_manager_fini(rdev, &rdev->vm_manager.sa_manager);
+   rdev->vm_manager.enabled = false;
 }
 
 int radeon_vm_manager_start(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 003eeec..7337850 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -404,6 +404,11 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
u32 invalid_flags;
int r = 0;
 
+   if (!rdev->vm_manager.enabled) {
+   args->operation = RADEON_VA_RESULT_ERROR;
+   return -ENOTTY;
+   }
+
/* !! DONT REMOVE !!
 * We don't support vm_id yet, to be sure we don't have have broken
 * userspace, reject anyone trying to use non 0 value thus moving
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon/kms: remove pointless CS flags priority struct

2012-01-06 Thread alexdeucher 
From: Alex Deucher 

Signed-off-by: Alex Deucher 
Cc: Christian König 
---
 include/drm/radeon_drm.h |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 2a807a5..b55da40 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -907,9 +907,6 @@ struct drm_radeon_gem_va {
 #define RADEON_CS_RING_COMPUTE  1
 /* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
 /* 0 = normal, + = higher priority, - = lower priority */
-struct drm_radeon_cs_ring_priority {
-   int32_t priority;
-};
 
 struct drm_radeon_cs_chunk {
uint32_tchunk_id;
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Christian König 

On 06.01.2012 15:12, Alex Deucher wrote:

2012/1/6 Christian König:

On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
[SNIP]


  #define RADEON_CHUNK_ID_RELOCS0x01
  #define RADEON_CHUNK_ID_IB0x02
  #define RADEON_CHUNK_ID_FLAGS 0x03

  /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
*/
  #define RADEON_CS_KEEP_TILING_FLAGS 0x01
+#define RADEON_CS_USE_VM0x02
+/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
ring type */
+#define RADEON_CS_RING_GFX  0
+#define RADEON_CS_RING_COMPUTE  1
+/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
priority */
+/* 0 = normal, + = higher priority, - = lower priority */
+struct drm_radeon_cs_ring_priority {
+   int32_t priority;
+};

Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" is
pretty much pointless.

I didn't have a struct for priority before, but someone suggested it
would be clearer what the 3rd dword was used for if I added a struct.
Basically just treat the third flag dword as a signed int32.
Yeah that suggestion came from me, but what I had in mind was a 
structure for the whole flags chunk, instead of just the priority field.



My comment was going more into that direction:
struct drm_radeon_cs_flags {
uint32_t  flags;
uint32_t  ring_type;
int32_tpriority;
};

Anyway, the patch is finally committed, but I think we should fix (remove?)
that before it goes further upstream.

Would there be any issues if we need to extend the stuct to add an
extra field later?  Also, not all of the fields are necessary.  You
can just allocate 1 dword if you just need the flags dword.  I've fine
to just drop the struct.

Well, using structs as interface definitions has always suffered from 
those problems, e. g. for compatibility you can only extend it at the 
end, members might have ambiguous sizes, members might be packed 
differently.  I'm still just prefering them because they are machine 
readable, instead of human readable comments, and machines tend to 
produce less bugs than humans while calculations memory offsets...


But I don't have enough experience with kernel interfaces to favor one 
style of coding over another, so if you think it's ok to drop it then 
just go ahead. I just wanted to note that there was a misunderstanding.


Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
2012/1/6 Christian König :
> On 06.01.2012 15:12, Alex Deucher wrote:
>>
>> 2012/1/6 Christian König:
>>>
>>> On -10.01.-28163 20:59, alexdeuc...@gmail.com wrote:
>>> [SNIP]
>>>
  #define RADEON_CHUNK_ID_RELOCS        0x01
  #define RADEON_CHUNK_ID_IB    0x02
  #define RADEON_CHUNK_ID_FLAGS 0x03

  /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
 */
  #define RADEON_CS_KEEP_TILING_FLAGS 0x01
 +#define RADEON_CS_USE_VM            0x02
 +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
 ring type */
 +#define RADEON_CS_RING_GFX          0
 +#define RADEON_CS_RING_COMPUTE      1
 +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
 priority */
 +/* 0 = normal, + = higher priority, - = lower priority */
 +struct drm_radeon_cs_ring_priority {
 +       int32_t                 priority;
 +};
>>>
>>> Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority"
>>> is
>>> pretty much pointless.
>>
>> I didn't have a struct for priority before, but someone suggested it
>> would be clearer what the 3rd dword was used for if I added a struct.
>> Basically just treat the third flag dword as a signed int32.
>
> Yeah that suggestion came from me, but what I had in mind was a structure
> for the whole flags chunk, instead of just the priority field.
>
>
>>> My comment was going more into that direction:
>>> struct drm_radeon_cs_flags {
>>>    uint32_t      flags;
>>>    uint32_t      ring_type;
>>>    int32_t        priority;
>>> };
>>>
>>> Anyway, the patch is finally committed, but I think we should fix
>>> (remove?)
>>> that before it goes further upstream.
>>
>> Would there be any issues if we need to extend the stuct to add an
>> extra field later?  Also, not all of the fields are necessary.  You
>> can just allocate 1 dword if you just need the flags dword.  I've fine
>> to just drop the struct.
>>
> Well, using structs as interface definitions has always suffered from those
> problems, e. g. for compatibility you can only extend it at the end, members
> might have ambiguous sizes, members might be packed differently.  I'm
> still just prefering them because they are machine readable, instead of
> human readable comments, and machines tend to produce less bugs than humans
> while calculations memory offsets...
>
> But I don't have enough experience with kernel interfaces to favor one style
> of coding over another, so if you think it's ok to drop it then just go
> ahead. I just wanted to note that there was a misunderstanding.

I just went ahead and dropped it for now.  I'm open too suggestions
for better approaches though.

Alex

>
> Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] dma-buf tree

2012-01-06 Thread Dave Airlie 

Hi Linus,

This isn't the drm merge, however a few projects have been working 
together on a buffer sharing mechanism for kernel drivers, the maim
interested parties are the Linaro/ARM SoC folks, V4L, DRM, and fbdev.
Sumit Semwal wrote the code, and its been reviewed on various lists a fair 
few times.

Now we've all agreed that the initial implementation is a good baseline 
for us to move forward on, but its messy working with others when the core 
code is out of tree. So we'd like to merge the core dma-buf code now so we 
can all build on top of it for 3.4. I know some people would say we 
shouldn't merge things with no users, but it will really make our lives 
easier going forward to get this baseline into the tree.

Currently I've got most of a drm inter-driver buffer sharing mechanism 
built on top and there is also got a v4l consumer built. The code doesn't 
introduce any new userspace interfaces, its purely a kernel internal 
layer, that the consumer/exported layers like drm/v4l will plug into to 
offer services.

Dave.
 
The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:

  Linux 3.2 (2012-01-04 15:55:44 -0800)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux dma-buf-merge

Sumit Semwal (3):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework
  dma-buf: mark EXPERIMENTAL for 1st release.

 Documentation/dma-buf-sharing.txt |  224 
 drivers/base/Kconfig  |   11 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  291 +
 include/linux/dma-buf.h   |  176 ++
 5 files changed, 703 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

2012-01-06 Thread Jesse Barnes 
On Thu, 05 Jan 2012 19:10:43 -0800
Eric Anholt  wrote:

> On Thu,  5 Jan 2012 14:16:23 -0200, przan...@gmail.com wrote:
> > From: Paulo Zanoni 
> > 
> > This ioctl is used to signal the drivers that the screen is rotated,
> > not to make the drivers rotate the screen.
> >  - add a driver-specific "rotation_set" function
> >  - implement Intel's rotation_set by setting the right values to the
> >PIPECONF registers.
> > 
> > The idea is that when user-space does rotation, it can call this ioctl
> > to inform the Kernel that we have a rotation. This feature is needed
> > by the KVMr feature of VPro.
> 
> So am I following this right, that these register bits are used to
> communicate from one piece of software to another piece of software,
> across the virtualization boundary?

Right, but not for virtualization; these bits are read by the AMT
engine for its built-in KVM functionality.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44524] [radeon driver] Screen corruption when "Applications" has enough apps to have a scrollbar on Gnome Desktop

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44524

Michel Dänzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
  QAContact|xorg-t...@lists.x.org   |
Product|xorg|Mesa
  Component|Driver/Radeon   |Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> > On Thu, 2012-01-05 at 13:31 -0500, j.gli...@gmail.com wrote:
> > > From: Jerome Glisse 
> > > 
> > > ttm might call the move notify with null new mem placement,
> > > properly handle this case inside nouveau move notify callback.
> > This has been fixed already in a -next tree I sent to Dave.
> 
> I just tried -next with your patch (and two other fixes that I had sent):
> 
> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
> don't try to free freed pages
> 
> and Jerome's AGP fix:
> ttm: fix agp since ttm tt rework
> 
> and got the crash (but only with NVidia cards) after swapping between Xorg 
> and the VCs.
> Look in drm-next.jpg

http://darnok.org/vga/drm-next.jpg

> 
> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a recent 
> ttm change")
> and the patch below by Jerome I still get it to crash (see 
> drm-next-with-Jerome-fix-revert-Ben.jpg)..

http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg


> 
> > 
> > Ben.
> > > 
> > > Signed-off-by: Jerome Glisse 
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
> > >  1 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index f12dd0f..65f5b0b 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -808,9 +808,8 @@ out:
> > >  }
> > >  
> > >  static void
> > > -nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> > > *new_mem)
> > > +nouveau_bo_move_notify(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> > > *new_mem)
> > >  {
> > > - struct nouveau_mem *node = new_mem->mm_node;
> > >   struct nouveau_bo *nvbo = nouveau_bo(bo);
> > >   struct nouveau_vma *vma;
> > >  
> > > @@ -820,6 +819,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> > > struct ttm_mem_reg *new_mem)
> > >   } else
> > >   if (new_mem && new_mem->mem_type == TTM_PL_TT &&
> > >   nvbo->page_shift == vma->vm->spg_shift) {
> > > + struct nouveau_mem *node = new_mem->mm_node;
> > >   nouveau_vm_map_sg(vma, 0, new_mem->
> > > num_pages << PAGE_SHIFT,
> > > node, node->pages);
> > > @@ -1131,7 +1131,7 @@ struct ttm_bo_driver nouveau_bo_driver = {
> > >   .invalidate_caches = nouveau_bo_invalidate_caches,
> > >   .init_mem_type = nouveau_bo_init_mem_type,
> > >   .evict_flags = nouveau_bo_evict_flags,
> > > - .move_notify = nouveau_bo_move_ntfy,
> > > + .move_notify = nouveau_bo_move_notify,
> > >   .move = nouveau_bo_move,
> > >   .verify_access = nouveau_bo_verify_access,
> > >   .sync_obj_signaled = __nouveau_fence_signalled,
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44524] [radeon driver] Screen corruption when "Applications" has enough apps to have a scrollbar on Gnome Desktop

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44524

Michel Dänzer  changed:

   What|Removed |Added

Version|unspecified |7.11

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: TTM and AGP conflicts

2012-01-06 Thread James Simmons 

> >> You can achieve what you want by either adding a new domain so you would 
> >> have
> >> system, vram, agp, pcidma and object can be bound to one and only one. Or 
> >> you
> >> can hack your own agp ttm backend that could bind bo to agp or pci or
> >> both at the same time depending on what you want to achieve.
> >
> > The question is how does one know which domain you want in tt_create.
> > Currenty drivers are using there dev_priv but if you have have more than
> > one option available how does one choose? Would you be okay with passing
> > in a domain flag?
> >
> 
> Well i agree that something would be usefull there so the driver know
> which bind/unbind function it should use. Thomas i would prefer
> passing the bo to the tt_create callback but a flag is the minimum we
> need.

We can discuss this after the merge widow. Jerome your patch does fix a 
regression whereas my proposal is a enhancement. 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43719] drm-core-next + AGP RV670 = Oops

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=43719

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Andy Furniss  2012-01-06 
08:34:23 UTC ---
Patch now in drm-core-next, which is working OK for me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
>> > On Thu, 2012-01-05 at 13:31 -0500, j.gli...@gmail.com wrote:
>> > > From: Jerome Glisse 
>> > >
>> > > ttm might call the move notify with null new mem placement,
>> > > properly handle this case inside nouveau move notify callback.
>> > This has been fixed already in a -next tree I sent to Dave.
>>
>> I just tried -next with your patch (and two other fixes that I had sent):
>>
>> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
>> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
>> don't try to free freed pages
>>
>> and Jerome's AGP fix:
>> ttm: fix agp since ttm tt rework
>>
>> and got the crash (but only with NVidia cards) after swapping between Xorg 
>> and the VCs.
>> Look in drm-next.jpg
>
> http://darnok.org/vga/drm-next.jpg
>
>>
>> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a recent 
>> ttm change")
>> and the patch below by Jerome I still get it to crash (see 
>> drm-next-with-Jerome-fix-revert-Ben.jpg)..
>
> http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
>

Anything special to trigger it ? I can't trigger it with simple gnome3
session (firefox evince ...)

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.30

2012-01-06 Thread Eric Anholt 
Here's a new release, featuring updated i915_drm.h for gen7 transform
feedback, and intel_decode.c as a library API instead of being copied
around between our various driver components.

Chris Wilson (2):
  intel: Reset vma list upon purge
  tests/gem_flink: Check for MASTER before proceeding

Eric Anholt (18):
  intel: Import intel_decode.c from intel-gpu-tools.
  intel: Make intel_chipset handle devid directly.
  intel: intel: Add IS_GEN[567] macros.
  intel: Reformat intel_decode.c from intel-gpu-tools using Lindent.
  intel: Minor style tweaks after Lindent.
  intel: Get intel_decode.c minimally building.
  intel: Fix Wsigned-compare warnings (soon to be enabled).
  intel: Fix a ton of signed vs unsigned and const char *warnings
  intel: Add printflike warnings for instr_out.
  intel: Fix printf format warnings for intel_decode.
  intel: Remove c99ish variable declarations.
  intel: Turn on normal warnings for intel_decode.c build.
  intel: Disable unused decode_logic_op().
  intel: Add an interface for setting the output file for decode.
  intel: Add a regression test program for intel_decode.c.
  intel: Add regression tests for batch decode.
  intel: Update for new i915_drm.h defines.
  configure: Bump version for 2.4.30

Jesse Barnes (1):
  libdrm: update drm headers from kernel, including new overlay ioctls & 
structs

Johannes Obermayr (1):
  intel/intel_decode.c: Remove #include "intel_decode.h".

git tag: 2.4.30

http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.bz2
MD5:  9f57a68b2c0836b55ebcbc241f6ca175  libdrm-2.4.30.tar.bz2
SHA1: 5ba36a0bcbacbe67e6a2e0d5318ed9455da59bbc  libdrm-2.4.30.tar.bz2
SHA256: cacea9c157ec824ad278a06f4910659b2f3ae69686518ece8d6967843cddcd56  
libdrm-2.4.30.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.gz
MD5:  cd790fb761a83125eceb64162d7d5ce5  libdrm-2.4.30.tar.gz
SHA1: 148936f0c0f83d016c584245493b975d42bd359a  libdrm-2.4.30.tar.gz
SHA256: a64e63a2af08bcab835e758048611cf61c7183dc7e829cad9dceba859245b4bc  
libdrm-2.4.30.tar.gz



pgp4wpDL8sdaT.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> >> > On Thu, 2012-01-05 at 13:31 -0500, j.gli...@gmail.com wrote:
> >> > > From: Jerome Glisse 
> >> > >
> >> > > ttm might call the move notify with null new mem placement,
> >> > > properly handle this case inside nouveau move notify callback.
> >> > This has been fixed already in a -next tree I sent to Dave.
> >>
> >> I just tried -next with your patch (and two other fixes that I had sent):
> >>
> >> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> >> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page 
> >> and don't try to free freed pages
> >>
> >> and Jerome's AGP fix:
> >> ttm: fix agp since ttm tt rework
> >>
> >> and got the crash (but only with NVidia cards) after swapping between Xorg 
> >> and the VCs.
> >> Look in drm-next.jpg
> >
> > http://darnok.org/vga/drm-next.jpg
> >
> >>
> >> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a 
> >> recent ttm change")
> >> and the patch below by Jerome I still get it to crash (see 
> >> drm-next-with-Jerome-fix-revert-Ben.jpg)..
> >
> > http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
> >
> 
> Anything special to trigger it ? I can't trigger it with simple gnome3
> session (firefox evince ...)

I ran etracer, then switched over to a framebuffer console (Alt-F2), logged in.
Then ran perf record and switched back to etracer. Ran a couple of laps and 
when finished
quit the perf top. On the PCI-e it took a while (so I had to run a couple of 
laps).

On the AGP one it happended immediately, which is no surprise since the code 
looks
to be activated when we do garbage collection and the machine only had 2GB. The
PCIe on has 8GB. Perhaps a better way would be to force the workqueue by 
setting the
pool limits to smaller values.

> 
> Cheers,
> Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44536] New: [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

 Bug #: 44536
   Summary: [r300g] bisected - performance regression on 0ad
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: fabio@libero.it
CC: mar...@gmail.com


This commit [1] lowers 0 A.D. performance from ~28 fps to ~20 fps, confirmed
with LIBGL_SHOW_FPS=1 mesa variable and with in game FPS counter. This is on
0ad alpha 8 on default Oasis map. Tested with current mesa git up to e60daf7
with and without the [1] commit reverted.

The card is:
r300: DRM version: 2.9.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2
r300: GART size: 509 MB, VRAM size: 256 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES


[1]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=93f4e3cb6c1ca303ee1f5c2a2491a8eff33f2633

commit 93f4e3cb6c1ca303ee1f5c2a2491a8eff33f2633
Author: Marek Olšák 
Date:   Sat Dec 24 08:15:40 2011 +0100

winsys/radeon: move managing GEM domains back to drivers

This partially reverts commit 363ff844753c46ac9c13866627e096b091ea81f8.

It caused severe performance drops in Nexuiz. Reported by Phoronix.

Tested by me on r300g and by IRC people on r600g.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 06, 2012 at 11:53:35AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> > On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
> >  wrote:
> > > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> > >> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> > >> > On Thu, 2012-01-05 at 13:31 -0500, j.gli...@gmail.com wrote:
> > >> > > From: Jerome Glisse 
> > >> > >
> > >> > > ttm might call the move notify with null new mem placement,
> > >> > > properly handle this case inside nouveau move notify callback.
> > >> > This has been fixed already in a -next tree I sent to Dave.
> > >>
> > >> I just tried -next with your patch (and two other fixes that I had sent):
> > >>
> > >> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> > >> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page 
> > >> and don't try to free freed pages
> > >>
> > >> and Jerome's AGP fix:
> > >> ttm: fix agp since ttm tt rework
> > >>
> > >> and got the crash (but only with NVidia cards) after swapping between 
> > >> Xorg and the VCs.
> > >> Look in drm-next.jpg
> > >
> > > http://darnok.org/vga/drm-next.jpg
> > >
> > >>
> > >> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a 
> > >> recent ttm change")
> > >> and the patch below by Jerome I still get it to crash (see 
> > >> drm-next-with-Jerome-fix-revert-Ben.jpg)..
> > >
> > > http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
> > >
> > 
> > Anything special to trigger it ? I can't trigger it with simple gnome3
> > session (firefox evince ...)
> 
> I ran etracer, then switched over to a framebuffer console (Alt-F2), logged 
> in.
> Then ran perf record and switched back to etracer. Ran a couple of laps and 
> when finished
> quit the perf top. On the PCI-e it took a while (so I had to run a couple of 
> laps).
> 
> On the AGP one it happended immediately, which is no surprise since the code 
> looks
> to be activated when we do garbage collection and the machine only had 2GB. 
> The
> PCIe on has 8GB. Perhaps a better way would be to force the workqueue by 
> setting the
> pool limits to smaller values.
>

Still having difficulty to reproduce can you reproduce with the attached
printk debuging patch and provide the log (only few printk preceding the
oops or segfault are interesting).

Cheers,
Jerome
>From 862e2cc6d35d85404ed24d24c5a5c49c5ef45fc7 Mon Sep 17 00:00:00 2001
From: Jerome Glisse 
Date: Fri, 6 Jan 2012 13:20:08 -0500
Subject: [PATCH] TTM-DEBUG-PRINTK

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..326b64a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -812,12 +812,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_vma *vma;
 
+DRM_INFO("%s list (%p %p)\n", __func__, nvbo->vma_list.prev, 
nvbo->vma_list.next);
list_for_each_entry(vma, &nvbo->vma_list, head) {
if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem->mm_node);
} else
if (new_mem && new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
+DRM_INFO("%s vma %p new mem %p %d pages\n", __func__, vma, new_mem, 
new_mem->num_pages);
nouveau_vm_map_sg(vma, 0, new_mem->
  num_pages << PAGE_SHIFT,
  new_mem->mm_node);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=30227

--- Comment #12 from Michel Dänzer  2012-01-06 10:37:08 PST 
---
FWIW, http://lists.freedesktop.org/archives/dri-devel/2012-January/017932.html
should increase the chance of recovering from a GPU lockup, or at least being
able to reboot cleanly, on a big endian host.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
> Still having difficulty to reproduce can you reproduce with the attached
> printk debuging patch and provide the log (only few printk preceding the
> oops or segfault are interesting).

http://darnok.org/vga/move_notify-v212.log

> 
> Cheers,
> Jerome

> >From 862e2cc6d35d85404ed24d24c5a5c49c5ef45fc7 Mon Sep 17 00:00:00 2001
> From: Jerome Glisse 
> Date: Fri, 6 Jan 2012 13:20:08 -0500
> Subject: [PATCH] TTM-DEBUG-PRINTK
> 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 724b41a..326b64a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -812,12 +812,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> struct ttm_mem_reg *new_mem)
>   struct nouveau_bo *nvbo = nouveau_bo(bo);
>   struct nouveau_vma *vma;
>  
> +DRM_INFO("%s list (%p %p)\n", __func__, nvbo->vma_list.prev, 
> nvbo->vma_list.next);
>   list_for_each_entry(vma, &nvbo->vma_list, head) {
>   if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
>   nouveau_vm_map(vma, new_mem->mm_node);
>   } else
>   if (new_mem && new_mem->mem_type == TTM_PL_TT &&
>   nvbo->page_shift == vma->vm->spg_shift) {
> +DRM_INFO("%s vma %p new mem %p %d pages\n", __func__, vma, new_mem, 
> new_mem->num_pages);
>   nouveau_vm_map_sg(vma, 0, new_mem->
> num_pages << PAGE_SHIFT,
> new_mem->mm_node);
> -- 
> 1.7.5.4
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > Still having difficulty to reproduce can you reproduce with the attached
> > printk debuging patch and provide the log (only few printk preceding the
> > oops or segfault are interesting).
> 
> http://darnok.org/vga/move_notify-v212.log
> 

Looks like nouveau doesn't like move notify being call on driver
shutdown or when somethings om nv50 is down. Ben i think you will
be better at finding a fix for that than me.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44536] [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

--- Comment #1 from Marek Olšák  2012-01-06 13:54:57 PST ---
If I revert that commit, Nexuiz will be slow again. I can't do that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44536] [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

Marek Olšák  changed:

   What|Removed |Added

  Component|Drivers/DRI/r300|Drivers/Gallium/r300

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Ben Skeggs 
On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
> 
> ttm might call the move notify with null new mem placement,
> properly handle this case inside nouveau move notify callback.
This has been fixed already in a -next tree I sent to Dave.

Ben.
> 
> Signed-off-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index f12dd0f..65f5b0b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -808,9 +808,8 @@ out:
>  }
>  
>  static void
> -nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> *new_mem)
> +nouveau_bo_move_notify(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> *new_mem)
>  {
> - struct nouveau_mem *node = new_mem->mm_node;
>   struct nouveau_bo *nvbo = nouveau_bo(bo);
>   struct nouveau_vma *vma;
>  
> @@ -820,6 +819,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
> ttm_mem_reg *new_mem)
>   } else
>   if (new_mem && new_mem->mem_type == TTM_PL_TT &&
>   nvbo->page_shift == vma->vm->spg_shift) {
> + struct nouveau_mem *node = new_mem->mm_node;
>   nouveau_vm_map_sg(vma, 0, new_mem->
> num_pages << PAGE_SHIFT,
> node, node->pages);
> @@ -1131,7 +1131,7 @@ struct ttm_bo_driver nouveau_bo_driver = {
>   .invalidate_caches = nouveau_bo_invalidate_caches,
>   .init_mem_type = nouveau_bo_init_mem_type,
>   .evict_flags = nouveau_bo_evict_flags,
> - .move_notify = nouveau_bo_move_ntfy,
> + .move_notify = nouveau_bo_move_notify,
>   .move = nouveau_bo_move,
>   .verify_access = nouveau_bo_verify_access,
>   .sync_obj_signaled = __nouveau_fence_signalled,

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=37724

--- Comment #14 from Marek Ol??k  2012-01-05 16:18:14 PST 
---
Well maybe not, I am not sure.

I recall there was another bug with HiZ, which could be triggered by changing
the depth function. The workaround was to flush the zbuffer cache when the
depth function was changed. However flushing the cache is a very costly
operation, so it wasn't even an option.

I just gave up after that, because it made no *** sense. Zbuffer cache
should have nothing to with HiZ.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43829] Resuming my AMD A4-300 based laptop leaves the screen black

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43829

--- Comment #1 from Joshua Roys  2012-01-05 17:21:16 PST 
---
Created attachment 55194
  --> https://bugs.freedesktop.org/attachment.cgi?id=55194
difference of `radeontool regmatch \*` from before and after suspend

HP G4-1215DX with an A4-3300 APU here.  Everything comes back but the display
on a resume from a suspend.  I can ssh into the machine and get any kind of
debugging info needed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43829

Joshua Roys  changed:

   What|Removed |Added

Summary|Resuming my AMD A4-300  |Resuming my AMD A4-3300
   |based laptop leaves the |based laptop leaves the
   |screen black|screen black

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: add support for streamout

2012-01-06 Thread Marek Olšák 
People can start using transform feedback on r6xx with this.

Strict CS checking will be implemented later.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  104 +++--
 drivers/gpu/drm/radeon/evergreend.h   |   10 +++
 drivers/gpu/drm/radeon/r600_cs.c  |  105 +++--
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 +++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 +++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 +++
 8 files changed, 246 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index cd4590a..3150489 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,19 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_offset = 0x;
track->db_s_read_bo = NULL;
track->db_s_write_bo = NULL;
+
+   for (i = 0; i < 4; i++) {
+   track->vgt_strmout_size[i] = 0;
+   track->vgt_strmout_bo[i] = NULL;
+   track->vgt_strmout_bo_offset[i] = 0x;
+   track->vgt_strmout_bo_mc[i] = 0x;
+   }
 }

 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
struct evergreen_cs_track *track = p->track;

-   /* we don't support stream out buffer yet */
-   if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
-   dev_warn(p->dev, "this kernel doesn't support SMX output 
buffer\n");
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +602,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, &reloc);
+   if (r) {
+   dev_warn(p->dev, "bad SET_CONTEXT_REG "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
<< 8;
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+   track->vgt_strmout_bo[tmp] = reloc->robj;
+   track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, &reloc);
+   if (r) {
+   dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1451,6 +1487,62 @@ static int evergreen_packet3_check(struct 
radeon_cs_parser *p,
return -EINVAL;
}
break;
+   case PACKET3_STRMOUT_BUFFER_UPDATE:
+   if (pkt->count != 4) {
+   DRM_ERROR("bad STRMOUT_BUFFER_UPDATE (invalid 
count)\n");
+   return -EINVAL;
+   }
+   /* Updating memory at DST_ADDRESS. */
+   if (idx_value & 0x1) {
+   r = evergreen_cs_packet_next_reloc(p, &reloc);
+   if (r) {
+   DRM_ERROR("bad STRMOUT_BUFFER_UPDATE (missing 
reloc 1)\n");
+   return -EINVAL;
+   }

[PATCH] drm: introduce drm_can_sleep and use in intel/radeon drivers.

2012-01-06 Thread Dave Airlie 
>>
>> So we have a few places where the drm drivers would like to sleep to
>> be nice to the system, mainly in the modesetting paths, but we also
>> have two cases were atomic modesetting must take place, panic writing
>> and kernel debugger. So provide a central inline to determine if a
>> sleep or delay should be used and use this in the intel and radeon drivers.
>>
>> Based on patch from Michel D?nzer 
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>>
>> Signed-off-by: Dave Airlie 
>
> If MSLEEP is indeed unused, I think it should just die - we have way too
> much yelling cruft from dri1 yonder lying around that hides important
> details like this. Otherwise
>
> Reviewed-by: Daniel Vetter 

I've pushed the version that just drops MSLEEP since nobody used it.

Thanks,
Dave.

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Dave Airlie 
On Fri, Jan 6, 2012 at 3:11 AM,   wrote:
> From: Jerome Glisse 
>
> Virtual address space are per drm client (opener of /dev/drm).
> Client are in charge of virtual address space, they need to
> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>
> First 16M of virtual address space is reserved by the kernel.
>
> Once using 2 level page table we should be able to have a small
> vram memory footprint for each pt (there would be one pt for all
> gart, one for all vram and then one first level for each virtual
> address space).
>
> Plan include using the sub allocator for a common vm page table
> area and using memcpy to copy vm page table in & out. Or use
> a gart object and copy things in & out using dma.

Pushed all 3.

What happens if someone calls the VA ioctl on a non-VM system btw?

If thats an issue, please provide a follow up patch.

Dave.

merge window closed

2012-01-06 Thread Dave Airlie 
On Fri, Jan 6, 2012 at 2:24 AM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Jan 05, 2012 at 10:48:10AM +, Dave Airlie wrote:
>> Hi
>>
>> So Linus has released, so really whats in -next is really it
>>
>> I've two things outstanding,
>> the TTM/AGP fixes, from Jerome/Konrad, guys please cross-review asap,
>
> OK, so the two I posted:
>
> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
> don't try to free freed pages.
> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
>
> Should go in. Jerome took a look at both of them and Reviewed them.
>
> He has also posted:
> ttm: fix agp since ttm tt rework
>
> which looks OK to me and should have the Reviewed-by me flag stuck on. Let
> me respond to Jerome's email on that.
>
> Now on the move_notify work, that still does not work properly with nouveau.
> Ben did some work with ""drm/nouveau/ttm: fix crash as a result of a recent 
> ttm change"
> but I can still get the machine to crash so will have to dig on this a bit 
> more.

Okay I've merged the 3 you've mentioned here,

The move notify stuff if its still an issue please work it out with
Ben, all his stuff is in -core-next already.

Dave.

[Bug 44523] New: nexuiz perf regression since u_vbuf: implement another upload codepath which unrolls indices

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44523

 Bug #: 44523
   Summary: nexuiz perf regression since u_vbuf: implement another
upload codepath which unrolls indices
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: lists at andyfurniss.entadsl.com


d-r-t kernel, HD4890.

Since -

commit ce44bae366ade59fb2dbdfbfe5a1ab8d24518a57
Author: Marek Olk 
Date:   Tue Jan 3 22:01:03 2012 +0100

u_vbuf: implement another upload codepath which unrolls indices

Improves performance from cca 1 fps to 23 fps in Cogs.
This new codepath is not always used, instead, there is a heuristic which
determines whether to use it. Using translate for uploads is generally
slower than what we have had already, it's a win only in a few cases.

I get quite a noticeable perf regression running demo1 in nexuiz.

Other games (openarena,ut2004 demo, etqw) seem unaffected 


91.2740132 fps, one-second fps min/avg/max: 50 99 231 (90 seconds)

to

55.6802612 fps, one-second fps min/avg/max: 19 69 231 (90 seconds)

Sometimes I saw a couple of short (1/4 sec) stalls as well, which gave worse
results, above was without stalls.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44032] drm-core-next + RV790 + ETQW = WARNING bisected

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44032

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Andy Furniss  2012-01-06 
04:07:24 PST ---
I can't trigger this with today's drm-core-next.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Christian König 
On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
[SNIP]
>   #define RADEON_CHUNK_ID_RELOCS  0x01
>   #define RADEON_CHUNK_ID_IB  0x02
>   #define RADEON_CHUNK_ID_FLAGS   0x03
>
>   /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
>   #define RADEON_CS_KEEP_TILING_FLAGS 0x01
> +#define RADEON_CS_USE_VM0x02
> +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the ring 
> type */
> +#define RADEON_CS_RING_GFX  0
> +#define RADEON_CS_RING_COMPUTE  1
> +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the 
> priority */
> +/* 0 = normal, + = higher priority, - = lower priority */
> +struct drm_radeon_cs_ring_priority {
> + int32_t priority;
> +};
Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" 
is pretty much pointless.

My comment was going more into that direction:
struct drm_radeon_cs_flags {
 uint32_t  flags;
 uint32_t  ring_type;
 int32_tpriority;
};

Anyway, the patch is finally committed, but I think we should fix 
(remove?) that before it goes further upstream.

Christian.

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
2012/1/6 Christian K?nig :
> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
> [SNIP]
>
>> ?#define RADEON_CHUNK_ID_RELOCS ? ? ? ?0x01
>> ?#define RADEON_CHUNK_ID_IB ? ?0x02
>> ?#define RADEON_CHUNK_ID_FLAGS 0x03
>>
>> ?/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
>> */
>> ?#define RADEON_CS_KEEP_TILING_FLAGS 0x01
>> +#define RADEON_CS_USE_VM ? ? ? ? ? ?0x02
>> +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
>> ring type */
>> +#define RADEON_CS_RING_GFX ? ? ? ? ?0
>> +#define RADEON_CS_RING_COMPUTE ? ? ?1
>> +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
>> priority */
>> +/* 0 = normal, + = higher priority, - = lower priority */
>> +struct drm_radeon_cs_ring_priority {
>> + ? ? ? int32_t ? ? ? ? ? ? ? ? priority;
>> +};
>
> Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" is
> pretty much pointless.

I didn't have a struct for priority before, but someone suggested it
would be clearer what the 3rd dword was used for if I added a struct.
Basically just treat the third flag dword as a signed int32.

>
> My comment was going more into that direction:
> struct drm_radeon_cs_flags {
> ? ?uint32_t ? ? ?flags;
> ? ?uint32_t ? ? ?ring_type;
> ? ?int32_t ? ? ? ?priority;
> };
>
> Anyway, the patch is finally committed, but I think we should fix (remove?)
> that before it goes further upstream.

Would there be any issues if we need to extend the stuct to add an
extra field later?  Also, not all of the fields are necessary.  You
can just allocate 1 dword if you just need the flags dword.  I've fine
to just drop the struct.

Alex

>
> Christian.

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
On Fri, Jan 6, 2012 at 5:09 AM, Dave Airlie  wrote:
> On Fri, Jan 6, 2012 at 3:11 AM, ? wrote:
>> From: Jerome Glisse 
>>
>> Virtual address space are per drm client (opener of /dev/drm).
>> Client are in charge of virtual address space, they need to
>> map bo into it by calling DRM_RADEON_GEM_VA ioctl.
>>
>> First 16M of virtual address space is reserved by the kernel.
>>
>> Once using 2 level page table we should be able to have a small
>> vram memory footprint for each pt (there would be one pt for all
>> gart, one for all vram and then one first level for each virtual
>> address space).
>>
>> Plan include using the sub allocator for a common vm page table
>> area and using memcpy to copy vm page table in & out. Or use
>> a gart object and copy things in & out using dma.
>
> Pushed all 3.
>
> What happens if someone calls the VA ioctl on a non-VM system btw?
>
> If thats an issue, please provide a follow up patch.


I'll double check.

Alex

>
> Dave.

[PATCH 1/2] drm/radeon/kms: check if vm is supported in VA ioctl

2012-01-06 Thread alexdeuc...@gmail.com 
From: Alex Deucher 

Add a VM manager enabled field and use it to check if
vm is enabled.

Signed-off-by: Alex Deucher 
Cc: jglisse at redhat.com
---
 drivers/gpu/drm/radeon/radeon.h  |2 ++
 drivers/gpu/drm/radeon/radeon_cs.c   |4 ++--
 drivers/gpu/drm/radeon/radeon_gart.c |   10 +-
 drivers/gpu/drm/radeon/radeon_gem.c  |5 +
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7cb63cd..73e05cb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -668,6 +668,8 @@ struct radeon_vm_manager {
unsignednvm;
/* vram base address for page table entry  */
u64 vram_base_offset;
+   /* is vm enabled? */
+   boolenabled;
 };

 /*
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 17af0e8..435a3d9 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -234,8 +234,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
}

if ((p->cs_flags & RADEON_CS_USE_VM) &&
-   (p->rdev->family < CHIP_CAYMAN)) {
-   DRM_ERROR("VM not supported on asic!\n");
+   !p->rdev->vm_manager.enabled) {
+   DRM_ERROR("VM not active on asic!\n");
if (p->chunk_relocs_idx != -1)
kfree(p->chunks[p->chunk_relocs_idx].kdata);
if (p->chunk_flags_idx != -1)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 3ef58ca..8597d2c 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -286,6 +286,8 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 {
int r;

+   rdev->vm_manager.enabled = false;
+
/* mark first vm as always in use, it's the system one */
r = radeon_sa_bo_manager_init(rdev, &rdev->vm_manager.sa_manager,
  rdev->vm_manager.max_pfn * 8,
@@ -295,7 +297,12 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
(rdev->vm_manager.max_pfn * 8) >> 10);
return r;
}
-   return rdev->vm_manager.funcs->init(rdev);
+
+   r = rdev->vm_manager.funcs->init(rdev);
+   if (r == 0)
+   rdev->vm_manager.enabled = true;
+
+   return r;
 }

 /* cs mutex must be lock */
@@ -334,6 +341,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
radeon_vm_manager_suspend(rdev);
rdev->vm_manager.funcs->fini(rdev);
radeon_sa_bo_manager_fini(rdev, &rdev->vm_manager.sa_manager);
+   rdev->vm_manager.enabled = false;
 }

 int radeon_vm_manager_start(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 003eeec..7337850 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -404,6 +404,11 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
u32 invalid_flags;
int r = 0;

+   if (!rdev->vm_manager.enabled) {
+   args->operation = RADEON_VA_RESULT_ERROR;
+   return -ENOTTY;
+   }
+
/* !! DONT REMOVE !!
 * We don't support vm_id yet, to be sure we don't have have broken
 * userspace, reject anyone trying to use non 0 value thus moving
-- 
1.7.3.4

[PATCH 2/2] drm/radeon/kms: remove pointless CS flags priority struct

2012-01-06 Thread alexdeuc...@gmail.com 
From: Alex Deucher 

Signed-off-by: Alex Deucher 
Cc: Christian K?nig 
---
 include/drm/radeon_drm.h |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 2a807a5..b55da40 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -907,9 +907,6 @@ struct drm_radeon_gem_va {
 #define RADEON_CS_RING_COMPUTE  1
 /* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
 /* 0 = normal, + = higher priority, - = lower priority */
-struct drm_radeon_cs_ring_priority {
-   int32_t priority;
-};

 struct drm_radeon_cs_chunk {
uint32_tchunk_id;
-- 
1.7.3.4

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Christian König 
On 06.01.2012 15:12, Alex Deucher wrote:
> 2012/1/6 Christian K?nig:
>> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
>> [SNIP]
>>
>>>   #define RADEON_CHUNK_ID_RELOCS0x01
>>>   #define RADEON_CHUNK_ID_IB0x02
>>>   #define RADEON_CHUNK_ID_FLAGS 0x03
>>>
>>>   /* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
>>> */
>>>   #define RADEON_CS_KEEP_TILING_FLAGS 0x01
>>> +#define RADEON_CS_USE_VM0x02
>>> +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
>>> ring type */
>>> +#define RADEON_CS_RING_GFX  0
>>> +#define RADEON_CS_RING_COMPUTE  1
>>> +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
>>> priority */
>>> +/* 0 = normal, + = higher priority, - = lower priority */
>>> +struct drm_radeon_cs_ring_priority {
>>> +   int32_t priority;
>>> +};
>> Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority" is
>> pretty much pointless.
> I didn't have a struct for priority before, but someone suggested it
> would be clearer what the 3rd dword was used for if I added a struct.
> Basically just treat the third flag dword as a signed int32.
Yeah that suggestion came from me, but what I had in mind was a 
structure for the whole flags chunk, instead of just the priority field.

>> My comment was going more into that direction:
>> struct drm_radeon_cs_flags {
>> uint32_t  flags;
>> uint32_t  ring_type;
>> int32_tpriority;
>> };
>>
>> Anyway, the patch is finally committed, but I think we should fix (remove?)
>> that before it goes further upstream.
> Would there be any issues if we need to extend the stuct to add an
> extra field later?  Also, not all of the fields are necessary.  You
> can just allocate 1 dword if you just need the flags dword.  I've fine
> to just drop the struct.
>
Well, using structs as interface definitions has always suffered from 
those problems, e. g. for compatibility you can only extend it at the 
end, members might have ambiguous sizes, members might be packed 
differently.  I'm still just prefering them because they are machine 
readable, instead of human readable comments, and machines tend to 
produce less bugs than humans while calculations memory offsets...

But I don't have enough experience with kernel interfaces to favor one 
style of coding over another, so if you think it's ok to drop it then 
just go ahead. I just wanted to note that there was a misunderstanding.

Christian.

[PATCH 1/3] drm/radeon: GPU virtual memory support v22

2012-01-06 Thread Alex Deucher 
2012/1/6 Christian K?nig :
> On 06.01.2012 15:12, Alex Deucher wrote:
>>
>> 2012/1/6 Christian K?nig:
>>>
>>> On -10.01.-28163 20:59, alexdeucher at gmail.com wrote:
>>> [SNIP]
>>>
 ?#define RADEON_CHUNK_ID_RELOCS ? ? ? ?0x01
 ?#define RADEON_CHUNK_ID_IB ? ?0x02
 ?#define RADEON_CHUNK_ID_FLAGS 0x03

 ?/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags:
 */
 ?#define RADEON_CS_KEEP_TILING_FLAGS 0x01
 +#define RADEON_CS_USE_VM ? ? ? ? ? ?0x02
 +/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the
 ring type */
 +#define RADEON_CS_RING_GFX ? ? ? ? ?0
 +#define RADEON_CS_RING_COMPUTE ? ? ?1
 +/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the
 priority */
 +/* 0 = normal, + = higher priority, - = lower priority */
 +struct drm_radeon_cs_ring_priority {
 + ? ? ? int32_t ? ? ? ? ? ? ? ? priority;
 +};
>>>
>>> Sorry, missed that one before, the "struct drm_radeon_cs_ring_priority"
>>> is
>>> pretty much pointless.
>>
>> I didn't have a struct for priority before, but someone suggested it
>> would be clearer what the 3rd dword was used for if I added a struct.
>> Basically just treat the third flag dword as a signed int32.
>
> Yeah that suggestion came from me, but what I had in mind was a structure
> for the whole flags chunk, instead of just the priority field.
>
>
>>> My comment was going more into that direction:
>>> struct drm_radeon_cs_flags {
>>> ? ?uint32_t ? ? ?flags;
>>> ? ?uint32_t ? ? ?ring_type;
>>> ? ?int32_t ? ? ? ?priority;
>>> };
>>>
>>> Anyway, the patch is finally committed, but I think we should fix
>>> (remove?)
>>> that before it goes further upstream.
>>
>> Would there be any issues if we need to extend the stuct to add an
>> extra field later? ?Also, not all of the fields are necessary. ?You
>> can just allocate 1 dword if you just need the flags dword. ?I've fine
>> to just drop the struct.
>>
> Well, using structs as interface definitions has always suffered from those
> problems, e. g. for compatibility you can only extend it at the end, members
> might have ambiguous sizes, members might be packed differently. ?I'm
> still just prefering them because they are machine readable, instead of
> human readable comments, and machines tend to produce less bugs than humans
> while calculations memory offsets...
>
> But I don't have enough experience with kernel interfaces to favor one style
> of coding over another, so if you think it's ok to drop it then just go
> ahead. I just wanted to note that there was a misunderstanding.

I just went ahead and dropped it for now.  I'm open too suggestions
for better approaches though.

Alex

>
> Christian.

[git pull] dma-buf tree

2012-01-06 Thread Dave Airlie 

Hi Linus,

This isn't the drm merge, however a few projects have been working 
together on a buffer sharing mechanism for kernel drivers, the maim
interested parties are the Linaro/ARM SoC folks, V4L, DRM, and fbdev.
Sumit Semwal wrote the code, and its been reviewed on various lists a fair 
few times.

Now we've all agreed that the initial implementation is a good baseline 
for us to move forward on, but its messy working with others when the core 
code is out of tree. So we'd like to merge the core dma-buf code now so we 
can all build on top of it for 3.4. I know some people would say we 
shouldn't merge things with no users, but it will really make our lives 
easier going forward to get this baseline into the tree.

Currently I've got most of a drm inter-driver buffer sharing mechanism 
built on top and there is also got a v4l consumer built. The code doesn't 
introduce any new userspace interfaces, its purely a kernel internal 
layer, that the consumer/exported layers like drm/v4l will plug into to 
offer services.

Dave.

The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:

  Linux 3.2 (2012-01-04 15:55:44 -0800)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux dma-buf-merge

Sumit Semwal (3):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework
  dma-buf: mark EXPERIMENTAL for 1st release.

 Documentation/dma-buf-sharing.txt |  224 
 drivers/base/Kconfig  |   11 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  291 +
 include/linux/dma-buf.h   |  176 ++
 5 files changed, 703 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

[Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

2012-01-06 Thread Jesse Barnes 
On Thu, 05 Jan 2012 19:10:43 -0800
Eric Anholt  wrote:

> On Thu,  5 Jan 2012 14:16:23 -0200, przanoni at gmail.com wrote:
> > From: Paulo Zanoni 
> > 
> > This ioctl is used to signal the drivers that the screen is rotated,
> > not to make the drivers rotate the screen.
> >  - add a driver-specific "rotation_set" function
> >  - implement Intel's rotation_set by setting the right values to the
> >PIPECONF registers.
> > 
> > The idea is that when user-space does rotation, it can call this ioctl
> > to inform the Kernel that we have a rotation. This feature is needed
> > by the KVMr feature of VPro.
> 
> So am I following this right, that these register bits are used to
> communicate from one piece of software to another piece of software,
> across the virtualization boundary?

Right, but not for virtualization; these bits are read by the AMT
engine for its built-in KVM functionality.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 44524] [radeon driver] Screen corruption when "Applications" has enough apps to have a scrollbar on Gnome Desktop

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44524

Michel D?nzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |
Product|xorg|Mesa
  Component|Driver/Radeon   |Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
> > > From: Jerome Glisse 
> > > 
> > > ttm might call the move notify with null new mem placement,
> > > properly handle this case inside nouveau move notify callback.
> > This has been fixed already in a -next tree I sent to Dave.
> 
> I just tried -next with your patch (and two other fixes that I had sent):
> 
> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
> don't try to free freed pages
> 
> and Jerome's AGP fix:
> ttm: fix agp since ttm tt rework
> 
> and got the crash (but only with NVidia cards) after swapping between Xorg 
> and the VCs.
> Look in drm-next.jpg

http://darnok.org/vga/drm-next.jpg

> 
> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a recent 
> ttm change")
> and the patch below by Jerome I still get it to crash (see 
> drm-next-with-Jerome-fix-revert-Ben.jpg)..

http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg


> 
> > 
> > Ben.
> > > 
> > > Signed-off-by: Jerome Glisse 
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
> > >  1 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index f12dd0f..65f5b0b 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -808,9 +808,8 @@ out:
> > >  }
> > >  
> > >  static void
> > > -nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> > > *new_mem)
> > > +nouveau_bo_move_notify(struct ttm_buffer_object *bo, struct ttm_mem_reg 
> > > *new_mem)
> > >  {
> > > - struct nouveau_mem *node = new_mem->mm_node;
> > >   struct nouveau_bo *nvbo = nouveau_bo(bo);
> > >   struct nouveau_vma *vma;
> > >  
> > > @@ -820,6 +819,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> > > struct ttm_mem_reg *new_mem)
> > >   } else
> > >   if (new_mem && new_mem->mem_type == TTM_PL_TT &&
> > >   nvbo->page_shift == vma->vm->spg_shift) {
> > > + struct nouveau_mem *node = new_mem->mm_node;
> > >   nouveau_vm_map_sg(vma, 0, new_mem->
> > > num_pages << PAGE_SHIFT,
> > > node, node->pages);
> > > @@ -1131,7 +1131,7 @@ struct ttm_bo_driver nouveau_bo_driver = {
> > >   .invalidate_caches = nouveau_bo_invalidate_caches,
> > >   .init_mem_type = nouveau_bo_init_mem_type,
> > >   .evict_flags = nouveau_bo_evict_flags,
> > > - .move_notify = nouveau_bo_move_ntfy,
> > > + .move_notify = nouveau_bo_move_notify,
> > >   .move = nouveau_bo_move,
> > >   .verify_access = nouveau_bo_verify_access,
> > >   .sync_obj_signaled = __nouveau_fence_signalled,
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44524] [radeon driver] Screen corruption when "Applications" has enough apps to have a scrollbar on Gnome Desktop

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44524

Michel D?nzer  changed:

   What|Removed |Added

Version|unspecified |7.11

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

TTM and AGP conflicts

2012-01-06 Thread James Simmons 

> >> You can achieve what you want by either adding a new domain so you would 
> >> have
> >> system, vram, agp, pcidma and object can be bound to one and only one. Or 
> >> you
> >> can hack your own agp ttm backend that could bind bo to agp or pci or
> >> both at the same time depending on what you want to achieve.
> >
> > The question is how does one know which domain you want in tt_create.
> > Currenty drivers are using there dev_priv but if you have have more than
> > one option available how does one choose? Would you be okay with passing
> > in a domain flag?
> >
> 
> Well i agree that something would be usefull there so the driver know
> which bind/unbind function it should use. Thomas i would prefer
> passing the bo to the tt_create callback but a flag is the minimum we
> need.

We can discuss this after the merge widow. Jerome your patch does fix a 
regression whereas my proposal is a enhancement.

[Bug 43719] drm-core-next + AGP RV670 = Oops

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43719

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Andy Furniss  2012-01-06 
08:34:23 UTC ---
Patch now in drm-core-next, which is working OK for me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
>> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
>> > > From: Jerome Glisse 
>> > >
>> > > ttm might call the move notify with null new mem placement,
>> > > properly handle this case inside nouveau move notify callback.
>> > This has been fixed already in a -next tree I sent to Dave.
>>
>> I just tried -next with your patch (and two other fixes that I had sent):
>>
>> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
>> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and 
>> don't try to free freed pages
>>
>> and Jerome's AGP fix:
>> ttm: fix agp since ttm tt rework
>>
>> and got the crash (but only with NVidia cards) after swapping between Xorg 
>> and the VCs.
>> Look in drm-next.jpg
>
> http://darnok.org/vga/drm-next.jpg
>
>>
>> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a recent 
>> ttm change")
>> and the patch below by Jerome I still get it to crash (see 
>> drm-next-with-Jerome-fix-revert-Ben.jpg)..
>
> http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
>

Anything special to trigger it ? I can't trigger it with simple gnome3
session (firefox evince ...)

Cheers,
Jerome

[ANNOUNCE] libdrm 2.4.30

2012-01-06 Thread Eric Anholt 
Here's a new release, featuring updated i915_drm.h for gen7 transform
feedback, and intel_decode.c as a library API instead of being copied
around between our various driver components.

Chris Wilson (2):
  intel: Reset vma list upon purge
  tests/gem_flink: Check for MASTER before proceeding

Eric Anholt (18):
  intel: Import intel_decode.c from intel-gpu-tools.
  intel: Make intel_chipset handle devid directly.
  intel: intel: Add IS_GEN[567] macros.
  intel: Reformat intel_decode.c from intel-gpu-tools using Lindent.
  intel: Minor style tweaks after Lindent.
  intel: Get intel_decode.c minimally building.
  intel: Fix Wsigned-compare warnings (soon to be enabled).
  intel: Fix a ton of signed vs unsigned and const char *warnings
  intel: Add printflike warnings for instr_out.
  intel: Fix printf format warnings for intel_decode.
  intel: Remove c99ish variable declarations.
  intel: Turn on normal warnings for intel_decode.c build.
  intel: Disable unused decode_logic_op().
  intel: Add an interface for setting the output file for decode.
  intel: Add a regression test program for intel_decode.c.
  intel: Add regression tests for batch decode.
  intel: Update for new i915_drm.h defines.
  configure: Bump version for 2.4.30

Jesse Barnes (1):
  libdrm: update drm headers from kernel, including new overlay ioctls & 
structs

Johannes Obermayr (1):
  intel/intel_decode.c: Remove #include "intel_decode.h".

git tag: 2.4.30

http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.bz2
MD5:  9f57a68b2c0836b55ebcbc241f6ca175  libdrm-2.4.30.tar.bz2
SHA1: 5ba36a0bcbacbe67e6a2e0d5318ed9455da59bbc  libdrm-2.4.30.tar.bz2
SHA256: cacea9c157ec824ad278a06f4910659b2f3ae69686518ece8d6967843cddcd56  
libdrm-2.4.30.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.gz
MD5:  cd790fb761a83125eceb64162d7d5ce5  libdrm-2.4.30.tar.gz
SHA1: 148936f0c0f83d016c584245493b975d42bd359a  libdrm-2.4.30.tar.gz
SHA256: a64e63a2af08bcab835e758048611cf61c7183dc7e829cad9dceba859245b4bc  
libdrm-2.4.30.tar.gz

-- 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/20120106/42734a81/attachment.pgp>

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> >> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
> >> > > From: Jerome Glisse 
> >> > >
> >> > > ttm might call the move notify with null new mem placement,
> >> > > properly handle this case inside nouveau move notify callback.
> >> > This has been fixed already in a -next tree I sent to Dave.
> >>
> >> I just tried -next with your patch (and two other fixes that I had sent):
> >>
> >> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> >> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page 
> >> and don't try to free freed pages
> >>
> >> and Jerome's AGP fix:
> >> ttm: fix agp since ttm tt rework
> >>
> >> and got the crash (but only with NVidia cards) after swapping between Xorg 
> >> and the VCs.
> >> Look in drm-next.jpg
> >
> > http://darnok.org/vga/drm-next.jpg
> >
> >>
> >> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a 
> >> recent ttm change")
> >> and the patch below by Jerome I still get it to crash (see 
> >> drm-next-with-Jerome-fix-revert-Ben.jpg)..
> >
> > http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
> >
> 
> Anything special to trigger it ? I can't trigger it with simple gnome3
> session (firefox evince ...)

I ran etracer, then switched over to a framebuffer console (Alt-F2), logged in.
Then ran perf record and switched back to etracer. Ran a couple of laps and 
when finished
quit the perf top. On the PCI-e it took a while (so I had to run a couple of 
laps).

On the AGP one it happended immediately, which is no surprise since the code 
looks
to be activated when we do garbage collection and the machine only had 2GB. The
PCIe on has 8GB. Perhaps a better way would be to force the workqueue by 
setting the
pool limits to smaller values.

> 
> Cheers,
> Jerome

[Bug 44536] New: [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

 Bug #: 44536
   Summary: [r300g] bisected - performance regression on 0ad
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: fabio.ped at libero.it
CC: maraeo at gmail.com


This commit [1] lowers 0 A.D. performance from ~28 fps to ~20 fps, confirmed
with LIBGL_SHOW_FPS=1 mesa variable and with in game FPS counter. This is on
0ad alpha 8 on default Oasis map. Tested with current mesa git up to e60daf7
with and without the [1] commit reverted.

The card is:
r300: DRM version: 2.9.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2
r300: GART size: 509 MB, VRAM size: 256 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES


[1]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=93f4e3cb6c1ca303ee1f5c2a2491a8eff33f2633

commit 93f4e3cb6c1ca303ee1f5c2a2491a8eff33f2633
Author: Marek Ol??k 
Date:   Sat Dec 24 08:15:40 2011 +0100

winsys/radeon: move managing GEM domains back to drivers

This partially reverts commit 363ff844753c46ac9c13866627e096b091ea81f8.

It caused severe performance drops in Nexuiz. Reported by Phoronix.

Tested by me on r300g and by IRC people on r600g.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 06, 2012 at 11:53:35AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> > On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
> >  wrote:
> > > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> > >> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> > >> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
> > >> > > From: Jerome Glisse 
> > >> > >
> > >> > > ttm might call the move notify with null new mem placement,
> > >> > > properly handle this case inside nouveau move notify callback.
> > >> > This has been fixed already in a -next tree I sent to Dave.
> > >>
> > >> I just tried -next with your patch (and two other fixes that I had sent):
> > >>
> > >> drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool
> > >> drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page 
> > >> and don't try to free freed pages
> > >>
> > >> and Jerome's AGP fix:
> > >> ttm: fix agp since ttm tt rework
> > >>
> > >> and got the crash (but only with NVidia cards) after swapping between 
> > >> Xorg and the VCs.
> > >> Look in drm-next.jpg
> > >
> > > http://darnok.org/vga/drm-next.jpg
> > >
> > >>
> > >> With your patch removed ("drm/nouveau/ttm: fix crash as a result of a 
> > >> recent ttm change")
> > >> and the patch below by Jerome I still get it to crash (see 
> > >> drm-next-with-Jerome-fix-revert-Ben.jpg)..
> > >
> > > http://darnok.org/vga/drm-next-with-Jerome-fix-revert-Ben.jpg
> > >
> > 
> > Anything special to trigger it ? I can't trigger it with simple gnome3
> > session (firefox evince ...)
> 
> I ran etracer, then switched over to a framebuffer console (Alt-F2), logged 
> in.
> Then ran perf record and switched back to etracer. Ran a couple of laps and 
> when finished
> quit the perf top. On the PCI-e it took a while (so I had to run a couple of 
> laps).
> 
> On the AGP one it happended immediately, which is no surprise since the code 
> looks
> to be activated when we do garbage collection and the machine only had 2GB. 
> The
> PCIe on has 8GB. Perhaps a better way would be to force the workqueue by 
> setting the
> pool limits to smaller values.
>

Still having difficulty to reproduce can you reproduce with the attached
printk debuging patch and provide the log (only few printk preceding the
oops or segfault are interesting).

Cheers,
Jerome

[PATCH] TTM-DEBUG-PRINTK

2012-01-06 Thread Jerome Glisse 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..326b64a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -812,12 +812,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_vma *vma;

+DRM_INFO("%s list (%p %p)\n", __func__, nvbo->vma_list.prev, 
nvbo->vma_list.next);
list_for_each_entry(vma, &nvbo->vma_list, head) {
if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem->mm_node);
} else
if (new_mem && new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
+DRM_INFO("%s vma %p new mem %p %d pages\n", __func__, vma, new_mem, 
new_mem->num_pages);
nouveau_vm_map_sg(vma, 0, new_mem->
  num_pages << PAGE_SHIFT,
  new_mem->mm_node);
-- 
1.7.5.4


--IJpNTDwzlM2Ie8A6--

[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=30227

--- Comment #12 from Michel D?nzer  2012-01-06 10:37:08 
PST ---
FWIW, http://lists.freedesktop.org/archives/dri-devel/2012-January/017932.html
should increase the chance of recovering from a GPU lockup, or at least being
able to reboot cleanly, on a big endian host.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Konrad Rzeszutek Wilk 
> Still having difficulty to reproduce can you reproduce with the attached
> printk debuging patch and provide the log (only few printk preceding the
> oops or segfault are interesting).

http://darnok.org/vga/move_notify-v212.log

> 
> Cheers,
> Jerome

> >From 862e2cc6d35d85404ed24d24c5a5c49c5ef45fc7 Mon Sep 17 00:00:00 2001
> From: Jerome Glisse 
> Date: Fri, 6 Jan 2012 13:20:08 -0500
> Subject: [PATCH] TTM-DEBUG-PRINTK
> 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 724b41a..326b64a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -812,12 +812,14 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> struct ttm_mem_reg *new_mem)
>   struct nouveau_bo *nvbo = nouveau_bo(bo);
>   struct nouveau_vma *vma;
>  
> +DRM_INFO("%s list (%p %p)\n", __func__, nvbo->vma_list.prev, 
> nvbo->vma_list.next);
>   list_for_each_entry(vma, &nvbo->vma_list, head) {
>   if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
>   nouveau_vm_map(vma, new_mem->mm_node);
>   } else
>   if (new_mem && new_mem->mem_type == TTM_PL_TT &&
>   nvbo->page_shift == vma->vm->spg_shift) {
> +DRM_INFO("%s vma %p new mem %p %d pages\n", __func__, vma, new_mem, 
> new_mem->num_pages);
>   nouveau_vm_map_sg(vma, 0, new_mem->
> num_pages << PAGE_SHIFT,
> new_mem->mm_node);
> -- 
> 1.7.5.4
>

[PATCH] drm/nouveau: fix ttm move notify callback

2012-01-06 Thread Jerome Glisse 
On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > Still having difficulty to reproduce can you reproduce with the attached
> > printk debuging patch and provide the log (only few printk preceding the
> > oops or segfault are interesting).
> 
> http://darnok.org/vga/move_notify-v212.log
> 

Looks like nouveau doesn't like move notify being call on driver
shutdown or when somethings om nv50 is down. Ben i think you will
be better at finding a fix for that than me.

Cheers,
Jerome

[Bug 44536] [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

--- Comment #1 from Marek Ol??k  2012-01-06 13:54:57 PST 
---
If I revert that commit, Nexuiz will be slow again. I can't do that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44536] [r300g] bisected - performance regression on 0ad

2012-01-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=44536

Marek Ol??k  changed:

   What|Removed |Added

  Component|Drivers/DRI/r300|Drivers/Gallium/r300

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.