Closed source userspace graphics drivers with an open source kernel component

["C. Bergström"]

Xavier Bestel wrote:
> On Fri, 2010-07-02 at 19:07 +0700, "C. Bergstr?m" wrote:
>   
>> Dave Airlie wrote:
>> 
>>> What potential? there are maybe 6 players on the ARM graphics scene
>>>
>>> ...
>>> Nvidia - well we know their position will never change.
>>>   
>>>   
>> Never say never.  I have every reason to believe that Nvidia would 
>> respond to market demand.
>> 
>
> Could you share those interesting reasons with us ?
>   
I thought I stated that the main reason was market demand?

(Some of my own comments not representing any company)
By market I mean revenue... The Linux and FOSS world isn't exactly a 
huge market for high end graphics cards and total sales.  With the Tesla 
series of cards and most HPC clusters behing Linux powered this has the 
potential to change things.  Maybe I'm too optimistic and biased, but 
from my perspective I think there's a change in the winds coming..

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

> Sure, but you still slammed, and this affected in first order mostly 
> Qualcomm, instead
> of stating that you simply do not want to be involved.

I have no choice but to be involved, again you seem to misunderstand
what my position is.

>
>> They'll keep shipping closed stuff, just like they are now. Are you
>> going to reverse engineer the userspace drivers, so people who care
>> about open and free software platforms can use these drivers? (or have
>> you already signed NDAs saying you can't). Why should we maintain a
>> bunch of kernel code, when they are hiding away all the really useful
>> stuff that people could improve.
>
> Maintaining this exact code is not _your_ job, and you should've stated just 
> that.

Maintaining kernel graphics drivers is my responsibility, a lot of
days i wish it wasn't, and I'm sure some day it won't be, but until
then I have to provide guidance on how things should work. Again you
should look at what being a kernel maintainer is.

>
> You will need to restate this every time anyway, unless you somehow manage to 
> get your
> rather daunting and loud statement to be the first thing such corporations 
> management
> people at linux.com, which is what people type in their browser first.

I'm sure I will, but now I can just point people at this rather public
statement as opposed to private emails.
>
> Heh, i could make a really nasty statement here, but i wont.

Please do, since you've proved you are clueless about this position entails.

> Hrm, i only see _very_ old docs getting updated, and none produced.
>
> I still have docs which are pretty ready to be shipped (from 2007), under 
> uncertain
> legal status (the ati game was fun!), which were never made public. I am sure 
> that
> bridgman, gave you these docs too, but under even more shady circumstances.

Shady circumstances? you might want to ask your lawyer before making
statements like that on a public mailing list.

>> The code doesn't exist, there is no userspace code to be the
>> documents, if you read what I said, documents would be a good start in
>> lieu of code, but code is perfectly fine.
>
>> Imagintaion technologies seriously? they've never ever taken one step
>> towards opening anything, I don't think this statement is suddenly
>> going to jumpstart them.
>
>> Maybe you should disclose what NDAs you currently are under and who
>> pays your bills, since you accuse me of Red Hat mind-control.
>
> Oh, i now work for basysKom, a contractor for, amongst others, nokia, which 
> i'm sure
> you knew.

So you honestly think if I allow Nokia and/or Intel to push a poulsbo
driver into the kernel the magic fairies will come along and open the
userspace because they've seen the light?

What incentive does letting someone like Qualcomm etc put all their
kernel code upstream, and ignoring the userspace components do you
think it provides to open the userspace component, for once I'm
interested in your opinion since you seem to have the ARM players all
worked out. Previous experience with most companies has shown they'll
do as little as possible to ensure they can ship as many things as
possible, and this is fine, they need real incentives to follow the
open source rules.

>
>> I'm not sure how the ARM market would benefit from having no userspace
>> 3D drivers just like the x86 market, if you actually were normal you'd
>> realise the ARM people are trying to screw the market just like the
>> desktop people, to save themselves some money, but maybe working on
>> closed drivers has twisted you.
>
> Ah, so you did know.
>
> As a free software graphics driver developer there is little option left but 
> to go
> straight to the ARM world, at least things have potential to move there still.

What potential? there are maybe 6 players on the ARM graphics scene

Imagination Technologies SGX, used in TI and poulsbo/mrst(x86) - no
hope of opening userspace
ARM Mali - not sure what is going on there, I;m going to go with no
hope but would be nice to be proved wrong
Qualcomm SnapDragon - imageon by another name, from what I can and
from talking to Jordan on irc, they don't seem to have much incentive
to bother working on an open userspace
Marvell - maybe OLPC can make them open a userspace for millions of
sales, it doesn't seem to have worked with VIA for 10s of thousands of
persumable sales
Samsung - also holding out hope for something maybe, they seemed to
have some interest once, but not sure what happening now.
Nvidia - well we know their position will never change.

So we should have six completely separate stacks shipping in the
kernel not using drm or kms, but all standalone, all with closed
userspace drivers, with no maintainer, thanks that is not a future I'm
interested in, and generally from experience in Linux it isn't
something we've had much luck with before, wireless, networking, sw
raid, etc all have this sort of vendor demands and it took independent
maintainer pushback to achieve some cooperation and get what we 

[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining

[Justin P. Mattock]

On 07/02/10 13:04, Justin P. Mattock wrote:
> this is new(below) has anybody reported/bisected hit this yet
> (if not I'll bisect it)
>
> [drm] Num pipes: 1
> [   29.742432] [drm] writeback test succeeded in 1 usecs
> [   30.089717] X:2252 conflicting memory types 4000-4800 
> uncached-minus<->write-combining
> [   30.089721] reserve_memtype failed 0x4000-0x4800, track 
> uncached-minus, req uncached-minus
> [   30.123517] [drm] Num pipes: 1
> [   30.351017] X:2252 freeing invalid memtype 4000-4800
> [   30.354255] CPU 0
> [   30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco 
> xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat 
> xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack 
> nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci 
> firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw 
> ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 
> lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic 
> cbc des_generic cast5 blowfish serpent camellia twofish twofish_common 
> ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart 
> rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor 
> mperf appletouch applesmc uvcvideo[   30.354255]
> [   30.354255] Pid: 2252, comm: X Not tainted 
> 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2
> [   30.354255] RIP: 0010:[]  [] 
> radeon_read_ring_rptr+0x2b/0x2f [radeon]
> [   30.354255] RSP: 0018:8800360dfc80  EFLAGS: 00010202
> [   30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: 
> c9cf8000
> [   30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 
> 8800385e8848
> [   30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 
> 0010
> [   30.354255] R10:  R11: ea930af0 R12: 
> 0010
> [   30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 
> 8800385e8178
> [   30.354255] FS:  7f0aaa823840() GS:880001a0() 
> knlGS:
> [   30.354255] CS:  0010 DS:  ES:  CR0: 80050033
> [   30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 
> 06f0
> [   30.354255] DR0:  DR1:  DR2: 
> 
> [   30.354255] DR3:  DR6: 0ff0 DR7: 
> 0400
> [   30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 
> 880033dc5c40)
> [   30.354255]  8800360dfc90 a0358130 8800360dfca8 
> a035881c
> [   30.354255] <0> 8800385e8848 8800360dfcc8 a0359ac7 
> 
> [   30.354255] <0> 8800385e8848 8800360dfce8 a035c961 
> 8800385e8848
> [   30.354255]  [] radeon_get_ring_head+0x11/0x3c 
> [radeon]
> [   30.354255]  [] radeon_commit_ring+0x48/0x97 
> [radeon]
> [   30.354255]  [] radeon_do_cp_idle+0x140/0x14d 
> [radeon]
> [   30.354255]  [] 
> radeon_apply_surface_regs+0x22/0x138 [radeon]
> [   30.354255]  [] free_surface+0xd8/0xee [radeon]
> [   30.354255]  [] radeon_driver_lastclose+0x3c/0x56 
> [radeon]
> [   30.354255]  [] drm_lastclose+0x44/0x2ad [drm]
> [   30.354255]  [] drm_release+0x656/0x6a3 [drm]
> [   30.354255]  [] put_files_struct+0x65/0xb3
> [   30.354255]  [] exit_files+0x46/0x4e
> [   30.354255]  [] do_exit+0x214/0x69f
> [   30.354255]  [] ? fput+0x1e2/0x1f1
> [   30.354255]  [] do_group_exit+0x72/0x9a
> [   30.354255]  [] sys_exit_group+0x12/0x16
> [   30.354255]  [] system_call_fastpath+0x16/0x1b
> [   30.354255]  RSP 
> [   31.312879] ---[ end trace 9a7b92300d4121f6 ]---
> [   30.354255]  [] fput+0x122/0x1f1
> [   30.354255]  [] filp_close+0x63/0x6d
>
> Justin P. Mattock


o.k. finished bisecting.. the results point to this: 6a4f3b523 doing a 
git revert gets me to startx without crashing and burning.
the problem code is this:
new->subtree_max_end = new->end;

which sends me to: (if im reading correctly)
if (match->type != found_type && newtype == NULL)
 goto failure;

so how/what might be happening here?!

Justin P. Mattock

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

On Fri, Jul 2, 2010 at 9:12 PM, Luc Verhaegen  wrote:
> On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote:
>> Luc, can you please take your corporate bullshit out of this? ?I can
>> assume you know Dave personally and should be clearly aware that he's
>> everything but a corporate drone.
>
> Yes, with mails like this he clearly shows that he isn't a corporate drone.
>

Luc, this isn't phoronix forums, the adults are talking here, run along now.

Dave.

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

>
> Yes, this a mess indeed.
>
> But i fear that this a mess that cannot be fixed, in its entirety, in a 
> single shot.
>
> Qualcomm making this code available already clearly shows the will and 
> determination of
> some people inside qualcomm to do The Right Thing.
>
> This is Qualcomms first big step on the graphics side, where IP is always 
> amongst the
> heaviest. I am certain that Qualcomm wants to go further, but since Qualcomm 
> most
> likely licenses some parts of their graphics, Qualcomm can only open up those 
> bits that
> they truly own, and then use mainly market/sales-volume driven pressure to 
> get the
> original IP owner to play along.

They own quite a lot of the IP in the 3D core, having bought it from
AMD, you can see the CP packets and PM4 stuff just like in radeon.

>
> You should also take into account who Jordan is. He is one of the guys who 
> worked the
> Geode before AMD decided to drop that, which is when he got hired by 
> Qualcomm. He worked on
> both the graphics drivers and on (then still) LinuxBIOS. I know that redhat 
> has no
> intention of going near coreboot, but in my world one cannot become more 
> free, hardware
> wise, than supporting coreboot. This gives me very good hopes that this is a 
> serious
> attempt by qualcomm to go somewhere, and that this is not some lame attempt 
> to grab
> marketing attention.

I know who Jordan is well from AMD, and I've stated this isn't a
Qualcomm only thing, but companies need to understand that putting
stuff into the kernel is part of a bargain, where you get the benefits
of all the work everyone has done on the kernel and they get the
benefits of being able to do stuff with the code you provide, only
giving us a half arsed interface to the hw and hiding all the good
stuff in userspace isn't accepting this bargain. You can say what you
like about liceneses and legalese but Linus picked the GPL for this
sort of everyone gives what they get.

> Now that you slammed the door on these guys (and on others in the process), 
> what do you
> think the response would be? Where will this get us to in the end?

They'll keep shipping closed stuff, just like they are now. Are you
going to reverse engineer the userspace drivers, so people who care
about open and free software platforms can use these drivers? (or have
you already signed NDAs saying you can't). Why should we maintain a
bunch of kernel code, when they are hiding away all the really useful
stuff that people could improve.

>> b) verifying the sanity of the userspace API.
>> 1. Security: GPUs can do a lot of damage if left at home alone, since
>> mostly you are submitting command streams unverified into the GPU and
>> won't tell us what they mean, there is little way we can work out if
>> the GPU is going to over-write my passwd file to get 5 fps more in
>> quake. Now newer GPUs have at least started having MMUs, but again
>> we've no idea if that is the only way they work without docs or a lot
>> of trust.
>
> This makes me wonder: Why do you even care?
>
> If redhat was working with qualcomm, you would not have taken this stance 
> here at all.

I would, some points
(a) Red Hat is the company I work for.
(b) Red Hat doesn't really care about this stuff at all.
(c) I'm the kernel maintainer for far longer that I worked for Red
Hat, I also work a lot with Intel at Red Hat and I've told them the
same thing, and VIA and now I'm stating it so I don't have to restate
individually to every company again.

> If so, why couldn't you have stated "please guys, have fun with what you are 
> doing, but
> i will not be responsible for it" in a different way.

You don't understand what being a kernel maintainer is do you? at all?

> Now, it is interesting how you now are demanding documentation. When did 
> recent and
> relevant hw documentation happen for ATI? This pretty much died together when 
> the
> ATI<->SuSE relationship died, as the cooperation of SuSE and AMD is how 
> documentation
> was forced out of ATI in the first place, and ATI more and more found ways to 
> get rid
> of this responsibility, or overhead as bridgman would most likely name it.

Wierd I'm still seeing new docs being produced and old docs being
updated, not as fast as I'd like but I understand how many people
there is working on it and I'd rather we also got fixes for all the
current stuff done as well.


> If you are backing this reasoning for ATI, what is wrong with this code being 
> the
> documentation for Qualcomm?

The code doesn't exist, there is no userspace code to be the
documents, if you read what I said, documents would be a good start in
lieu of code, but code is perfectly fine.

> Heh, in some of these cases, not having looked at this code in detail yet, 
> such code
> predates kms, and drm might not have provided what was needed. Not wanting to
> completely diminish the responsibility of qualcomm (or the other companies 
> who are
> working or are forced to work like this), you might want to 

[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28294

--- Comment #16 from Tom Stellard  2010-07-02 20:04:47 
PDT ---
Can you try again with the current git master branch?  You should see less
errors now.

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

Closed source userspace graphics drivers with an open source kernel component

["C. Bergström"]

Dave Airlie wrote:
> What potential? there are maybe 6 players on the ARM graphics scene
>
> ...
> Nvidia - well we know their position will never change.
>   
Never say never.  I have every reason to believe that Nvidia would 
respond to market demand.

*fingers crossed*

./C

Closed source userspace graphics drivers with an open source kernel component

[Anton Vorontsov]

On Fri, Jul 02, 2010 at 01:10:29PM +0200, Luc Verhaegen wrote:
[...]
> > They'll keep shipping closed stuff, just like they are now. Are you
> > going to reverse engineer the userspace drivers, so people who care
> > about open and free software platforms can use these drivers? (or have
> > you already signed NDAs saying you can't). Why should we maintain a
> > bunch of kernel code, when they are hiding away all the really useful
> > stuff that people could improve.
> 
> Maintaining this exact code is not _your_ job, [...]

Correct, it's not solely his job, but it's also every kernel
developers' job.

When I change kernel API I have to grep through all the kernel
drivers, sometimes understand how they work, and then make the
change to the whole kernel source tree.

And I would not want to maintain this code, as these drivers
are wasting my time without returning anything back.

It was said many times. Actually, so many times that it started
to become boring to repeat, and the Kernel Driver Statement was
written:

"We, the undersigned Linux kernel developers, consider any
 closed-source Linux kernel module or driver to be harmful and
 undesirable."

http://www.linuxfoundation.org/collaborate/publications/kernel-driver-statement

While the doc mostly says "kernel code", I truly believe that
there's actually no huge difference between "closed-source
kernel module" and "open source dummy kernel module + userspace
blob".

Both are closed source solutions, and generally useless for the
open source. And, what is worse, the last one is harmful for me
personally.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

Closed source userspace graphics drivers with an open source kernel component

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luc Verhaegen wrote:

> Since redhat is then not working with qualcomm, why is this then your 
> responsibility?

I find that sentiment surprising from somebody who has actually met Dave. :/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwuhy0ACgkQX1gOwKyEAw/Q9QCfd0qcveuzyBVOIqW0yerggbLu
EzIAn16kyWeZ+fpVkmirQghbYFLGrAgx
=CeEy
-END PGP SIGNATURE-

Closed source userspace graphics drivers with an open source kernel component

[Xavier Bestel]

On Fri, 2010-07-02 at 19:07 +0700, "C. Bergstr?m" wrote:
> Dave Airlie wrote:
> > What potential? there are maybe 6 players on the ARM graphics scene
> >
> > ...
> > Nvidia - well we know their position will never change.
> >   
> Never say never.  I have every reason to believe that Nvidia would 
> respond to market demand.

Could you share those interesting reasons with us ?

Xav

[Intel-gfx] [PATCH 07/11] drm/i915: prepare for fair lru eviction

[Chris Wilson]

On Fri,  2 Jul 2010 15:02:17 +0100, Chris Wilson  
wrote:
> From: Daniel Vetter 
> 
> This does two little changes:
> 
> - Add an alignment parameter for evict_something. It's not really great to
>   whack a carefully sized hole into the gtt with the wrong alignment.
>   Especially since the fallback path is a full evict.
> 
> - With the inactive scan stuff we need to evict more that one object, so
>   move the unbind call into the helper function that scans for the object
>   to be evicted, too.  And adjust its name.
> 
> No functional changes in this patch, just preparation.
> 
> Signed-Off-by: Daniel Vetter 
Signed-off-by: Chris Wilson 

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 28860] [r300g] Yo Frankie crash: assertion failure / Too many hardware temporaries used

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #4 from Sven Arvidsson  2010-07-02 15:22:54 PDT ---
Created an attachment (id=36701)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=36701)
Backtrace of crash

(In reply to comment #3)
> 
> This looks similar to bug 28169, should be fixed with commit
> 6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a

Still crashes with the same assertion failure. I'm attaching a backtrace.

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

[PATCH 11/11] drm/i915: Maintain LRU order of inactive objects upon access by CPU

[Chris Wilson]

In order to reduce the penalty of fallbacks under memory pressure and to
avoid a potential immediate ping-pong of evicting a mmaped buffer, we
move the object to the tail of the inactive list when a page is freshly
faulted or the object is moved into the CPU domain.

We choose not to protect the CPU objects from casual eviction,
preferring to keep the GPU active for as long as possible.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb7d6a9..26d0345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1036,6 +1036,10 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
}

+   /* Maintain LRU order of "inactive" objects */
+   if (ret == 0 && obj_priv->gtt_space && !obj_priv->active)
+   list_move_tail(_priv->list, _priv->mm.inactive_list);
+
drm_gem_object_unreference(obj);
mutex_unlock(>struct_mutex);
return ret;
@@ -1169,6 +1173,9 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}

+   if (!obj_priv->active)
+   list_move_tail(_priv->list, _priv->mm.inactive_list);
+
pfn = ((dev->agp->base + obj_priv->gtt_offset) >> PAGE_SHIFT) +
page_offset;

-- 
1.7.1

[PATCH 10/11] drm/i915: Implement fair lru eviction across both rings.

[Chris Wilson]

Based in a large part upon Daniel Vetter's implementation and adapted
for handling multiple rings in a single pass.

This should lead to better gtt usage and fixes the page-fault-of-doom
triggered. The fairness is provided by scanning through the GTT space
amalgamating space in rendering order. As soon as we have a contiguous
space in the GTT large enough for the new object (and its alignment),
evict any object which lies within that space. This should keep more
objects resident in the GTT.

Doing throughput testing on a PineView machine with cairo-perf-trace
indicates that there is very little difference with the new LRU scan,
perhaps a small improvement.

Reference:

  Bug 15911 - Intermittent X crash (freeze)
  https://bugzilla.kernel.org/show_bug.cgi?id=15911

  Bug 20152 - cannot view JPG in firefox when running UXA
  https://bugs.freedesktop.org/show_bug.cgi?id=20152

  Bug 24369 - Hang when scrolling firefox page with window in front
  https://bugs.freedesktop.org/show_bug.cgi?id=24369

  Bug 28478 - Intermittent graphics lockups due to overflow/loop
  https://bugs.freedesktop.org/show_bug.cgi?id=28478

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |2 +
 drivers/gpu/drm/i915/i915_gem_evict.c |  259 +++--
 2 files changed, 121 insertions(+), 140 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6a0bd0..8e9e6a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -652,6 +652,8 @@ struct drm_i915_gem_object {
struct list_head list;
/** This object's place on GPU write list */
struct list_head gpu_write_list;
+   /** This object's place on eviction list */
+   struct list_head evict_list;

/**
 * This is set if the object is on the active or flushing lists
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index bf4d199..87efbab 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -31,170 +31,149 @@
 #include "i915_drv.h"
 #include "i915_drm.h"

-static inline int
-i915_gem_object_is_purgeable(struct drm_i915_gem_object *obj_priv)
-{
-   return obj_priv->madv == I915_MADV_DONTNEED;
-}
-
-static int
-i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
- unsigned alignment, int *found)
+static struct drm_i915_gem_object *
+i915_gem_next_active_object(struct drm_device *dev,
+   struct list_head **render_iter,
+   struct list_head **bsd_iter)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
-   struct drm_gem_object *obj;
-   struct drm_i915_gem_object *obj_priv;
-   struct drm_gem_object *best = NULL;
-   struct drm_gem_object *first = NULL;
+   struct drm_i915_gem_object *render_obj = NULL, *bsd_obj = NULL;

-   /* Try to find the smallest clean object */
-   list_for_each_entry(obj_priv, _priv->mm.inactive_list, list) {
-   struct drm_gem_object *obj = _priv->base;
-   if (obj->size >= min_size) {
-   if ((!obj_priv->dirty ||
-i915_gem_object_is_purgeable(obj_priv)) &&
-   (!best || obj->size < best->size)) {
-   best = obj;
-   if (best->size == min_size)
-   break;
-   }
-   if (!first)
-   first = obj;
-   }
-   }
-
-   obj = best ? best : first;
-
-   if (!obj) {
-   *found = 0;
-   return 0;
-   }
+   if (*render_iter != _priv->render_ring.active_list)
+   render_obj = list_entry(*render_iter,
+   struct drm_i915_gem_object,
+   list);

-   *found = 1;
+   if (HAS_BSD(dev)) {
+   if (*bsd_iter != _priv->bsd_ring.active_list)
+   bsd_obj = list_entry(*bsd_iter,
+struct drm_i915_gem_object,
+list);

-#if WATCH_LRU
-   DRM_INFO("%s: evicting %p\n", __func__, obj);
-#endif
-   obj_priv = to_intel_bo(obj);
-   BUG_ON(obj_priv->pin_count != 0);
-   BUG_ON(obj_priv->active);
+   if (render_obj == NULL) {
+   *bsd_iter = (*bsd_iter)->next;
+   return bsd_obj;
+   }

-   /* Wait on the rendering and unbind the buffer. */
-   return i915_gem_object_unbind(obj);
-}
+   if (bsd_obj == NULL) {
+   *render_iter = (*render_iter)->next;
+   return render_obj;
+   }

-static void
-i915_gem_flush_ring(struct drm_device *dev,
- 

[PATCH 09/11] drm/i915: Move the eviction logic to its own file.

[Chris Wilson]

The eviction code is the gnarly underbelly of memory management, and is
clearer if kept separated from the normal domain management in GEM.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/i915_drv.h   |6 +
 drivers/gpu/drm/i915/i915_gem.c   |  234 +-
 drivers/gpu/drm/i915/i915_gem_evict.c |  263 +
 4 files changed, 272 insertions(+), 232 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_evict.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index da78f2c..384fd45 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -8,6 +8,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
   i915_suspend.o \
  i915_gem.o \
  i915_gem_debug.o \
+ i915_gem_evict.o \
  i915_gem_tiling.o \
  i915_trace_points.o \
  intel_display.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65cf336..b6a0bd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -964,6 +964,7 @@ int i915_gem_init_ringbuffer(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 int i915_gem_do_init(struct drm_device *dev, unsigned long start,
 unsigned long end);
+int i915_gpu_idle(struct drm_device *dev);
 int i915_gem_idle(struct drm_device *dev);
 uint32_t i915_add_request(struct drm_device *dev,
struct drm_file *file_priv,
@@ -989,6 +990,11 @@ int i915_gem_object_flush_write_domain(struct 
drm_gem_object *obj);
 void i915_gem_shrinker_init(void);
 void i915_gem_shrinker_exit(void);

+/* i915_gem_evict.c */
+int i915_gem_evict_something(struct drm_device *dev, int min_size, unsigned 
alignment);
+int i915_gem_evict_everything(struct drm_device *dev);
+int i915_gem_evict_inactive(struct drm_device *dev);
+
 /* i915_gem_tiling.c */
 void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);
 void i915_gem_object_do_bit_17_swizzle(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b867c4..bb7d6a9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,9 +49,6 @@ static int i915_gem_object_wait_rendering(struct 
drm_gem_object *obj);
 static int i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
   unsigned alignment);
 static void i915_gem_clear_fence_reg(struct drm_gem_object *obj);
-static int i915_gem_evict_something(struct drm_device *dev, int min_size,
-   unsigned alignment);
-static int i915_gem_evict_from_inactive_list(struct drm_device *dev);
 static int i915_gem_phys_pwrite(struct drm_device *dev, struct drm_gem_object 
*obj,
struct drm_i915_gem_pwrite *args,
struct drm_file *file_priv);
@@ -1869,19 +1866,6 @@ i915_gem_flush(struct drm_device *dev,
flush_domains);
 }

-static void
-i915_gem_flush_ring(struct drm_device *dev,
-  uint32_t invalidate_domains,
-  uint32_t flush_domains,
-  struct intel_ring_buffer *ring)
-{
-   if (flush_domains & I915_GEM_DOMAIN_CPU)
-   drm_agp_chipset_flush(dev);
-   ring->flush(dev, ring,
-   invalidate_domains,
-   flush_domains);
-}
-
 /**
  * Ensures that all rendering to the object has completed and the object is
  * safe to unbind from the GTT or access from the CPU.
@@ -1991,53 +1975,7 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
return 0;
 }

-static int
-i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
- unsigned alignment, int *found)
-{
-   drm_i915_private_t *dev_priv = dev->dev_private;
-   struct drm_gem_object *obj;
-   struct drm_i915_gem_object *obj_priv;
-   struct drm_gem_object *best = NULL;
-   struct drm_gem_object *first = NULL;
-
-   /* Try to find the smallest clean object */
-   list_for_each_entry(obj_priv, _priv->mm.inactive_list, list) {
-   struct drm_gem_object *obj = _priv->base;
-   if (obj->size >= min_size) {
-   if ((!obj_priv->dirty ||
-i915_gem_object_is_purgeable(obj_priv)) &&
-   (!best || obj->size < best->size)) {
-   best = obj;
-   if (best->size == min_size)
-   break;
-   }
-   if (!first)
-   first = obj;
-   }
-   }
-
-   obj = best ? best : first;
-
-   if (!obj) {
-   *found = 0;
-   return 0;
-   }
-
-

[PATCH 08/11] drm/i915: Use a common seqno for all rings.

[Chris Wilson]

This will be used by the eviction logic to maintain fairness between the
rings.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |3 +-
 drivers/gpu/drm/i915/i915_gem.c |2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   46 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
 4 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 98e6980..65cf336 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -236,6 +236,7 @@ typedef struct drm_i915_private {
struct pci_dev *bridge_dev;
struct intel_ring_buffer render_ring;
struct intel_ring_buffer bsd_ring;
+   uint32_t next_seqno;

drm_dma_handle_t *status_page_dmah;
void *seqno_page;
@@ -553,8 +554,6 @@ typedef struct drm_i915_private {
 */
struct delayed_work retire_work;

-   uint32_t next_gem_seqno;
-
/**
 * Waiting sequence number, if any
 */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d4bcf71..1b867c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4701,6 +4701,8 @@ i915_gem_init_ringbuffer(struct drm_device *dev)
goto cleanup_render_ring;
}

+   dev_priv->next_seqno = 1;
+
return 0;

 cleanup_render_ring:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2a3d2fa..ec04238 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -33,18 +33,35 @@
 #include "i915_drm.h"
 #include "i915_trace.h"

+static u32 i915_gem_get_seqno(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev->dev_private;
+   u32 seqno;
+
+   seqno = dev_priv->next_seqno;
+
+   /* reserve 0 for non-seqno */
+   if (++dev_priv->next_seqno == 0)
+   dev_priv->next_seqno = 1;
+
+   return seqno;
+}
+
 static void
 render_ring_flush(struct drm_device *dev,
struct intel_ring_buffer *ring,
u32 invalidate_domains,
u32 flush_domains)
 {
+   drm_i915_private_t *dev_priv = dev->dev_private;
+   u32 cmd;
+
 #if WATCH_EXEC
DRM_INFO("%s: invalidate %08x flush %08x\n", __func__,
  invalidate_domains, flush_domains);
 #endif
-   u32 cmd;
-   trace_i915_gem_request_flush(dev, ring->next_seqno,
+
+   trace_i915_gem_request_flush(dev, dev_priv->next_seqno,
 invalidate_domains, flush_domains);

if ((invalidate_domains | flush_domains) & I915_GEM_GPU_DOMAINS) {
@@ -233,9 +250,10 @@ render_ring_add_request(struct drm_device *dev,
struct drm_file *file_priv,
u32 flush_domains)
 {
-   u32 seqno;
drm_i915_private_t *dev_priv = dev->dev_private;
-   seqno = intel_ring_get_seqno(dev, ring);
+   u32 seqno;
+
+   seqno = i915_gem_get_seqno(dev);

if (IS_GEN6(dev)) {
BEGIN_LP_RING(6);
@@ -405,7 +423,9 @@ bsd_ring_add_request(struct drm_device *dev,
u32 flush_domains)
 {
u32 seqno;
-   seqno = intel_ring_get_seqno(dev, ring);
+
+   seqno = i915_gem_get_seqno(dev);
+
intel_ring_begin(dev, ring, 4);
intel_ring_emit(dev, ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(dev, ring,
@@ -539,7 +559,7 @@ render_ring_dispatch_gem_execbuffer(struct drm_device *dev,
exec_start = (uint32_t) exec_offset + exec->batch_start_offset;
exec_len = (uint32_t) exec->batch_len;

-   trace_i915_gem_request_submit(dev, dev_priv->mm.next_gem_seqno + 1);
+   trace_i915_gem_request_submit(dev, dev_priv->next_seqno + 1);

pipeline = exec->flags & I915_EXEC_PIPELINE_MASK;
if (pipeline != ring->pipeline) {
@@ -838,18 +858,6 @@ void intel_fill_struct(struct drm_device *dev,
intel_ring_advance(dev, ring);
 }

-u32 intel_ring_get_seqno(struct drm_device *dev,
-   struct intel_ring_buffer *ring)
-{
-   u32 seqno;
-   seqno = ring->next_seqno;
-
-   /* reserve 0 for non-seqno */
-   if (++ring->next_seqno == 0)
-   ring->next_seqno = 1;
-   return seqno;
-}
-
 struct intel_ring_buffer render_ring = {
.name   = "render ring",
.regs   = {
@@ -867,7 +875,6 @@ struct intel_ring_buffer render_ring = {
.head   = 0,
.tail   = 0,
.space  = 0,
-   .next_seqno = 1,
.user_irq_refcount  = 0,
.irq_gem_seqno  = 0,
.waiting_gem_seqno  = 0,
@@ -906,7 +913,6 @@ struct intel_ring_buffer bsd_ring = {
.head   = 0,
.tail  

[PATCH 07/11] drm/i915: prepare for fair lru eviction

[Chris Wilson]

From: Daniel Vetter 

This does two little changes:

- Add an alignment parameter for evict_something. It's not really great to
  whack a carefully sized hole into the gtt with the wrong alignment.
  Especially since the fallback path is a full evict.

- With the inactive scan stuff we need to evict more that one object, so
  move the unbind call into the helper function that scans for the object
  to be evicted, too.  And adjust its name.

No functional changes in this patch, just preparation.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c |   67 ---
 1 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bfc7269..d4bcf71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
 #include 
 #include 

+static uint32_t i915_gem_get_fence_alignment(struct drm_gem_object *obj);
 static int i915_gem_object_flush_gpu_write_domain(struct drm_gem_object *obj);
 static void i915_gem_object_flush_gtt_write_domain(struct drm_gem_object *obj);
 static void i915_gem_object_flush_cpu_write_domain(struct drm_gem_object *obj);
@@ -48,7 +49,8 @@ static int i915_gem_object_wait_rendering(struct 
drm_gem_object *obj);
 static int i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
   unsigned alignment);
 static void i915_gem_clear_fence_reg(struct drm_gem_object *obj);
-static int i915_gem_evict_something(struct drm_device *dev, int min_size);
+static int i915_gem_evict_something(struct drm_device *dev, int min_size,
+   unsigned alignment);
 static int i915_gem_evict_from_inactive_list(struct drm_device *dev);
 static int i915_gem_phys_pwrite(struct drm_device *dev, struct drm_gem_object 
*obj,
struct drm_i915_gem_pwrite *args,
@@ -313,7 +315,8 @@ i915_gem_object_get_pages_or_evict(struct drm_gem_object 
*obj)
if (ret == -ENOMEM) {
struct drm_device *dev = obj->dev;

-   ret = i915_gem_evict_something(dev, obj->size);
+   ret = i915_gem_evict_something(dev, obj->size,
+  
i915_gem_get_fence_alignment(obj));
if (ret)
return ret;

@@ -1988,10 +1991,12 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
return 0;
 }

-static struct drm_gem_object *
-i915_gem_find_inactive_object(struct drm_device *dev, int min_size)
+static int
+i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
+ unsigned alignment, int *found)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_gem_object *obj;
struct drm_i915_gem_object *obj_priv;
struct drm_gem_object *best = NULL;
struct drm_gem_object *first = NULL;
@@ -2005,14 +2010,31 @@ i915_gem_find_inactive_object(struct drm_device *dev, 
int min_size)
(!best || obj->size < best->size)) {
best = obj;
if (best->size == min_size)
-   return best;
+   break;
}
if (!first)
first = obj;
}
}

-   return best ? best : first;
+   obj = best ? best : first;
+
+   if (!obj) {
+   *found = 0;
+   return 0;
+   }
+
+   *found = 1;
+
+#if WATCH_LRU
+   DRM_INFO("%s: evicting %p\n", __func__, obj);
+#endif
+   obj_priv = to_intel_bo(obj);
+   BUG_ON(obj_priv->pin_count != 0);
+   BUG_ON(obj_priv->active);
+
+   /* Wait on the rendering and unbind the buffer. */
+   return i915_gem_object_unbind(obj);
 }

 static int
@@ -2098,11 +2120,11 @@ i915_gem_evict_everything(struct drm_device *dev)
 }

 static int
-i915_gem_evict_something(struct drm_device *dev, int min_size)
+i915_gem_evict_something(struct drm_device *dev,
+int min_size, unsigned alignment)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
-   struct drm_gem_object *obj;
-   int ret;
+   int ret, found;

struct intel_ring_buffer *render_ring = _priv->render_ring;
struct intel_ring_buffer *bsd_ring = _priv->bsd_ring;
@@ -2115,20 +2137,11 @@ i915_gem_evict_something(struct drm_device *dev, int 
min_size)
/* If there's an inactive buffer available now, grab it
 * and be done.
 */
-   obj = i915_gem_find_inactive_object(dev, min_size);
-   if (obj) {
-   struct drm_i915_gem_object *obj_priv;
-
-#if WATCH_LRU
-   DRM_INFO("%s: evicting %p\n", __func__, obj);
-#endif
-   obj_priv = 

[PATCH 06/11] drm: implement helper functions for scanning lru list

[Chris Wilson]

From: Daniel Vetter 

These helper functions can be used to efficiently scan lru list
for eviction. Eviction becomes a three stage process:
1. Scanning through the lru list until a suitable hole has been found.
2. Scan backwards to restore drm_mm consistency and find out which
   objects fall into the hole.
3. Evict the objects that fall into the hole.

These helper functions don't allocate any memory (at the price of
not allowing any other concurrent operations). Hence this can also be
used for ttm (which does lru scanning under a spinlock).

Evicting objects in this fashion should be more fair than the current
approach by i915 (scan the lru for a object large enough to contain
the new object). It's also more efficient than the current approach used
by ttm (uncoditionally evict objects from the lru until there's enough
free space).

Signed-Off-by: Daniel Vetter 
Acked-by: Thomas Hellstrom 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_mm.c |  167 -
 include/drm/drm_mm.h |   15 -
 2 files changed, 177 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index fd86a6c..da99edc 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -53,9 +53,9 @@ static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, 
int atomic)
struct drm_mm_node *child;

if (atomic)
-   child = kmalloc(sizeof(*child), GFP_ATOMIC);
+   child = kzalloc(sizeof(*child), GFP_ATOMIC);
else
-   child = kmalloc(sizeof(*child), GFP_KERNEL);
+   child = kzalloc(sizeof(*child), GFP_KERNEL);

if (unlikely(child == NULL)) {
spin_lock(>unused_lock);
@@ -85,7 +85,7 @@ int drm_mm_pre_get(struct drm_mm *mm)
spin_lock(>unused_lock);
while (mm->num_unused < MM_UNUSED_TARGET) {
spin_unlock(>unused_lock);
-   node = kmalloc(sizeof(*node), GFP_KERNEL);
+   node = kzalloc(sizeof(*node), GFP_KERNEL);
spin_lock(>unused_lock);

if (unlikely(node == NULL)) {
@@ -134,7 +134,6 @@ static struct drm_mm_node *drm_mm_split_at_start(struct 
drm_mm_node *parent,

INIT_LIST_HEAD(>free_stack);

-   child->free = 0;
child->size = size;
child->start = parent->start;
child->mm = parent->mm;
@@ -235,6 +234,9 @@ void drm_mm_put_block(struct drm_mm_node *cur)

int merged = 0;

+   BUG_ON(cur->scanned_block || cur->scanned_prev_free
+ || cur->scanned_next_free);
+
if (cur_head->prev != root_head) {
prev_node =
list_entry(cur_head->prev, struct drm_mm_node, node_list);
@@ -312,6 +314,8 @@ struct drm_mm_node *drm_mm_search_free(const struct drm_mm 
*mm,
struct drm_mm_node *best;
unsigned long best_size;

+   BUG_ON(mm->scanned_blocks);
+
best = NULL;
best_size = ~0UL;

@@ -343,6 +347,8 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
struct drm_mm_node *best;
unsigned long best_size;

+   BUG_ON(mm->scanned_blocks);
+
best = NULL;
best_size = ~0UL;

@@ -366,6 +372,158 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
 }
 EXPORT_SYMBOL(drm_mm_search_free_in_range);

+/**
+ * Initializa lru scanning.
+ *
+ * This simply sets up the scanning routines with the parameters for the 
desired
+ * hole.
+ *
+ * Warning: As long as the scan list is non-empty, no other operations than
+ * adding/removing nodes to/from the scan list are allowed.
+ */
+void drm_mm_init_scan(struct drm_mm *mm, unsigned long size,
+ unsigned alignment)
+{
+   mm->scan_alignment = alignment;
+   mm->scan_size = size;
+   mm->scanned_blocks = 0;
+   mm->scan_hit_start = 0;
+   mm->scan_hit_size = 0;
+}
+EXPORT_SYMBOL(drm_mm_init_scan);
+
+/**
+ * Add a node to the scan list that might be freed to make space for the 
desired
+ * hole.
+ *
+ * Returns non-zero, if a hole has been found, zero otherwise.
+ */
+int drm_mm_scan_add_block(struct drm_mm_node *node)
+{
+   struct drm_mm *mm = node->mm;
+   struct list_head *prev_free, *next_free;
+   struct drm_mm_node *prev_node, *next_node;
+
+   mm->scanned_blocks++;
+
+   prev_free = next_free = NULL;
+
+   BUG_ON(node->free);
+   node->scanned_block = 1;
+   node->free = 1;
+
+   if (node->node_list.prev != >node_list) {
+   prev_node = list_entry(node->node_list.prev, struct drm_mm_node,
+  node_list);
+
+   if (prev_node->free) {
+   list_del(_node->node_list);
+
+   node->start = prev_node->start;
+   node->size += prev_node->size;
+
+   prev_node->scanned_prev_free = 1;
+
+ 

[PATCH 05/11] drm_mm: extract check_free_mm_node

[Chris Wilson]

From: Daniel Vetter 

There are already two copies of this logic. And the new scanning
stuff will add some more. So extract it into a small helper
function.

Signed-off-by: Daniel Vetter 
Acked-by: Thomas Hellstrom 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_mm.c |   71 ++
 1 files changed, 34 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index d2267ff..fd86a6c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -283,6 +283,27 @@ void drm_mm_put_block(struct drm_mm_node *cur)

 EXPORT_SYMBOL(drm_mm_put_block);

+static int check_free_mm_node(struct drm_mm_node *entry, unsigned long size,
+ unsigned alignment)
+{
+   unsigned wasted = 0;
+
+   if (entry->size < size)
+   return 0;
+
+   if (alignment) {
+   register unsigned tmp = entry->start % alignment;
+   if (tmp)
+   wasted = alignment - tmp;
+   }
+
+   if (entry->size >= size + wasted) {
+   return 1;
+   }
+
+   return 0;
+}
+
 struct drm_mm_node *drm_mm_search_free(const struct drm_mm *mm,
   unsigned long size,
   unsigned alignment, int best_match)
@@ -290,30 +311,20 @@ struct drm_mm_node *drm_mm_search_free(const struct 
drm_mm *mm,
struct drm_mm_node *entry;
struct drm_mm_node *best;
unsigned long best_size;
-   unsigned wasted;

best = NULL;
best_size = ~0UL;

list_for_each_entry(entry, >free_stack, free_stack) {
-   wasted = 0;
-
-   if (entry->size < size)
+   if (!check_free_mm_node(entry, size, alignment))
continue;

-   if (alignment) {
-   register unsigned tmp = entry->start % alignment;
-   if (tmp)
-   wasted += alignment - tmp;
-   }
+   if (!best_match)
+   return entry;

-   if (entry->size >= size + wasted) {
-   if (!best_match)
-   return entry;
-   if (entry->size < best_size) {
-   best = entry;
-   best_size = entry->size;
-   }
+   if (entry->size < best_size) {
+   best = entry;
+   best_size = entry->size;
}
}

@@ -331,37 +342,23 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
struct drm_mm_node *entry;
struct drm_mm_node *best;
unsigned long best_size;
-   unsigned wasted;

best = NULL;
best_size = ~0UL;

list_for_each_entry(entry, >free_stack, free_stack) {
-   wasted = 0;
-
-   if (entry->size < size)
+   if (entry->start > end || (entry->start+entry->size) < start)
continue;

-   if (entry->start > end || (entry->start+entry->size) < start)
+   if (!check_free_mm_node(entry, size, alignment))
continue;

-   if (entry->start < start)
-   wasted += start - entry->start;
+   if (!best_match)
+   return entry;

-   if (alignment) {
-   register unsigned tmp = (entry->start + wasted) % 
alignment;
-   if (tmp)
-   wasted += alignment - tmp;
-   }
-
-   if (entry->size >= size + wasted &&
-   (entry->start + wasted + size) <= end) {
-   if (!best_match)
-   return entry;
-   if (entry->size < best_size) {
-   best = entry;
-   best_size = entry->size;
-   }
+   if (entry->size < best_size) {
+   best = entry;
+   best_size = entry->size;
}
}

-- 
1.7.1

[PATCH 04/11] drm: sane naming for drm_mm.c

[Chris Wilson]

From: Daniel Vetter 

Yeah, I've kinda noticed that fl_entry is the free stack. Still
give it (and the memory node list ml_entry) decent names.

Signed-off-by: Daniel Vetter 
Acked-by: Thomas Hellstrom 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_mm.c |   72 ++---
 include/drm/drm_mm.h |   11 --
 2 files changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a5a7a16..d2267ff 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -64,8 +64,8 @@ static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, 
int atomic)
else {
child =
list_entry(mm->unused_nodes.next,
-  struct drm_mm_node, fl_entry);
-   list_del(>fl_entry);
+  struct drm_mm_node, free_stack);
+   list_del(>free_stack);
--mm->num_unused;
}
spin_unlock(>unused_lock);
@@ -94,7 +94,7 @@ int drm_mm_pre_get(struct drm_mm *mm)
return ret;
}
++mm->num_unused;
-   list_add_tail(>fl_entry, >unused_nodes);
+   list_add_tail(>free_stack, >unused_nodes);
}
spin_unlock(>unused_lock);
return 0;
@@ -116,8 +116,8 @@ static int drm_mm_create_tail_node(struct drm_mm *mm,
child->start = start;
child->mm = mm;

-   list_add_tail(>ml_entry, >ml_entry);
-   list_add_tail(>fl_entry, >fl_entry);
+   list_add_tail(>node_list, >node_list);
+   list_add_tail(>free_stack, >free_stack);

return 0;
 }
@@ -132,15 +132,15 @@ static struct drm_mm_node *drm_mm_split_at_start(struct 
drm_mm_node *parent,
if (unlikely(child == NULL))
return NULL;

-   INIT_LIST_HEAD(>fl_entry);
+   INIT_LIST_HEAD(>free_stack);

child->free = 0;
child->size = size;
child->start = parent->start;
child->mm = parent->mm;

-   list_add_tail(>ml_entry, >ml_entry);
-   INIT_LIST_HEAD(>fl_entry);
+   list_add_tail(>node_list, >node_list);
+   INIT_LIST_HEAD(>free_stack);

parent->size -= size;
parent->start += size;
@@ -168,7 +168,7 @@ struct drm_mm_node *drm_mm_get_block_generic(struct 
drm_mm_node *node,
}

if (node->size == size) {
-   list_del_init(>fl_entry);
+   list_del_init(>free_stack);
node->free = 0;
} else {
node = drm_mm_split_at_start(node, size, atomic);
@@ -206,7 +206,7 @@ struct drm_mm_node *drm_mm_get_block_range_generic(struct 
drm_mm_node *node,
}

if (node->size == size) {
-   list_del_init(>fl_entry);
+   list_del_init(>free_stack);
node->free = 0;
} else {
node = drm_mm_split_at_start(node, size, atomic);
@@ -228,8 +228,8 @@ void drm_mm_put_block(struct drm_mm_node *cur)
 {

struct drm_mm *mm = cur->mm;
-   struct list_head *cur_head = >ml_entry;
-   struct list_head *root_head = >ml_entry;
+   struct list_head *cur_head = >node_list;
+   struct list_head *root_head = >node_list;
struct drm_mm_node *prev_node = NULL;
struct drm_mm_node *next_node;

@@ -237,7 +237,7 @@ void drm_mm_put_block(struct drm_mm_node *cur)

if (cur_head->prev != root_head) {
prev_node =
-   list_entry(cur_head->prev, struct drm_mm_node, ml_entry);
+   list_entry(cur_head->prev, struct drm_mm_node, node_list);
if (prev_node->free) {
prev_node->size += cur->size;
merged = 1;
@@ -245,15 +245,15 @@ void drm_mm_put_block(struct drm_mm_node *cur)
}
if (cur_head->next != root_head) {
next_node =
-   list_entry(cur_head->next, struct drm_mm_node, ml_entry);
+   list_entry(cur_head->next, struct drm_mm_node, node_list);
if (next_node->free) {
if (merged) {
prev_node->size += next_node->size;
-   list_del(_node->ml_entry);
-   list_del(_node->fl_entry);
+   list_del(_node->node_list);
+   list_del(_node->free_stack);
spin_lock(>unused_lock);
if (mm->num_unused < MM_UNUSED_TARGET) {
-   list_add(_node->fl_entry,
+   list_add(_node->free_stack,
 >unused_nodes);
++mm->num_unused;
} else

[PATCH 03/11] drm: kill dead code in drm_mm.c

[Chris Wilson]

From: Daniel Vetter 

Signed-off-by: Daniel Vetter 
Acked-by: Thomas Hellstrom 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_mm.c |   45 -
 1 files changed, 0 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b75eb55..a5a7a16 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -48,36 +48,6 @@

 #define MM_UNUSED_TARGET 4

-unsigned long drm_mm_tail_space(struct drm_mm *mm)
-{
-   struct list_head *tail_node;
-   struct drm_mm_node *entry;
-
-   tail_node = mm->ml_entry.prev;
-   entry = list_entry(tail_node, struct drm_mm_node, ml_entry);
-   if (!entry->free)
-   return 0;
-
-   return entry->size;
-}
-
-int drm_mm_remove_space_from_tail(struct drm_mm *mm, unsigned long size)
-{
-   struct list_head *tail_node;
-   struct drm_mm_node *entry;
-
-   tail_node = mm->ml_entry.prev;
-   entry = list_entry(tail_node, struct drm_mm_node, ml_entry);
-   if (!entry->free)
-   return -ENOMEM;
-
-   if (entry->size <= size)
-   return -ENOMEM;
-
-   entry->size -= size;
-   return 0;
-}
-
 static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, int atomic)
 {
struct drm_mm_node *child;
@@ -152,21 +122,6 @@ static int drm_mm_create_tail_node(struct drm_mm *mm,
return 0;
 }

-int drm_mm_add_space_to_tail(struct drm_mm *mm, unsigned long size, int atomic)
-{
-   struct list_head *tail_node;
-   struct drm_mm_node *entry;
-
-   tail_node = mm->ml_entry.prev;
-   entry = list_entry(tail_node, struct drm_mm_node, ml_entry);
-   if (!entry->free) {
-   return drm_mm_create_tail_node(mm, entry->start + entry->size,
-  size, atomic);
-   }
-   entry->size += size;
-   return 0;
-}
-
 static struct drm_mm_node *drm_mm_split_at_start(struct drm_mm_node *parent,
 unsigned long size,
 int atomic)
-- 
1.7.1

[PATCH 02/11] drm: kill drm_mm_node->private

[Chris Wilson]

From: Daniel Vetter 

Only ever assigned, never used.

Signed-off-by: Daniel Vetter 
[glisse: I will re-add if needed for range-restricted allocations]
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c   |4 +---
 drivers/gpu/drm/ttm/ttm_bo.c  |6 --
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 --
 include/drm/drm_mm.h  |1 -
 4 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a6fbe3b..bfc7269 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2643,10 +2643,8 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, 
unsigned alignment)
if (free_space != NULL) {
obj_priv->gtt_space = drm_mm_get_block(free_space, obj->size,
   alignment);
-   if (obj_priv->gtt_space != NULL) {
-   obj_priv->gtt_space->private = obj;
+   if (obj_priv->gtt_space != NULL)
obj_priv->gtt_offset = obj_priv->gtt_space->start;
-   }
}
if (obj_priv->gtt_space == NULL) {
/* If the gtt is empty and we're still having trouble
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 555ebb1..9763288 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -476,7 +476,6 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
*bo, bool remove_all)
++put_count;
}
if (bo->mem.mm_node) {
-   bo->mem.mm_node->private = NULL;
drm_mm_put_block(bo->mem.mm_node);
bo->mem.mm_node = NULL;
}
@@ -670,7 +669,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
printk(KERN_ERR TTM_PFX "Buffer eviction failed\n");
spin_lock(>lru_lock);
if (evict_mem.mm_node) {
-   evict_mem.mm_node->private = NULL;
drm_mm_put_block(evict_mem.mm_node);
evict_mem.mm_node = NULL;
}
@@ -929,8 +927,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem->mm_node = node;
mem->mem_type = mem_type;
mem->placement = cur_flags;
-   if (node)
-   node->private = bo;
return 0;
}

@@ -973,7 +969,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
interruptible, no_wait_reserve, 
no_wait_gpu);
if (ret == 0 && mem->mm_node) {
mem->placement = cur_flags;
-   mem->mm_node->private = bo;
return 0;
}
if (ret == -ERESTARTSYS)
@@ -1029,7 +1024,6 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
 out_unlock:
if (ret && mem.mm_node) {
spin_lock(>lru_lock);
-   mem.mm_node->private = NULL;
drm_mm_put_block(mem.mm_node);
spin_unlock(>lru_lock);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 13012a1..7cffb3e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -353,8 +353,6 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
fbo->vm_node = NULL;

fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
-   if (fbo->mem.mm_node)
-   fbo->mem.mm_node->private = (void *)fbo;
kref_init(>list_kref);
kref_init(>kref);
fbo->destroy = _transfered_destroy;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 4c10be3..da94071 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -48,7 +48,6 @@ struct drm_mm_node {
unsigned long start;
unsigned long size;
struct drm_mm *mm;
-   void *private;
 };

 struct drm_mm {
-- 
1.7.1

[PATCH 01/11] drm: use list_for_each_entry in drm_mm.c

[Chris Wilson]

From: Daniel Vetter 

Signed-off-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Acked-by: Thomas Hellstrom 
---
 drivers/gpu/drm/drm_mm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 2ac074c..b75eb55 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -332,7 +332,6 @@ struct drm_mm_node *drm_mm_search_free(const struct drm_mm 
*mm,
   unsigned long size,
   unsigned alignment, int best_match)
 {
-   struct list_head *list;
const struct list_head *free_stack = >fl_entry;
struct drm_mm_node *entry;
struct drm_mm_node *best;
@@ -342,8 +341,7 @@ struct drm_mm_node *drm_mm_search_free(const struct drm_mm 
*mm,
best = NULL;
best_size = ~0UL;

-   list_for_each(list, free_stack) {
-   entry = list_entry(list, struct drm_mm_node, fl_entry);
+   list_for_each_entry(entry, free_stack, fl_entry) {
wasted = 0;

if (entry->size < size)
@@ -376,7 +374,6 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
unsigned long end,
int best_match)
 {
-   struct list_head *list;
const struct list_head *free_stack = >fl_entry;
struct drm_mm_node *entry;
struct drm_mm_node *best;
@@ -386,8 +383,7 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
best = NULL;
best_size = ~0UL;

-   list_for_each(list, free_stack) {
-   entry = list_entry(list, struct drm_mm_node, fl_entry);
+   list_for_each_entry(entry, free_stack, fl_entry) {
wasted = 0;

if (entry->size < size)
-- 
1.7.1

Fair eviction for i915, based on Daniel's drm_mm scanner

[Chris Wilson]

This is a resend of Daniel Vetter's drm mm work to provide a basis for
performing fair eviction in i915. I've taken the liberty of attaching the
acks and review comments from the previous round, so please look over and
check that they still hold true.

 drivers/gpu/drm/drm_mm.c|  359 ---
 drivers/gpu/drm/i915/Makefile   |1 +
 drivers/gpu/drm/i915/i915_drv.h |   11 +-
 drivers/gpu/drm/i915/i915_gem.c |  246 ++---
 drivers/gpu/drm/i915/i915_gem_evict.c   |  242 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   46 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
 drivers/gpu/drm/ttm/ttm_bo.c|6 -
 drivers/gpu/drm/ttm/ttm_bo_util.c   |2 -
 include/drm/drm_mm.h|   27 ++-
 10 files changed, 550 insertions(+), 391 deletions(-)
-ickle

[Bug 28860] [r300g] Yo Frankie crash: assertion failure / Too many hardware temporaries used

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #3 from Pavel Ondra?ka  2010-07-02 13:40:49 
PDT ---
(In reply to comment #0)
> yofrankie-linux-i386.bin: state_tracker/st_mesa_to_tgsi.c:181: dst_register:
> Assertion `t->outputMapping[index] <
> (sizeof(t->outputs)/sizeof(*(t->outputs)))' failed.

This looks similar to bug 28169, should be fixed with commit
6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a

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

Closed source userspace graphics drivers with an open source kernel component

[Luc Verhaegen]

On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote:
> Luc, can you please take your corporate bullshit out of this?  I can
> assume you know Dave personally and should be clearly aware that he's
> everything but a corporate drone.

Yes, with mails like this he clearly shows that he isn't a corporate drone.

Luc Verhaegen.

Closed source userspace graphics drivers with an open source kernel component

[Luc Verhaegen]

On Fri, Jul 02, 2010 at 08:23:27PM +1000, Dave Airlie wrote:
> >
> 
> They own quite a lot of the IP in the 3D core, having bought it from
> AMD, you can see the CP packets and PM4 stuff just like in radeon.

Aha, imageon indeed, cool!

I doubt that you know the conditions of this sale. This might just be about 
waiting for 
Qualcomm to sort things out, or it might be about a licensing issue still. We 
just 
cannot know this.

> I know who Jordan is well from AMD, and I've stated this isn't a
> Qualcomm only thing, but companies need to understand that putting
> stuff into the kernel is part of a bargain, where you get the benefits
> of all the work everyone has done on the kernel and they get the
> benefits of being able to do stuff with the code you provide, only
> giving us a half arsed interface to the hw and hiding all the good
> stuff in userspace isn't accepting this bargain. You can say what you
> like about liceneses and legalese but Linus picked the GPL for this
> sort of everyone gives what they get.

Sure, but you still slammed, and this affected in first order mostly Qualcomm, 
instead 
of stating that you simply do not want to be involved.

> They'll keep shipping closed stuff, just like they are now. Are you
> going to reverse engineer the userspace drivers, so people who care
> about open and free software platforms can use these drivers? (or have
> you already signed NDAs saying you can't). Why should we maintain a
> bunch of kernel code, when they are hiding away all the really useful
> stuff that people could improve.

Maintaining this exact code is not _your_ job, and you should've stated just 
that.

> I would, some points
> (a) Red Hat is the company I work for.
> (b) Red Hat doesn't really care about this stuff at all.
> (c) I'm the kernel maintainer for far longer that I worked for Red
> Hat, I also work a lot with Intel at Red Hat and I've told them the
> same thing, and VIA and now I'm stating it so I don't have to restate
> individually to every company again.

You will need to restate this every time anyway, unless you somehow manage to 
get your 
rather daunting and loud statement to be the first thing such corporations 
management 
people at linux.com, which is what people type in their browser first.

But maybe you might want to adjust your message.

> You don't understand what being a kernel maintainer is do you? at all?

Heh, i could make a really nasty statement here, but i wont.

> Wierd I'm still seeing new docs being produced and old docs being
> updated, not as fast as I'd like but I understand how many people
> there is working on it and I'd rather we also got fixes for all the
> current stuff done as well.

Hrm, i only see _very_ old docs getting updated, and none produced.

I still have docs which are pretty ready to be shipped (from 2007), under 
uncertain 
legal status (the ati game was fun!), which were never made public. I am sure 
that 
bridgman, gave you these docs too, but under even more shady circumstances.

> The code doesn't exist, there is no userspace code to be the
> documents, if you read what I said, documents would be a good start in
> lieu of code, but code is perfectly fine.

> Imagintaion technologies seriously? they've never ever taken one step
> towards opening anything, I don't think this statement is suddenly
> going to jumpstart them.

> Maybe you should disclose what NDAs you currently are under and who
> pays your bills, since you accuse me of Red Hat mind-control.

Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm 
sure
you knew.

> I'm not sure how the ARM market would benefit from having no userspace
> 3D drivers just like the x86 market, if you actually were normal you'd
> realise the ARM people are trying to screw the market just like the
> desktop people, to save themselves some money, but maybe working on
> closed drivers has twisted you.

Ah, so you did know.

As a free software graphics driver developer there is little option left but to 
go 
straight to the ARM world, at least things have potential to move there still.

Well, unless the efforts there, like the one that triggered your mail, are 
thwarted 
too, like with your mail.

Luc Verhaegen.

X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining

[Justin P. Mattock]

this is new(below) has anybody reported/bisected hit this yet
(if not I'll bisect it)

[drm] Num pipes: 1
[   29.742432] [drm] writeback test succeeded in 1 usecs
[   30.089717] X:2252 conflicting memory types 4000-4800 
uncached-minus<->write-combining
[   30.089721] reserve_memtype failed 0x4000-0x4800, track 
uncached-minus, req uncached-minus
[   30.123517] [drm] Num pipes: 1
[   30.351017] X:2252 freeing invalid memtype 4000-4800
[   30.354255] CPU 0
[   30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc 
bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state 
nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 
iptable_filter ip_tables x_tables firewire_ohci firewire_core video 
battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal 
evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib 
ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 
blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc 
raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap 
bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc 
uvcvideo[   30.354255]
[   30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f 
#3 Mac-F42187C8/MacBookPro2,2
[   30.354255] RIP: 0010:[]  [] 
radeon_read_ring_rptr+0x2b/0x2f [radeon]
[   30.354255] RSP: 0018:8800360dfc80  EFLAGS: 00010202
[   30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: 
c9cf8000
[   30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 
8800385e8848
[   30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 
0010
[   30.354255] R10:  R11: ea930af0 R12: 
0010
[   30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 
8800385e8178
[   30.354255] FS:  7f0aaa823840() GS:880001a0() 
knlGS:
[   30.354255] CS:  0010 DS:  ES:  CR0: 80050033
[   30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 
06f0
[   30.354255] DR0:  DR1:  DR2: 

[   30.354255] DR3:  DR6: 0ff0 DR7: 
0400
[   30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 
880033dc5c40)
[   30.354255]  8800360dfc90 a0358130 8800360dfca8 
a035881c
[   30.354255] <0> 8800385e8848 8800360dfcc8 a0359ac7 

[   30.354255] <0> 8800385e8848 8800360dfce8 a035c961 
8800385e8848
[   30.354255]  [] radeon_get_ring_head+0x11/0x3c [radeon]
[   30.354255]  [] radeon_commit_ring+0x48/0x97 [radeon]
[   30.354255]  [] radeon_do_cp_idle+0x140/0x14d [radeon]
[   30.354255]  [] 
radeon_apply_surface_regs+0x22/0x138 [radeon]
[   30.354255]  [] free_surface+0xd8/0xee [radeon]
[   30.354255]  [] radeon_driver_lastclose+0x3c/0x56 
[radeon]
[   30.354255]  [] drm_lastclose+0x44/0x2ad [drm]
[   30.354255]  [] drm_release+0x656/0x6a3 [drm]
[   30.354255]  [] put_files_struct+0x65/0xb3
[   30.354255]  [] exit_files+0x46/0x4e
[   30.354255]  [] do_exit+0x214/0x69f
[   30.354255]  [] ? fput+0x1e2/0x1f1
[   30.354255]  [] do_group_exit+0x72/0x9a
[   30.354255]  [] sys_exit_group+0x12/0x16
[   30.354255]  [] system_call_fastpath+0x16/0x1b
[   30.354255]  RSP 
[   31.312879] ---[ end trace 9a7b92300d4121f6 ]---
[   30.354255]  [] fput+0x122/0x1f1
[   30.354255]  [] filp_close+0x63/0x6d

Justin P. Mattock

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

On Thu, 2010-07-01 at 20:42 -0400, Timothy Meade wrote:
> -- Forwarded message --

> Hello.  I've been working with the developers on the htc-linux project
> and following the progress of Android on MSM devices closely for a few
> years.  I've been excitied to see DRM/DRI replace PMEM and the Android
> specific interfaces be replaced with more Linux-like ones.  The Xorg
> driver from Qualcomm uses this same interface for 2D and it's possible
> that Android will take the same approach, though it uses 3D and GLES
> as a type of abstraction layer for surfaceflinger.  This allows for a
> closed 3D driver with an open command submission layer that is in
> itself not that different from the split for ATI devices using
> radeonhd.  I say this because the alternative for these devices is a
> fully closed binary and secrecy surrounding the graphics layers that
> ensures that only the OS that ships with the device can ever really be
> used and preventing those non-coorporate developers as myself from
> utilising GPL code the way we want or even usuing are own cell phones
> (in this case).  I would choose a fully open, X based OS even if that
> meant only having 2D drivers, but I know that Quic and others aren't
> going to develop just a (accelerated) 2D driver, not the kernel
> components or userspace but instead rely on the same GLES layer that
> Android uses, essentially making X and open environments a second
> class citizen on modern mobile hardware.

The thing is you are prevented from using the GPU the way you want,
telling you how to send commands and get irqs from a device but not
telling you what those commands means is limiting you. So you can use it
a framebuffer device, you can do that with a 500 line fbdev driver most
likely, we don't need the maintainer burden of the other 5000 lines of
code that are only in the driver to service some 3D userspace binary
blob.

The radeon example is pointless since all pieces in that system are open
even if AMD can't/won't disclose how certain parts of the GPU work, we
have access to nearly all the functionality, we control all the open
pieces and if someone reverse engineers it, AMD have to accept it.

There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more unfair.

Dave.

[Bug 28876] [radeon HD4250] Frequent lockups while screen locked

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28876

--- Comment #3 from Yann Dirson  2010-07-02 12:20:13 PDT 
---
Forgot to note the kernel version, vanilla 2.6.32.13 (with evms-bd-claim patch,
but that should not matter).

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

Closed source userspace graphics drivers with an open source kernel component

[Luc Verhaegen]

On Fri, Jul 02, 2010 at 08:10:40AM +1000, Dave Airlie wrote:
> Now this is just my opinion as maintainer of the drm, and doesn't
> reflect anyone or any official policy, I've also no idea if Linus
> agrees or not.
> 
> We are going to start to see a number of companies in the embedded
> space submitting 3D drivers for mobile devices to the kernel. I'd like
> to clarify my position once so they don't all come asking the same
> questions.
> 
> If you aren't going to create an open userspace driver (either MIT or
> LGPL) then don't waste time submitting a kernel driver to me.
> 
> My reasons are as follows, the thing is you can probably excuse some
> of these on a point by point basis, but you need to justify why closed
> userspace on all points.
> 
> a) licensing, Alan Cox pointed this out before, if you wrote a GPL
> kernel driver, then wrote a closed userspace on top, you open up a
> while world of derived work issues. Can the userspace operate on a
> non-GPL kernel without major modifications etc. This is a can of worms
> I'd rather not enter into, and there are a few workarounds.

Yes, this a mess indeed.

But i fear that this a mess that cannot be fixed, in its entirety, in a single 
shot.  

Qualcomm making this code available already clearly shows the will and 
determination of 
some people inside qualcomm to do The Right Thing. 

This is Qualcomms first big step on the graphics side, where IP is always 
amongst the 
heaviest. I am certain that Qualcomm wants to go further, but since Qualcomm 
most 
likely licenses some parts of their graphics, Qualcomm can only open up those 
bits that 
they truly own, and then use mainly market/sales-volume driven pressure to get 
the 
original IP owner to play along.

You should also take into account who Jordan is. He is one of the guys who 
worked the 
Geode before AMD decided to drop that, which is when he got hired by Qualcomm. 
He worked on 
both the graphics drivers and on (then still) LinuxBIOS. I know that redhat has 
no 
intention of going near coreboot, but in my world one cannot become more free, 
hardware 
wise, than supporting coreboot. This gives me very good hopes that this is a 
serious 
attempt by qualcomm to go somewhere, and that this is not some lame attempt to 
grab 
marketing attention.

Now that you slammed the door on these guys (and on others in the process), 
what do you 
think the response would be? Where will this get us to in the end?

The licensing should get sorted, and that is of course something for Qualcomm 
to do, 
or prove that it has been sorted already.

> b) verifying the sanity of the userspace API.
> 1. Security: GPUs can do a lot of damage if left at home alone, since
> mostly you are submitting command streams unverified into the GPU and
> won't tell us what they mean, there is little way we can work out if
> the GPU is going to over-write my passwd file to get 5 fps more in
> quake. Now newer GPUs have at least started having MMUs, but again
> we've no idea if that is the only way they work without docs or a lot
> of trust.

This makes me wonder: Why do you even care?

If redhat was working with qualcomm, you would not have taken this stance here 
at all.

Since redhat is then not working with qualcomm, why is this then your 
responsibility?

Or is denouncing responsibility exactly the reason for your mail here?

If so, why couldn't you have stated "please guys, have fun with what you are 
doing, but 
i will not be responsible for it" in a different way.

What you achieved now is that people will stop bothering with even freeing 
this, 
putting us even further back.

But i fully understand where you are coming from: redhat only wants to 
seriously back 
the server market, so free software graphics on arm based SOCs probably should 
not be 
encouraged too much. As per usual, big statements are then more important than 
actual 
free software advancement.

> 2. General API suitability and versioning. How do we check that API is
> sane wrt to userspace, if we can't verify the userspace. What happens
> if the API has lots of 32/64 compat issues or things like that, and
> when we fix them the binary userspace breaks? How do we know, how do
> we test etc. What happens if a security issue forces us to break the
> userspace API? how do we fix the userspace driver and test to confirm?
> 
> c) supplying docs in lieu of an open userspace
> If you were to fully document the GPU so we could verify the
> security/api aspects it leaves us in the position of writing our own
> driver. Now writing that driver on top of the current kernel driver
> would probably limit any innovation, and most people would want to
> write a new kernel driver from scratch. Now we end up with two drivers
> fighting, how do we pick which one to load at boot? can we ever do a
> generic distro kernel for that device (assuming ARM ever solves that
> issue).

I think that by now you should have realized that this is not how it works for 
things as complex as 

[PATCH] drm: correctly update connector DPMS status in drm_fb_helper

[Jesse Barnes]

We don't currently update the DPMS status of the connector (both in the
connector itself and the connector's DPMS property) in the fb helper
code.  This means that if the kernel FB core has blanked the screen,
sysfs will still show a DPMS status of "on".  It also means that when X
starts, it will try to light up the connectors, but the drm_crtc_helper
code will ignore the DPMS change since according to the connector, the
DPMS status is already on.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
"my screen was blanked when I started X and now it won't light up" bug).

Signed-off-by: Jesse Barnes 

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(struct fb_info *info)
struct drm_device *dev = fb_helper->dev;
struct drm_crtc *crtc;
struct drm_crtc_helper_funcs *crtc_funcs;
+   struct drm_connector *connector;
struct drm_encoder *encoder;
-   int i;
+   int i, j;

/*
 * For each CRTC in this fb, turn the crtc on then,
@@ -332,7 +333,14 @@ static void drm_fb_helper_on(struct fb_info *info)

crtc_funcs->dpms(crtc, DRM_MODE_DPMS_ON);

-
+   /* Walk the connectors & encoders on this fb turning them on */
+   for (j = 0; j < fb_helper->connector_count; j++) {
+   connector = fb_helper->connector_info[j]->connector;
+   connector->dpms = DRM_MODE_DPMS_ON;
+   drm_connector_property_set_value(connector,
+
dev->mode_config.dpms_property,
+DRM_MODE_DPMS_ON);
+   }
/* Found a CRTC on this fb, now find encoders */
list_for_each_entry(encoder, >mode_config.encoder_list, 
head) {
if (encoder->crtc == crtc) {
@@ -352,8 +360,9 @@ static void drm_fb_helper_off(struct fb_info *info, int 
dpms_mode)
struct drm_device *dev = fb_helper->dev;
struct drm_crtc *crtc;
struct drm_crtc_helper_funcs *crtc_funcs;
+   struct drm_connector *connector;
struct drm_encoder *encoder;
-   int i;
+   int i, j;

/*
 * For each CRTC in this fb, find all associated encoders
@@ -367,6 +376,14 @@ static void drm_fb_helper_off(struct fb_info *info, int 
dpms_mode)
if (!crtc->enabled)
continue;

+   /* Walk the connectors on this fb and mark them off */
+   for (j = 0; j < fb_helper->connector_count; j++) {
+   connector = fb_helper->connector_info[j]->connector;
+   connector->dpms = dpms_mode;
+   drm_connector_property_set_value(connector,
+
dev->mode_config.dpms_property,
+dpms_mode);
+   }
/* Found a CRTC on this fb, now find encoders */
list_for_each_entry(encoder, >mode_config.encoder_list, 
head) {
if (encoder->crtc == crtc) {

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

On Fri, Jul 2, 2010 at 10:08 AM, Daniel Walker  
wrote:
> On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:
>
>> > Oh, man .. It seems like any driver model that straddles userspace and
>> > kernel space is kind of asking for trouble (my opinion anyway)..
>> >
>> > Would you accept a userspace component that supported some subset of the
>> > features ? You would have a kernel space driver, and userspace both open
>> > source and GPL'd , but the userspace component wouldn't support ever
>> > feature available .. Then the company would be free to make another
>> > proprietary userspace with more features based off the open source one.
>> >
>>
>> That starts to get a bit more towards useful, except you still run
>> into the problem of what happens if community developers start adding
>> features to the open driver, that conflict with ?features in the
>> closed code. We'd also have to be very careful about what interfaces
>> the kernel exposed had corresponding code in userspace. i.e. adding
>> "special" ioctls for the closed bits would be a disaster, all such
>> ioctls would need open users for verification and testing.
>
> Ok .. The open userspace would just be like any other project, but
> whatever company pushed the driver would likely maintain the userspace
> component .. So the maintainer would have to handle the conflicts
> between the proprietary vs. open source sides of it.
>
> Actually , now that I think about it the biggest problem is the license
> of the userspace side.. Whatever company makes this would have to be
> able to relicense it and actually make a proprietary userspace.. So the
> userspace license would be really critical.. Either that or no one
> outside the company that pushed the driver could make code changes to
> the userspace side..

We generally use MIT for userspace bits anyways, I don't think we have
any LGPL/GPL drivers in userspace currently. So this would probably be
an okay solution to continue with.

The thing is with architectures like Gallium it would be possible to
write a complete open driver and just keep the Windows interface bits,
granted we don't have an open gallium to windows driver layer so that
would have to be worked on.

>
>> So for example, if you have a kernel KMS/DRM driver, and it set the
>> hardware up, but then you had an open 2D driver and a closed 3D
>> driver, you would have to make sure there was no functionality in the
>> kernel that only the 3D driver used as it would become impossible to
>> openly validate it.
>
> Ok. I'm not sure how crazy that would be to setup, but it doesn't seem
> like it would be that hard to just abstract the various components of
> the driver.

Its pretty much what something like gallium can do.

>
>> The other issue I see with a lot of these, is the driver are presented
>> as this is the kernel driver, these APIs are set in stone as we have
>> binary userspaces already deployed, this is even more unacceptable,
>> since we need to be able to change the interface and do proper driver
>> design before merging what looks like crap thrown together in a pile
>> and made to stick.
>
> This seems really wild to me .. Your talking about how you change the
> kernel space side and you need to be able to change the userspace side
> to match right ?
>
> Where does the userspace side of these driver live? Not in the kernel
> right?

This is more about initial development stages. We maintain kernel
API/ABI for all in-tree drivers, however before we put a driver into
mainline, we usually need to redo the crazy interfaces that vendors
have come up with. Like 32/64 alignment, passing userspace addresses
into the kernel, passing phy addresses to userspace etc. If the
userspace binary is closed that process becomes next to impossible.

Dave.

[Bug 28437] [r300g] wrong texture colors with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28437

--- Comment #5 from Alan Swanson  2010-07-02 10:09:58 PDT 
---
Seems to affect UT2004 too on an AGP X1650 Pro running current mesa git when
S3TC textures are enabled with libtxc_dxtn.so, the blue and red colours are
swapped.

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

[Bug 28437] [r300g] wrong texture colors with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28437

--- Comment #4 from Fabio Pedretti  2010-07-02 09:41:49 
PDT ---
> terrain is still blueish rather than green as with swrastg or r300g without
> libtxc_dxtn.so.

Now that bug #28169 is fixed, also the game, other than the editor, has all
textures blueish.

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

Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

On Fri, Jul 2, 2010 at 9:29 AM, Daniel Walker  wrote:
> On Fri, 2010-07-02 at 08:57 +1000, Dave Airlie wrote:
>> On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker  
>> wrote:
>> > On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
>> >> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie  wrote:
>> >> > Now this is just my opinion as maintainer of the drm, and doesn't
>> >> > reflect anyone or any official policy, I've also no idea if Linus
>> >> > agrees or not.
>> >> >
>> >> > We are going to start to see a number of companies in the embedded
>> >> > space submitting 3D drivers for mobile devices to the kernel. I'd like
>> >> > to clarify my position once so they don't all come asking the same
>> >> > questions.
>> >> >
>> >> > If you aren't going to create an open userspace driver (either MIT or
>> >> > LGPL) then don't waste time submitting a kernel driver to me.
>> >
>> > If , for whatever reason, you changed you mind on this what sort of
>> > connection between kernel and userspace would these components use?
>> >
>> > I ask only because I think UIO hold most (if not all) the driver in
>> > userspace .. So you would have to use some other interface if you wanted
>> > a more half and half solution ..
>> >
>>
>> The thing is UIO doesn't solve the problem 3D graphics drivers need to
>> solve. Which is we need to let unprivileged users access the graphics
>> device in an efficient manner, hence why DRI/DRM exists. Now I think
>> the tegra guys have done some evil hacks with a userspace daemon to
>> replace the kernel functionality, so all they have in-kernel is a
>> framebuffer device, since they can't really get away with shipping the
>> binary nvidia driver linked to the kernel in a real device. So all
>> their userspace closed bits talk to the daemon running as root with
>> direct access to the lowlevel hw.
>
> Oh, man .. It seems like any driver model that straddles userspace and
> kernel space is kind of asking for trouble (my opinion anyway)..
>
> Would you accept a userspace component that supported some subset of the
> features ? You would have a kernel space driver, and userspace both open
> source and GPL'd , but the userspace component wouldn't support ever
> feature available .. Then the company would be free to make another
> proprietary userspace with more features based off the open source one.
>

That starts to get a bit more towards useful, except you still run
into the problem of what happens if community developers start adding
features to the open driver, that conflict with  features in the
closed code. We'd also have to be very careful about what interfaces
the kernel exposed had corresponding code in userspace. i.e. adding
"special" ioctls for the closed bits would be a disaster, all such
ioctls would need open users for verification and testing.

So for example, if you have a kernel KMS/DRM driver, and it set the
hardware up, but then you had an open 2D driver and a closed 3D
driver, you would have to make sure there was no functionality in the
kernel that only the 3D driver used as it would become impossible to
openly validate it.

The other issue I see with a lot of these, is the driver are presented
as this is the kernel driver, these APIs are set in stone as we have
binary userspaces already deployed, this is even more unacceptable,
since we need to be able to change the interface and do proper driver
design before merging what looks like crap thrown together in a pile
and made to stick.

Dave.

Closed source userspace graphics drivers with an open source kernel component

[Piotr Gluszenia Slawinski]

> Piotr Gluszenia Slawinski wrote:
>> >  There is no point supporting companies that give you a little bit of
>> >  information in exchange they want the support that being in a mainline
>> >  kernel gives. Its an unfair exchange of knowledge and time, and if they
>> >  claim they have to make a profit then its even more unfair.
>>
>>  also, they seem to do it quite wrong way. i.e. much simpler would be to
>>  just implement regular, open driver , and implement additional crypto
>>  mechanism in chipset itself, allowing to use simple userspace program
>>  sending certified keys allowing GPU to operate.
>>  if key is not available and device/driver not paid/registered, then
>>  GPU would simply lock itself , similiar to pre-paid designs from
>>  company whose name should not be spoken aloud.
>>
>>  also certain functionality could be ordered with same chip structure,
>>  i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
>>  with user buying proper 'entry level' pre-paid code set from manufacturer.
>>
>>  this would provide quite same functionality (profit), without impacting
>>  open-source projects like Xorg with unnessesary complications.
>
> Pardon me for intruding in this discussion, but I'm astonished that you 
> actually find what you posted to be acceptable. If I pay for a piece of 
> hardware, I have the right to use it. Requiring certified keys before it 
> performs the function for which it was purchased is pure nonsense.

in this context it is more lease than purhase, similiar to situation
when you buy cellphone, but you are limited by the sim card to access
networks, and sometimes even own adress book (when your account is 
drained, your adress book stored on sim data card is locked).

i do not claim such practices are convient for users, yet they are
very convient for hardware vendors, and it seems more 'open cards' play
which seems more clear to user than situation in which you need binary 
blobs which can contain everything from rootkit to actual crypto routine
(i.e. to prevent driver running on 'non original' clone video cards made
by competitor company) running with ROOT privileges on the computers of 
users being told it is Only Way (tm) to make given company profit and 
survive, while providing some functionality as a trade.

so to resume such solution - one gets fair information about to which 
extent company allows usage of hardware sold to user (without messy 'end 
user license' implied on binary drivers) , and can perform clear
decision - either buying 'secure' and 'genuinely original' video card
with options one needs and is able to pay for (which includes
software development price) , or goes for more 'open' solutions.

mind you most of hardware vendors do NOT want you to purhase
hardware, at best they want LICENSE you to use it for specific
purpose, and specific period. the wish of yours to freely use
hardware does not represent accurate wish of casual users ,
which do not care about freedom as long as hardware allows them
to perform specific task.

either way imho mixing those two attitudes is erroneus,
as it creates confusion and beliefs that some hardware is intended
for free use, and in same time that some software should provide
infrastructure to limit safety and freedom of users.
also it leads to development of BOTH. the sooner those two will
be separated, the sooner alternatives will be created,
and most importantly RECOGNIZED by market.

-- 

Closed source userspace graphics drivers with an open source kernel component

[Christoph Hellwig]

Luc, can you please take your corporate bullshit out of this?  I can
assume you know Dave personally and should be clearly aware that he's
everything but a corporate drone.

Closed source userspace graphics drivers with an open source kernel component

[Piotr Gluszenia Slawinski]

> There is no point supporting companies that give you a little bit of
> information in exchange they want the support that being in a mainline
> kernel gives. Its an unfair exchange of knowledge and time, and if they
> claim they have to make a profit then its even more unfair.

also, they seem to do it quite wrong way. i.e. much simpler would be to 
just implement regular, open driver , and implement additional crypto
mechanism in chipset itself, allowing to use simple userspace program
sending certified keys allowing GPU to operate.
if key is not available and device/driver not paid/registered, then
GPU would simply lock itself , similiar to pre-paid designs from
company whose name should not be spoken aloud.

also certain functionality could be ordered with same chip structure,
i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
with user buying proper 'entry level' pre-paid code set from manufacturer.

this would provide quite same functionality (profit), without impacting
open-source projects like Xorg with unnessesary complications.


-- 

Closed source userspace graphics drivers with an open source kernel component

[Christoph Hellwig]

100% agreed on the rationale, and I hope you can keep this crap out!

Closed source userspace graphics drivers with an open source kernel component

[Piotr Gluszenia Slawinski]

> We are going to start to see a number of companies in the embedded
> space submitting 3D drivers for mobile devices to the kernel. I'd like
> to clarify my position once so they don't all come asking the same
> questions.

one of options for future would be equipping gpu's with additional
processing force, allowing it to run whole Xorg on it's own,
and just communicate with rest of machine via shared memory window (so 
visible as 'hardware X server' from systems standpoint),

option which allows both - closing 'source' of gpu , and taking
off burden of development for closed, once-use-throwaway
devices from Xorg and kenel crew.

also port of Xorg on GPUs itself allows skipping a lot of features
of kernel, and OS itself (it doesn't to be based on linux afterall)
allowing much more robust performance, and skipping common bottlenecks
(sharing irq's , scheduling, etc)

but this route needs to be considered by hardware vendors themselves.

--

Re: Closed source userspace graphics drivers with an open source kernel component

[Howard Chu]

Piotr Gluszenia Slawinski wrote:

There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more unfair.


also, they seem to do it quite wrong way. i.e. much simpler would be to
just implement regular, open driver , and implement additional crypto
mechanism in chipset itself, allowing to use simple userspace program
sending certified keys allowing GPU to operate.
if key is not available and device/driver not paid/registered, then
GPU would simply lock itself , similiar to pre-paid designs from
company whose name should not be spoken aloud.

also certain functionality could be ordered with same chip structure,
i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
with user buying proper 'entry level' pre-paid code set from manufacturer.

this would provide quite same functionality (profit), without impacting
open-source projects like Xorg with unnessesary complications.


Pardon me for intruding in this discussion, but I'm astonished that you 
actually find what you posted to be acceptable. If I pay for a piece of 
hardware, I have the right to use it. Requiring certified keys before it 
performs the function for which it was purchased is pure nonsense.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Closed source userspace graphics drivers with an open source kernel component

[Christoph Hellwig]

100% agreed on the rationale, and I hope you can keep this crap out!

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

Re: Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

 Yes, this a mess indeed.

 But i fear that this a mess that cannot be fixed, in its entirety, in a 
 single shot.

 Qualcomm making this code available already clearly shows the will and 
 determination of
 some people inside qualcomm to do The Right Thing.

 This is Qualcomms first big step on the graphics side, where IP is always 
 amongst the
 heaviest. I am certain that Qualcomm wants to go further, but since Qualcomm 
 most
 likely licenses some parts of their graphics, Qualcomm can only open up those 
 bits that
 they truly own, and then use mainly market/sales-volume driven pressure to 
 get the
 original IP owner to play along.

They own quite a lot of the IP in the 3D core, having bought it from
AMD, you can see the CP packets and PM4 stuff just like in radeon.


 You should also take into account who Jordan is. He is one of the guys who 
 worked the
 Geode before AMD decided to drop that, which is when he got hired by 
 Qualcomm. He worked on
 both the graphics drivers and on (then still) LinuxBIOS. I know that redhat 
 has no
 intention of going near coreboot, but in my world one cannot become more 
 free, hardware
 wise, than supporting coreboot. This gives me very good hopes that this is a 
 serious
 attempt by qualcomm to go somewhere, and that this is not some lame attempt 
 to grab
 marketing attention.

I know who Jordan is well from AMD, and I've stated this isn't a
Qualcomm only thing, but companies need to understand that putting
stuff into the kernel is part of a bargain, where you get the benefits
of all the work everyone has done on the kernel and they get the
benefits of being able to do stuff with the code you provide, only
giving us a half arsed interface to the hw and hiding all the good
stuff in userspace isn't accepting this bargain. You can say what you
like about liceneses and legalese but Linus picked the GPL for this
sort of everyone gives what they get.

 Now that you slammed the door on these guys (and on others in the process), 
 what do you
 think the response would be? Where will this get us to in the end?

They'll keep shipping closed stuff, just like they are now. Are you
going to reverse engineer the userspace drivers, so people who care
about open and free software platforms can use these drivers? (or have
you already signed NDAs saying you can't). Why should we maintain a
bunch of kernel code, when they are hiding away all the really useful
stuff that people could improve.

 b) verifying the sanity of the userspace API.
 1. Security: GPUs can do a lot of damage if left at home alone, since
 mostly you are submitting command streams unverified into the GPU and
 won't tell us what they mean, there is little way we can work out if
 the GPU is going to over-write my passwd file to get 5 fps more in
 quake. Now newer GPUs have at least started having MMUs, but again
 we've no idea if that is the only way they work without docs or a lot
 of trust.

 This makes me wonder: Why do you even care?

 If redhat was working with qualcomm, you would not have taken this stance 
 here at all.

I would, some points
(a) Red Hat is the company I work for.
(b) Red Hat doesn't really care about this stuff at all.
(c) I'm the kernel maintainer for far longer that I worked for Red
Hat, I also work a lot with Intel at Red Hat and I've told them the
same thing, and VIA and now I'm stating it so I don't have to restate
individually to every company again.

 If so, why couldn't you have stated please guys, have fun with what you are 
 doing, but
 i will not be responsible for it in a different way.

You don't understand what being a kernel maintainer is do you? at all?

 Now, it is interesting how you now are demanding documentation. When did 
 recent and
 relevant hw documentation happen for ATI? This pretty much died together when 
 the
 ATI-SuSE relationship died, as the cooperation of SuSE and AMD is how 
 documentation
 was forced out of ATI in the first place, and ATI more and more found ways to 
 get rid
 of this responsibility, or overhead as bridgman would most likely name it.

Wierd I'm still seeing new docs being produced and old docs being
updated, not as fast as I'd like but I understand how many people
there is working on it and I'd rather we also got fixes for all the
current stuff done as well.


 If you are backing this reasoning for ATI, what is wrong with this code being 
 the
 documentation for Qualcomm?

The code doesn't exist, there is no userspace code to be the
documents, if you read what I said, documents would be a good start in
lieu of code, but code is perfectly fine.

 Heh, in some of these cases, not having looked at this code in detail yet, 
 such code
 predates kms, and drm might not have provided what was needed. Not wanting to
 completely diminish the responsibility of qualcomm (or the other companies 
 who are
 working or are forced to work like this), you might want to think about 
 providing
 stable and fitting infrastructure, not just stating that 

Re: Closed source userspace graphics drivers with an open source kernel component

[Luc Verhaegen]

On Fri, Jul 02, 2010 at 08:23:27PM +1000, Dave Airlie wrote:
 
 
 They own quite a lot of the IP in the 3D core, having bought it from
 AMD, you can see the CP packets and PM4 stuff just like in radeon.

Aha, imageon indeed, cool!

I doubt that you know the conditions of this sale. This might just be about 
waiting for 
Qualcomm to sort things out, or it might be about a licensing issue still. We 
just 
cannot know this.

 I know who Jordan is well from AMD, and I've stated this isn't a
 Qualcomm only thing, but companies need to understand that putting
 stuff into the kernel is part of a bargain, where you get the benefits
 of all the work everyone has done on the kernel and they get the
 benefits of being able to do stuff with the code you provide, only
 giving us a half arsed interface to the hw and hiding all the good
 stuff in userspace isn't accepting this bargain. You can say what you
 like about liceneses and legalese but Linus picked the GPL for this
 sort of everyone gives what they get.

Sure, but you still slammed, and this affected in first order mostly Qualcomm, 
instead 
of stating that you simply do not want to be involved.

 They'll keep shipping closed stuff, just like they are now. Are you
 going to reverse engineer the userspace drivers, so people who care
 about open and free software platforms can use these drivers? (or have
 you already signed NDAs saying you can't). Why should we maintain a
 bunch of kernel code, when they are hiding away all the really useful
 stuff that people could improve.

Maintaining this exact code is not _your_ job, and you should've stated just 
that.

 I would, some points
 (a) Red Hat is the company I work for.
 (b) Red Hat doesn't really care about this stuff at all.
 (c) I'm the kernel maintainer for far longer that I worked for Red
 Hat, I also work a lot with Intel at Red Hat and I've told them the
 same thing, and VIA and now I'm stating it so I don't have to restate
 individually to every company again.

You will need to restate this every time anyway, unless you somehow manage to 
get your 
rather daunting and loud statement to be the first thing such corporations 
management 
people at linux.com, which is what people type in their browser first.

But maybe you might want to adjust your message.

 You don't understand what being a kernel maintainer is do you? at all?

Heh, i could make a really nasty statement here, but i wont.

 Wierd I'm still seeing new docs being produced and old docs being
 updated, not as fast as I'd like but I understand how many people
 there is working on it and I'd rather we also got fixes for all the
 current stuff done as well.

Hrm, i only see _very_ old docs getting updated, and none produced.

I still have docs which are pretty ready to be shipped (from 2007), under 
uncertain 
legal status (the ati game was fun!), which were never made public. I am sure 
that 
bridgman, gave you these docs too, but under even more shady circumstances.

 The code doesn't exist, there is no userspace code to be the
 documents, if you read what I said, documents would be a good start in
 lieu of code, but code is perfectly fine.

 Imagintaion technologies seriously? they've never ever taken one step
 towards opening anything, I don't think this statement is suddenly
 going to jumpstart them.

 Maybe you should disclose what NDAs you currently are under and who
 pays your bills, since you accuse me of Red Hat mind-control.

Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm 
sure
you knew.

 I'm not sure how the ARM market would benefit from having no userspace
 3D drivers just like the x86 market, if you actually were normal you'd
 realise the ARM people are trying to screw the market just like the
 desktop people, to save themselves some money, but maybe working on
 closed drivers has twisted you.

Ah, so you did know.

As a free software graphics driver developer there is little option left but to 
go 
straight to the ARM world, at least things have potential to move there still.

Well, unless the efforts there, like the one that triggered your mail, are 
thwarted 
too, like with your mail.

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

Re: Closed source userspace graphics drivers with an open source kernel component

[Luc Verhaegen]

On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote:
 Luc, can you please take your corporate bullshit out of this?  I can
 assume you know Dave personally and should be clearly aware that he's
 everything but a corporate drone.

Yes, with mails like this he clearly shows that he isn't a corporate drone.

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

Re: Closed source userspace graphics drivers with an open source kernel component

[Dave Airlie]

On Fri, Jul 2, 2010 at 9:12 PM, Luc Verhaegen l...@skynet.be wrote:
 On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote:
 Luc, can you please take your corporate bullshit out of this?  I can
 assume you know Dave personally and should be clearly aware that he's
 everything but a corporate drone.

 Yes, with mails like this he clearly shows that he isn't a corporate drone.


Luc, this isn't phoronix forums, the adults are talking here, run along now.

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

Re: Closed source userspace graphics drivers with an open source kernel component

[C. Bergström]

Dave Airlie wrote:

What potential? there are maybe 6 players on the ARM graphics scene

...
Nvidia - well we know their position will never change.
  
Never say never.  I have every reason to believe that Nvidia would 
respond to market demand.


*fingers crossed*

./C

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

Re: Closed source userspace graphics drivers with an open source kernel component

[Christoph Hellwig]

Luc, can you please take your corporate bullshit out of this?  I can
assume you know Dave personally and should be clearly aware that he's
everything but a corporate drone.

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

Fair eviction for i915, based on Daniel's drm_mm scanner

[Chris Wilson]

This is a resend of Daniel Vetter's drm mm work to provide a basis for
performing fair eviction in i915. I've taken the liberty of attaching the
acks and review comments from the previous round, so please look over and
check that they still hold true.

 drivers/gpu/drm/drm_mm.c|  359 ---
 drivers/gpu/drm/i915/Makefile   |1 +
 drivers/gpu/drm/i915/i915_drv.h |   11 +-
 drivers/gpu/drm/i915/i915_gem.c |  246 ++---
 drivers/gpu/drm/i915/i915_gem_evict.c   |  242 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   46 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
 drivers/gpu/drm/ttm/ttm_bo.c|6 -
 drivers/gpu/drm/ttm/ttm_bo_util.c   |2 -
 include/drm/drm_mm.h|   27 ++-
 10 files changed, 550 insertions(+), 391 deletions(-)
-ickle


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

[PATCH 02/11] drm: kill drm_mm_node-private

[Chris Wilson]

From: Daniel Vetter daniel.vet...@ffwll.ch

Only ever assigned, never used.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[glisse: I will re-add if needed for range-restricted allocations]
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c   |4 +---
 drivers/gpu/drm/ttm/ttm_bo.c  |6 --
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 --
 include/drm/drm_mm.h  |1 -
 4 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a6fbe3b..bfc7269 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2643,10 +2643,8 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, 
unsigned alignment)
if (free_space != NULL) {
obj_priv-gtt_space = drm_mm_get_block(free_space, obj-size,
   alignment);
-   if (obj_priv-gtt_space != NULL) {
-   obj_priv-gtt_space-private = obj;
+   if (obj_priv-gtt_space != NULL)
obj_priv-gtt_offset = obj_priv-gtt_space-start;
-   }
}
if (obj_priv-gtt_space == NULL) {
/* If the gtt is empty and we're still having trouble
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 555ebb1..9763288 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -476,7 +476,6 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
*bo, bool remove_all)
++put_count;
}
if (bo-mem.mm_node) {
-   bo-mem.mm_node-private = NULL;
drm_mm_put_block(bo-mem.mm_node);
bo-mem.mm_node = NULL;
}
@@ -670,7 +669,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
printk(KERN_ERR TTM_PFX Buffer eviction failed\n);
spin_lock(glob-lru_lock);
if (evict_mem.mm_node) {
-   evict_mem.mm_node-private = NULL;
drm_mm_put_block(evict_mem.mm_node);
evict_mem.mm_node = NULL;
}
@@ -929,8 +927,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node = node;
mem-mem_type = mem_type;
mem-placement = cur_flags;
-   if (node)
-   node-private = bo;
return 0;
}
 
@@ -973,7 +969,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
interruptible, no_wait_reserve, 
no_wait_gpu);
if (ret == 0  mem-mm_node) {
mem-placement = cur_flags;
-   mem-mm_node-private = bo;
return 0;
}
if (ret == -ERESTARTSYS)
@@ -1029,7 +1024,6 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
 out_unlock:
if (ret  mem.mm_node) {
spin_lock(glob-lru_lock);
-   mem.mm_node-private = NULL;
drm_mm_put_block(mem.mm_node);
spin_unlock(glob-lru_lock);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 13012a1..7cffb3e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -353,8 +353,6 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
fbo-vm_node = NULL;
 
fbo-sync_obj = driver-sync_obj_ref(bo-sync_obj);
-   if (fbo-mem.mm_node)
-   fbo-mem.mm_node-private = (void *)fbo;
kref_init(fbo-list_kref);
kref_init(fbo-kref);
fbo-destroy = ttm_transfered_destroy;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 4c10be3..da94071 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -48,7 +48,6 @@ struct drm_mm_node {
unsigned long start;
unsigned long size;
struct drm_mm *mm;
-   void *private;
 };
 
 struct drm_mm {
-- 
1.7.1

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

[PATCH 04/11] drm: sane naming for drm_mm.c

[Chris Wilson]

From: Daniel Vetter daniel.vet...@ffwll.ch

Yeah, I've kinda noticed that fl_entry is the free stack. Still
give it (and the memory node list ml_entry) decent names.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Thomas Hellstrom thellst...@vmwgfx.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/drm_mm.c |   72 ++---
 include/drm/drm_mm.h |   11 --
 2 files changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a5a7a16..d2267ff 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -64,8 +64,8 @@ static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, 
int atomic)
else {
child =
list_entry(mm-unused_nodes.next,
-  struct drm_mm_node, fl_entry);
-   list_del(child-fl_entry);
+  struct drm_mm_node, free_stack);
+   list_del(child-free_stack);
--mm-num_unused;
}
spin_unlock(mm-unused_lock);
@@ -94,7 +94,7 @@ int drm_mm_pre_get(struct drm_mm *mm)
return ret;
}
++mm-num_unused;
-   list_add_tail(node-fl_entry, mm-unused_nodes);
+   list_add_tail(node-free_stack, mm-unused_nodes);
}
spin_unlock(mm-unused_lock);
return 0;
@@ -116,8 +116,8 @@ static int drm_mm_create_tail_node(struct drm_mm *mm,
child-start = start;
child-mm = mm;
 
-   list_add_tail(child-ml_entry, mm-ml_entry);
-   list_add_tail(child-fl_entry, mm-fl_entry);
+   list_add_tail(child-node_list, mm-node_list);
+   list_add_tail(child-free_stack, mm-free_stack);
 
return 0;
 }
@@ -132,15 +132,15 @@ static struct drm_mm_node *drm_mm_split_at_start(struct 
drm_mm_node *parent,
if (unlikely(child == NULL))
return NULL;
 
-   INIT_LIST_HEAD(child-fl_entry);
+   INIT_LIST_HEAD(child-free_stack);
 
child-free = 0;
child-size = size;
child-start = parent-start;
child-mm = parent-mm;
 
-   list_add_tail(child-ml_entry, parent-ml_entry);
-   INIT_LIST_HEAD(child-fl_entry);
+   list_add_tail(child-node_list, parent-node_list);
+   INIT_LIST_HEAD(child-free_stack);
 
parent-size -= size;
parent-start += size;
@@ -168,7 +168,7 @@ struct drm_mm_node *drm_mm_get_block_generic(struct 
drm_mm_node *node,
}
 
if (node-size == size) {
-   list_del_init(node-fl_entry);
+   list_del_init(node-free_stack);
node-free = 0;
} else {
node = drm_mm_split_at_start(node, size, atomic);
@@ -206,7 +206,7 @@ struct drm_mm_node *drm_mm_get_block_range_generic(struct 
drm_mm_node *node,
}
 
if (node-size == size) {
-   list_del_init(node-fl_entry);
+   list_del_init(node-free_stack);
node-free = 0;
} else {
node = drm_mm_split_at_start(node, size, atomic);
@@ -228,8 +228,8 @@ void drm_mm_put_block(struct drm_mm_node *cur)
 {
 
struct drm_mm *mm = cur-mm;
-   struct list_head *cur_head = cur-ml_entry;
-   struct list_head *root_head = mm-ml_entry;
+   struct list_head *cur_head = cur-node_list;
+   struct list_head *root_head = mm-node_list;
struct drm_mm_node *prev_node = NULL;
struct drm_mm_node *next_node;
 
@@ -237,7 +237,7 @@ void drm_mm_put_block(struct drm_mm_node *cur)
 
if (cur_head-prev != root_head) {
prev_node =
-   list_entry(cur_head-prev, struct drm_mm_node, ml_entry);
+   list_entry(cur_head-prev, struct drm_mm_node, node_list);
if (prev_node-free) {
prev_node-size += cur-size;
merged = 1;
@@ -245,15 +245,15 @@ void drm_mm_put_block(struct drm_mm_node *cur)
}
if (cur_head-next != root_head) {
next_node =
-   list_entry(cur_head-next, struct drm_mm_node, ml_entry);
+   list_entry(cur_head-next, struct drm_mm_node, node_list);
if (next_node-free) {
if (merged) {
prev_node-size += next_node-size;
-   list_del(next_node-ml_entry);
-   list_del(next_node-fl_entry);
+   list_del(next_node-node_list);
+   list_del(next_node-free_stack);
spin_lock(mm-unused_lock);
if (mm-num_unused  MM_UNUSED_TARGET) {
-   list_add(next_node-fl_entry,
+   

[PATCH 05/11] drm_mm: extract check_free_mm_node

[Chris Wilson]

From: Daniel Vetter daniel.vet...@ffwll.ch

There are already two copies of this logic. And the new scanning
stuff will add some more. So extract it into a small helper
function.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Thomas Hellstrom thellst...@vmwgfx.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/drm_mm.c |   71 ++
 1 files changed, 34 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index d2267ff..fd86a6c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -283,6 +283,27 @@ void drm_mm_put_block(struct drm_mm_node *cur)
 
 EXPORT_SYMBOL(drm_mm_put_block);
 
+static int check_free_mm_node(struct drm_mm_node *entry, unsigned long size,
+ unsigned alignment)
+{
+   unsigned wasted = 0;
+
+   if (entry-size  size)
+   return 0;
+
+   if (alignment) {
+   register unsigned tmp = entry-start % alignment;
+   if (tmp)
+   wasted = alignment - tmp;
+   }
+
+   if (entry-size = size + wasted) {
+   return 1;
+   }
+
+   return 0;
+}
+
 struct drm_mm_node *drm_mm_search_free(const struct drm_mm *mm,
   unsigned long size,
   unsigned alignment, int best_match)
@@ -290,30 +311,20 @@ struct drm_mm_node *drm_mm_search_free(const struct 
drm_mm *mm,
struct drm_mm_node *entry;
struct drm_mm_node *best;
unsigned long best_size;
-   unsigned wasted;
 
best = NULL;
best_size = ~0UL;
 
list_for_each_entry(entry, mm-free_stack, free_stack) {
-   wasted = 0;
-
-   if (entry-size  size)
+   if (!check_free_mm_node(entry, size, alignment))
continue;
 
-   if (alignment) {
-   register unsigned tmp = entry-start % alignment;
-   if (tmp)
-   wasted += alignment - tmp;
-   }
+   if (!best_match)
+   return entry;
 
-   if (entry-size = size + wasted) {
-   if (!best_match)
-   return entry;
-   if (entry-size  best_size) {
-   best = entry;
-   best_size = entry-size;
-   }
+   if (entry-size  best_size) {
+   best = entry;
+   best_size = entry-size;
}
}
 
@@ -331,37 +342,23 @@ struct drm_mm_node *drm_mm_search_free_in_range(const 
struct drm_mm *mm,
struct drm_mm_node *entry;
struct drm_mm_node *best;
unsigned long best_size;
-   unsigned wasted;
 
best = NULL;
best_size = ~0UL;
 
list_for_each_entry(entry, mm-free_stack, free_stack) {
-   wasted = 0;
-
-   if (entry-size  size)
+   if (entry-start  end || (entry-start+entry-size)  start)
continue;
 
-   if (entry-start  end || (entry-start+entry-size)  start)
+   if (!check_free_mm_node(entry, size, alignment))
continue;
 
-   if (entry-start  start)
-   wasted += start - entry-start;
+   if (!best_match)
+   return entry;
 
-   if (alignment) {
-   register unsigned tmp = (entry-start + wasted) % 
alignment;
-   if (tmp)
-   wasted += alignment - tmp;
-   }
-
-   if (entry-size = size + wasted 
-   (entry-start + wasted + size) = end) {
-   if (!best_match)
-   return entry;
-   if (entry-size  best_size) {
-   best = entry;
-   best_size = entry-size;
-   }
+   if (entry-size  best_size) {
+   best = entry;
+   best_size = entry-size;
}
}
 
-- 
1.7.1

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

[PATCH 07/11] drm/i915: prepare for fair lru eviction

[Chris Wilson]

From: Daniel Vetter daniel.vet...@ffwll.ch

This does two little changes:

- Add an alignment parameter for evict_something. It's not really great to
  whack a carefully sized hole into the gtt with the wrong alignment.
  Especially since the fallback path is a full evict.

- With the inactive scan stuff we need to evict more that one object, so
  move the unbind call into the helper function that scans for the object
  to be evicted, too.  And adjust its name.

No functional changes in this patch, just preparation.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_gem.c |   67 ---
 1 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bfc7269..d4bcf71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
 #include linux/swap.h
 #include linux/pci.h
 
+static uint32_t i915_gem_get_fence_alignment(struct drm_gem_object *obj);
 static int i915_gem_object_flush_gpu_write_domain(struct drm_gem_object *obj);
 static void i915_gem_object_flush_gtt_write_domain(struct drm_gem_object *obj);
 static void i915_gem_object_flush_cpu_write_domain(struct drm_gem_object *obj);
@@ -48,7 +49,8 @@ static int i915_gem_object_wait_rendering(struct 
drm_gem_object *obj);
 static int i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
   unsigned alignment);
 static void i915_gem_clear_fence_reg(struct drm_gem_object *obj);
-static int i915_gem_evict_something(struct drm_device *dev, int min_size);
+static int i915_gem_evict_something(struct drm_device *dev, int min_size,
+   unsigned alignment);
 static int i915_gem_evict_from_inactive_list(struct drm_device *dev);
 static int i915_gem_phys_pwrite(struct drm_device *dev, struct drm_gem_object 
*obj,
struct drm_i915_gem_pwrite *args,
@@ -313,7 +315,8 @@ i915_gem_object_get_pages_or_evict(struct drm_gem_object 
*obj)
if (ret == -ENOMEM) {
struct drm_device *dev = obj-dev;
 
-   ret = i915_gem_evict_something(dev, obj-size);
+   ret = i915_gem_evict_something(dev, obj-size,
+  
i915_gem_get_fence_alignment(obj));
if (ret)
return ret;
 
@@ -1988,10 +1991,12 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
return 0;
 }
 
-static struct drm_gem_object *
-i915_gem_find_inactive_object(struct drm_device *dev, int min_size)
+static int
+i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
+ unsigned alignment, int *found)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
+   struct drm_gem_object *obj;
struct drm_i915_gem_object *obj_priv;
struct drm_gem_object *best = NULL;
struct drm_gem_object *first = NULL;
@@ -2005,14 +2010,31 @@ i915_gem_find_inactive_object(struct drm_device *dev, 
int min_size)
(!best || obj-size  best-size)) {
best = obj;
if (best-size == min_size)
-   return best;
+   break;
}
if (!first)
first = obj;
}
}
 
-   return best ? best : first;
+   obj = best ? best : first;
+
+   if (!obj) {
+   *found = 0;
+   return 0;
+   }
+
+   *found = 1;
+
+#if WATCH_LRU
+   DRM_INFO(%s: evicting %p\n, __func__, obj);
+#endif
+   obj_priv = to_intel_bo(obj);
+   BUG_ON(obj_priv-pin_count != 0);
+   BUG_ON(obj_priv-active);
+
+   /* Wait on the rendering and unbind the buffer. */
+   return i915_gem_object_unbind(obj);
 }
 
 static int
@@ -2098,11 +2120,11 @@ i915_gem_evict_everything(struct drm_device *dev)
 }
 
 static int
-i915_gem_evict_something(struct drm_device *dev, int min_size)
+i915_gem_evict_something(struct drm_device *dev,
+int min_size, unsigned alignment)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
-   struct drm_gem_object *obj;
-   int ret;
+   int ret, found;
 
struct intel_ring_buffer *render_ring = dev_priv-render_ring;
struct intel_ring_buffer *bsd_ring = dev_priv-bsd_ring;
@@ -2115,20 +2137,11 @@ i915_gem_evict_something(struct drm_device *dev, int 
min_size)
/* If there's an inactive buffer available now, grab it
 * and be done.
 */
-   obj = i915_gem_find_inactive_object(dev, min_size);
-   if (obj) {
-   struct drm_i915_gem_object *obj_priv;
-
-#if WATCH_LRU
-   DRM_INFO(%s: evicting %p\n, __func__, obj);

[PATCH 08/11] drm/i915: Use a common seqno for all rings.

[Chris Wilson]

This will be used by the eviction logic to maintain fairness between the
rings.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.h |3 +-
 drivers/gpu/drm/i915/i915_gem.c |2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   46 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
 4 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 98e6980..65cf336 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -236,6 +236,7 @@ typedef struct drm_i915_private {
struct pci_dev *bridge_dev;
struct intel_ring_buffer render_ring;
struct intel_ring_buffer bsd_ring;
+   uint32_t next_seqno;
 
drm_dma_handle_t *status_page_dmah;
void *seqno_page;
@@ -553,8 +554,6 @@ typedef struct drm_i915_private {
 */
struct delayed_work retire_work;
 
-   uint32_t next_gem_seqno;
-
/**
 * Waiting sequence number, if any
 */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d4bcf71..1b867c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4701,6 +4701,8 @@ i915_gem_init_ringbuffer(struct drm_device *dev)
goto cleanup_render_ring;
}
 
+   dev_priv-next_seqno = 1;
+
return 0;
 
 cleanup_render_ring:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2a3d2fa..ec04238 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -33,18 +33,35 @@
 #include i915_drm.h
 #include i915_trace.h
 
+static u32 i915_gem_get_seqno(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev-dev_private;
+   u32 seqno;
+
+   seqno = dev_priv-next_seqno;
+
+   /* reserve 0 for non-seqno */
+   if (++dev_priv-next_seqno == 0)
+   dev_priv-next_seqno = 1;
+
+   return seqno;
+}
+
 static void
 render_ring_flush(struct drm_device *dev,
struct intel_ring_buffer *ring,
u32 invalidate_domains,
u32 flush_domains)
 {
+   drm_i915_private_t *dev_priv = dev-dev_private;
+   u32 cmd;
+
 #if WATCH_EXEC
DRM_INFO(%s: invalidate %08x flush %08x\n, __func__,
  invalidate_domains, flush_domains);
 #endif
-   u32 cmd;
-   trace_i915_gem_request_flush(dev, ring-next_seqno,
+
+   trace_i915_gem_request_flush(dev, dev_priv-next_seqno,
 invalidate_domains, flush_domains);
 
if ((invalidate_domains | flush_domains)  I915_GEM_GPU_DOMAINS) {
@@ -233,9 +250,10 @@ render_ring_add_request(struct drm_device *dev,
struct drm_file *file_priv,
u32 flush_domains)
 {
-   u32 seqno;
drm_i915_private_t *dev_priv = dev-dev_private;
-   seqno = intel_ring_get_seqno(dev, ring);
+   u32 seqno;
+
+   seqno = i915_gem_get_seqno(dev);
 
if (IS_GEN6(dev)) {
BEGIN_LP_RING(6);
@@ -405,7 +423,9 @@ bsd_ring_add_request(struct drm_device *dev,
u32 flush_domains)
 {
u32 seqno;
-   seqno = intel_ring_get_seqno(dev, ring);
+
+   seqno = i915_gem_get_seqno(dev);
+
intel_ring_begin(dev, ring, 4);
intel_ring_emit(dev, ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(dev, ring,
@@ -539,7 +559,7 @@ render_ring_dispatch_gem_execbuffer(struct drm_device *dev,
exec_start = (uint32_t) exec_offset + exec-batch_start_offset;
exec_len = (uint32_t) exec-batch_len;
 
-   trace_i915_gem_request_submit(dev, dev_priv-mm.next_gem_seqno + 1);
+   trace_i915_gem_request_submit(dev, dev_priv-next_seqno + 1);
 
pipeline = exec-flags  I915_EXEC_PIPELINE_MASK;
if (pipeline != ring-pipeline) {
@@ -838,18 +858,6 @@ void intel_fill_struct(struct drm_device *dev,
intel_ring_advance(dev, ring);
 }
 
-u32 intel_ring_get_seqno(struct drm_device *dev,
-   struct intel_ring_buffer *ring)
-{
-   u32 seqno;
-   seqno = ring-next_seqno;
-
-   /* reserve 0 for non-seqno */
-   if (++ring-next_seqno == 0)
-   ring-next_seqno = 1;
-   return seqno;
-}
-
 struct intel_ring_buffer render_ring = {
.name   = render ring,
.regs   = {
@@ -867,7 +875,6 @@ struct intel_ring_buffer render_ring = {
.head   = 0,
.tail   = 0,
.space  = 0,
-   .next_seqno = 1,
.user_irq_refcount  = 0,
.irq_gem_seqno  = 0,
.waiting_gem_seqno  = 0,
@@ -906,7 +913,6 @@ struct intel_ring_buffer bsd_ring = {
.head   = 0,
.tail

[PATCH 09/11] drm/i915: Move the eviction logic to its own file.

[Chris Wilson]

The eviction code is the gnarly underbelly of memory management, and is
clearer if kept separated from the normal domain management in GEM.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/i915_drv.h   |6 +
 drivers/gpu/drm/i915/i915_gem.c   |  234 +-
 drivers/gpu/drm/i915/i915_gem_evict.c |  263 +
 4 files changed, 272 insertions(+), 232 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_evict.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index da78f2c..384fd45 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -8,6 +8,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
   i915_suspend.o \
  i915_gem.o \
  i915_gem_debug.o \
+ i915_gem_evict.o \
  i915_gem_tiling.o \
  i915_trace_points.o \
  intel_display.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65cf336..b6a0bd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -964,6 +964,7 @@ int i915_gem_init_ringbuffer(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 int i915_gem_do_init(struct drm_device *dev, unsigned long start,
 unsigned long end);
+int i915_gpu_idle(struct drm_device *dev);
 int i915_gem_idle(struct drm_device *dev);
 uint32_t i915_add_request(struct drm_device *dev,
struct drm_file *file_priv,
@@ -989,6 +990,11 @@ int i915_gem_object_flush_write_domain(struct 
drm_gem_object *obj);
 void i915_gem_shrinker_init(void);
 void i915_gem_shrinker_exit(void);
 
+/* i915_gem_evict.c */
+int i915_gem_evict_something(struct drm_device *dev, int min_size, unsigned 
alignment);
+int i915_gem_evict_everything(struct drm_device *dev);
+int i915_gem_evict_inactive(struct drm_device *dev);
+
 /* i915_gem_tiling.c */
 void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);
 void i915_gem_object_do_bit_17_swizzle(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b867c4..bb7d6a9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,9 +49,6 @@ static int i915_gem_object_wait_rendering(struct 
drm_gem_object *obj);
 static int i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
   unsigned alignment);
 static void i915_gem_clear_fence_reg(struct drm_gem_object *obj);
-static int i915_gem_evict_something(struct drm_device *dev, int min_size,
-   unsigned alignment);
-static int i915_gem_evict_from_inactive_list(struct drm_device *dev);
 static int i915_gem_phys_pwrite(struct drm_device *dev, struct drm_gem_object 
*obj,
struct drm_i915_gem_pwrite *args,
struct drm_file *file_priv);
@@ -1869,19 +1866,6 @@ i915_gem_flush(struct drm_device *dev,
flush_domains);
 }
 
-static void
-i915_gem_flush_ring(struct drm_device *dev,
-  uint32_t invalidate_domains,
-  uint32_t flush_domains,
-  struct intel_ring_buffer *ring)
-{
-   if (flush_domains  I915_GEM_DOMAIN_CPU)
-   drm_agp_chipset_flush(dev);
-   ring-flush(dev, ring,
-   invalidate_domains,
-   flush_domains);
-}
-
 /**
  * Ensures that all rendering to the object has completed and the object is
  * safe to unbind from the GTT or access from the CPU.
@@ -1991,53 +1975,7 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
return 0;
 }
 
-static int
-i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
- unsigned alignment, int *found)
-{
-   drm_i915_private_t *dev_priv = dev-dev_private;
-   struct drm_gem_object *obj;
-   struct drm_i915_gem_object *obj_priv;
-   struct drm_gem_object *best = NULL;
-   struct drm_gem_object *first = NULL;
-
-   /* Try to find the smallest clean object */
-   list_for_each_entry(obj_priv, dev_priv-mm.inactive_list, list) {
-   struct drm_gem_object *obj = obj_priv-base;
-   if (obj-size = min_size) {
-   if ((!obj_priv-dirty ||
-i915_gem_object_is_purgeable(obj_priv)) 
-   (!best || obj-size  best-size)) {
-   best = obj;
-   if (best-size == min_size)
-   break;
-   }
-   if (!first)
-   first = obj;
-   }
-   }
-
-   obj = best ? best : first;
-
-   if (!obj) {
-   *found = 0;
-   return 

[PATCH 10/11] drm/i915: Implement fair lru eviction across both rings.

[Chris Wilson]

Based in a large part upon Daniel Vetter's implementation and adapted
for handling multiple rings in a single pass.

This should lead to better gtt usage and fixes the page-fault-of-doom
triggered. The fairness is provided by scanning through the GTT space
amalgamating space in rendering order. As soon as we have a contiguous
space in the GTT large enough for the new object (and its alignment),
evict any object which lies within that space. This should keep more
objects resident in the GTT.

Doing throughput testing on a PineView machine with cairo-perf-trace
indicates that there is very little difference with the new LRU scan,
perhaps a small improvement.

Reference:

  Bug 15911 - Intermittent X crash (freeze)
  https://bugzilla.kernel.org/show_bug.cgi?id=15911

  Bug 20152 - cannot view JPG in firefox when running UXA
  https://bugs.freedesktop.org/show_bug.cgi?id=20152

  Bug 24369 - Hang when scrolling firefox page with window in front
  https://bugs.freedesktop.org/show_bug.cgi?id=24369

  Bug 28478 - Intermittent graphics lockups due to overflow/loop
  https://bugs.freedesktop.org/show_bug.cgi?id=28478

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.h   |2 +
 drivers/gpu/drm/i915/i915_gem_evict.c |  259 +++--
 2 files changed, 121 insertions(+), 140 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6a0bd0..8e9e6a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -652,6 +652,8 @@ struct drm_i915_gem_object {
struct list_head list;
/** This object's place on GPU write list */
struct list_head gpu_write_list;
+   /** This object's place on eviction list */
+   struct list_head evict_list;
 
/**
 * This is set if the object is on the active or flushing lists
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index bf4d199..87efbab 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -31,170 +31,149 @@
 #include i915_drv.h
 #include i915_drm.h
 
-static inline int
-i915_gem_object_is_purgeable(struct drm_i915_gem_object *obj_priv)
-{
-   return obj_priv-madv == I915_MADV_DONTNEED;
-}
-
-static int
-i915_gem_scan_inactive_list_and_evict(struct drm_device *dev, int min_size,
- unsigned alignment, int *found)
+static struct drm_i915_gem_object *
+i915_gem_next_active_object(struct drm_device *dev,
+   struct list_head **render_iter,
+   struct list_head **bsd_iter)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
-   struct drm_gem_object *obj;
-   struct drm_i915_gem_object *obj_priv;
-   struct drm_gem_object *best = NULL;
-   struct drm_gem_object *first = NULL;
+   struct drm_i915_gem_object *render_obj = NULL, *bsd_obj = NULL;
 
-   /* Try to find the smallest clean object */
-   list_for_each_entry(obj_priv, dev_priv-mm.inactive_list, list) {
-   struct drm_gem_object *obj = obj_priv-base;
-   if (obj-size = min_size) {
-   if ((!obj_priv-dirty ||
-i915_gem_object_is_purgeable(obj_priv)) 
-   (!best || obj-size  best-size)) {
-   best = obj;
-   if (best-size == min_size)
-   break;
-   }
-   if (!first)
-   first = obj;
-   }
-   }
-
-   obj = best ? best : first;
-
-   if (!obj) {
-   *found = 0;
-   return 0;
-   }
+   if (*render_iter != dev_priv-render_ring.active_list)
+   render_obj = list_entry(*render_iter,
+   struct drm_i915_gem_object,
+   list);
 
-   *found = 1;
+   if (HAS_BSD(dev)) {
+   if (*bsd_iter != dev_priv-bsd_ring.active_list)
+   bsd_obj = list_entry(*bsd_iter,
+struct drm_i915_gem_object,
+list);
 
-#if WATCH_LRU
-   DRM_INFO(%s: evicting %p\n, __func__, obj);
-#endif
-   obj_priv = to_intel_bo(obj);
-   BUG_ON(obj_priv-pin_count != 0);
-   BUG_ON(obj_priv-active);
+   if (render_obj == NULL) {
+   *bsd_iter = (*bsd_iter)-next;
+   return bsd_obj;
+   }
 
-   /* Wait on the rendering and unbind the buffer. */
-   return i915_gem_object_unbind(obj);
-}
+   if (bsd_obj == NULL) {
+   *render_iter = (*render_iter)-next;
+   return render_obj;
+   }
 
-static void
-i915_gem_flush_ring(struct drm_device 

[PATCH 11/11] drm/i915: Maintain LRU order of inactive objects upon access by CPU

[Chris Wilson]

In order to reduce the penalty of fallbacks under memory pressure and to
avoid a potential immediate ping-pong of evicting a mmaped buffer, we
move the object to the tail of the inactive list when a page is freshly
faulted or the object is moved into the CPU domain.

We choose not to protect the CPU objects from casual eviction,
preferring to keep the GPU active for as long as possible.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb7d6a9..26d0345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1036,6 +1036,10 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
}
 
+   /* Maintain LRU order of inactive objects */
+   if (ret == 0  obj_priv-gtt_space  !obj_priv-active)
+   list_move_tail(obj_priv-list, dev_priv-mm.inactive_list);
+
drm_gem_object_unreference(obj);
mutex_unlock(dev-struct_mutex);
return ret;
@@ -1169,6 +1173,9 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}
 
+   if (!obj_priv-active)
+   list_move_tail(obj_priv-list, dev_priv-mm.inactive_list);
+
pfn = ((dev-agp-base + obj_priv-gtt_offset)  PAGE_SHIFT) +
page_offset;
 
-- 
1.7.1

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

Re: [Intel-gfx] [PATCH 07/11] drm/i915: prepare for fair lru eviction

[Chris Wilson]

On Fri,  2 Jul 2010 15:02:17 +0100, Chris Wilson ch...@chris-wilson.co.uk 
wrote:
 From: Daniel Vetter daniel.vet...@ffwll.ch
 
 This does two little changes:
 
 - Add an alignment parameter for evict_something. It's not really great to
   whack a carefully sized hole into the gtt with the wrong alignment.
   Especially since the fallback path is a full evict.
 
 - With the inactive scan stuff we need to evict more that one object, so
   move the unbind call into the helper function that scans for the object
   to be evicted, too.  And adjust its name.
 
 No functional changes in this patch, just preparation.
 
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Closed source userspace graphics drivers with an open source kernel component

[C. Bergström]

Xavier Bestel wrote:

On Fri, 2010-07-02 at 19:07 +0700, C. Bergström wrote:
  

Dave Airlie wrote:


What potential? there are maybe 6 players on the ARM graphics scene

...
Nvidia - well we know their position will never change.
  
  
Never say never.  I have every reason to believe that Nvidia would 
respond to market demand.



Could you share those interesting reasons with us ?
  

I thought I stated that the main reason was market demand?

(Some of my own comments not representing any company)
By market I mean revenue... The Linux and FOSS world isn't exactly a 
huge market for high end graphics cards and total sales.  With the Tesla 
series of cards and most HPC clusters behing Linux powered this has the 
potential to change things.  Maybe I'm too optimistic and biased, but 
from my perspective I think there's a change in the winds coming..

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

Re: Closed source userspace graphics drivers with an open source kernel component

[Xavier Bestel]

On Fri, 2010-07-02 at 19:07 +0700, C. Bergström wrote:
 Dave Airlie wrote:
  What potential? there are maybe 6 players on the ARM graphics scene
 
  ...
  Nvidia - well we know their position will never change.

 Never say never.  I have every reason to believe that Nvidia would 
 respond to market demand.

Could you share those interesting reasons with us ?

Xav


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

[Bug 28437] [r300g] wrong texture colors with libtxc_dxtn.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28437

--- Comment #4 from Fabio Pedretti fabio@libero.it 2010-07-02 09:41:49 
PDT ---
 terrain is still blueish rather than green as with swrastg or r300g without
 libtxc_dxtn.so.

Now that bug #28169 is fixed, also the game, other than the editor, has all
textures blueish.

-- 
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: correctly update connector DPMS status in drm_fb_helper

[Jesse Barnes]

We don't currently update the DPMS status of the connector (both in the
connector itself and the connector's DPMS property) in the fb helper
code.  This means that if the kernel FB core has blanked the screen,
sysfs will still show a DPMS status of on.  It also means that when X
starts, it will try to light up the connectors, but the drm_crtc_helper
code will ignore the DPMS change since according to the connector, the
DPMS status is already on.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
my screen was blanked when I started X and now it won't light up bug).

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(struct fb_info *info)
struct drm_device *dev = fb_helper-dev;
struct drm_crtc *crtc;
struct drm_crtc_helper_funcs *crtc_funcs;
+   struct drm_connector *connector;
struct drm_encoder *encoder;
-   int i;
+   int i, j;
 
/*
 * For each CRTC in this fb, turn the crtc on then,
@@ -332,7 +333,14 @@ static void drm_fb_helper_on(struct fb_info *info)
 
crtc_funcs-dpms(crtc, DRM_MODE_DPMS_ON);
 
-
+   /* Walk the connectors  encoders on this fb turning them on */
+   for (j = 0; j  fb_helper-connector_count; j++) {
+   connector = fb_helper-connector_info[j]-connector;
+   connector-dpms = DRM_MODE_DPMS_ON;
+   drm_connector_property_set_value(connector,
+
dev-mode_config.dpms_property,
+DRM_MODE_DPMS_ON);
+   }
/* Found a CRTC on this fb, now find encoders */
list_for_each_entry(encoder, dev-mode_config.encoder_list, 
head) {
if (encoder-crtc == crtc) {
@@ -352,8 +360,9 @@ static void drm_fb_helper_off(struct fb_info *info, int 
dpms_mode)
struct drm_device *dev = fb_helper-dev;
struct drm_crtc *crtc;
struct drm_crtc_helper_funcs *crtc_funcs;
+   struct drm_connector *connector;
struct drm_encoder *encoder;
-   int i;
+   int i, j;
 
/*
 * For each CRTC in this fb, find all associated encoders
@@ -367,6 +376,14 @@ static void drm_fb_helper_off(struct fb_info *info, int 
dpms_mode)
if (!crtc-enabled)
continue;
 
+   /* Walk the connectors on this fb and mark them off */
+   for (j = 0; j  fb_helper-connector_count; j++) {
+   connector = fb_helper-connector_info[j]-connector;
+   connector-dpms = dpms_mode;
+   drm_connector_property_set_value(connector,
+
dev-mode_config.dpms_property,
+dpms_mode);
+   }
/* Found a CRTC on this fb, now find encoders */
list_for_each_entry(encoder, dev-mode_config.encoder_list, 
head) {
if (encoder-crtc == crtc) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28876] [radeon HD4250] Frequent lockups while screen locked

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28876

--- Comment #3 from Yann Dirson ydir...@altern.org 2010-07-02 12:20:13 PDT ---
Forgot to note the kernel version, vanilla 2.6.32.13 (with evms-bd-claim patch,
but that should not matter).

-- 
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

X:2252 conflicting memory types 40000000-48000000 uncached-minus-write-combining

[Justin P. Mattock]

this is new(below) has anybody reported/bisected hit this yet
(if not I'll bisect it)

[drm] Num pipes: 1
[   29.742432] [drm] writeback test succeeded in 1 usecs
[   30.089717] X:2252 conflicting memory types 4000-4800 
uncached-minus-write-combining
[   30.089721] reserve_memtype failed 0x4000-0x4800, track 
uncached-minus, req uncached-minus

[   30.123517] [drm] Num pipes: 1
[   30.351017] X:2252 freeing invalid memtype 4000-4800
[   30.354255] CPU 0
[   30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc 
bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state 
nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 
iptable_filter ip_tables x_tables firewire_ohci firewire_core video 
battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal 
evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib 
ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 
blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc 
raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap 
bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc 
uvcvideo[   30.354255]
[   30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f 
#3 Mac-F42187C8/MacBookPro2,2
[   30.354255] RIP: 0010:[a035811b]  [a035811b] 
radeon_read_ring_rptr+0x2b/0x2f [radeon]

[   30.354255] RSP: 0018:8800360dfc80  EFLAGS: 00010202
[   30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: 
c9cf8000
[   30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 
8800385e8848
[   30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 
0010
[   30.354255] R10:  R11: ea930af0 R12: 
0010
[   30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 
8800385e8178
[   30.354255] FS:  7f0aaa823840() GS:880001a0() 
knlGS:

[   30.354255] CS:  0010 DS:  ES:  CR0: 80050033
[   30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 
06f0
[   30.354255] DR0:  DR1:  DR2: 

[   30.354255] DR3:  DR6: 0ff0 DR7: 
0400
[   30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 
880033dc5c40)
[   30.354255]  8800360dfc90 a0358130 8800360dfca8 
a035881c
[   30.354255] 0 8800385e8848 8800360dfcc8 a0359ac7 

[   30.354255] 0 8800385e8848 8800360dfce8 a035c961 
8800385e8848

[   30.354255]  [a0358130] radeon_get_ring_head+0x11/0x3c [radeon]
[   30.354255]  [a035881c] radeon_commit_ring+0x48/0x97 [radeon]
[   30.354255]  [a0359ac7] radeon_do_cp_idle+0x140/0x14d [radeon]
[   30.354255]  [a035c961] 
radeon_apply_surface_regs+0x22/0x138 [radeon]

[   30.354255]  [a035cb4f] free_surface+0xd8/0xee [radeon]
[   30.354255]  [a0365036] radeon_driver_lastclose+0x3c/0x56 
[radeon]

[   30.354255]  [a031440b] drm_lastclose+0x44/0x2ad [drm]
[   30.354255]  [a0314eda] drm_release+0x656/0x6a3 [drm]
[   30.354255]  [8105abaf] put_files_struct+0x65/0xb3
[   30.354255]  [8105ac43] exit_files+0x46/0x4e
[   30.354255]  [8105c2e6] do_exit+0x214/0x69f
[   30.354255]  [810ebc2e] ? fput+0x1e2/0x1f1
[   30.354255]  [8105c7e3] do_group_exit+0x72/0x9a
[   30.354255]  [8105c81d] sys_exit_group+0x12/0x16
[   30.354255]  [81026442] system_call_fastpath+0x16/0x1b
[   30.354255]  RSP 8800360dfc80
[   31.312879] ---[ end trace 9a7b92300d4121f6 ]---
[   30.354255]  [810ebb6e] fput+0x122/0x1f1
[   30.354255]  [810e9181] filp_close+0x63/0x6d

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

[Bug 28860] [r300g] Yo Frankie crash: assertion failure / Too many hardware temporaries used

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #3 from Pavel Ondračka dra...@centrum.cz 2010-07-02 13:40:49 PDT 
---
(In reply to comment #0)
 yofrankie-linux-i386.bin: state_tracker/st_mesa_to_tgsi.c:181: dst_register:
 Assertion `t-outputMapping[index] 
 (sizeof(t-outputs)/sizeof(*(t-outputs)))' failed.

This looks similar to bug 28169, should be fixed with commit
6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a

-- 
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 28294] [r300g] Unigine Sanctuary v2.2: black glitches

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28294

--- Comment #16 from Tom Stellard tstel...@gmail.com 2010-07-02 20:04:47 PDT 
---
Can you try again with the current git master branch?  You should see less
errors now.

-- 
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

hardware implementation of Xorg

[Piotr Gluszenia Slawinski]

Hello.
While i've been thinking about open-hardware alternatives
for Xorg , i started to wonder about if it isn't already
time to implement Xorg purely in hardware, i.e. set of
FPGA chips.

one can find many nice examples of functional 8bit systems
able to fit into single chips
(i.e. http://zxgate.sourceforge.net/ )

ofcourse at current state of technology Xorg will be unable
to fit single chip, yet it's current modular nature
and fact that it's (still) completely open-source,
and uses pieces of system which are also open-source
developed (i.e. http://wiki.opengraphics.org/ )

there are ofcourse C to verilog converters, and almost
whole process (except prototyping) could be automated.

do you think it is time for it now, or it's better to wait
few years until Xorg will reach enough stability, and Xorg
foundation will be able to afford fabbing it's own ,
non-fpga chips ?

did anyone already performed any evaluations on how
power-efficient such chips could be?

perhaps mobile market could use them as more convient alternative
to cpu+gpu hybrids, esp. for devices without heavy 
3d, ultra-high-resolution, and multihead capability...



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

Re: hardware implementation of Xorg

[Piotr Gluszenia Slawinski]

ofcourse at current state of technology Xorg will be unable
to fit single chip, yet it's current modular nature
and fact that it's (still) completely open-source,
and uses pieces of system which are also open-source
developed (i.e. http://wiki.opengraphics.org/ )


... could allow it to fit in several 'off-the-shelf' fpga's.


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

[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus-write-combining

[Justin P. Mattock]

On 07/02/10 13:04, Justin P. Mattock wrote:

this is new(below) has anybody reported/bisected hit this yet
(if not I'll bisect it)

[drm] Num pipes: 1
[   29.742432] [drm] writeback test succeeded in 1 usecs
[   30.089717] X:2252 conflicting memory types 4000-4800 
uncached-minus-write-combining
[   30.089721] reserve_memtype failed 0x4000-0x4800, track 
uncached-minus, req uncached-minus

[   30.123517] [drm] Num pipes: 1
[   30.351017] X:2252 freeing invalid memtype 4000-4800
[   30.354255] CPU 0
[   30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco 
xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat 
xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack 
nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci 
firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw 
ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 
lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic 
cbc des_generic cast5 blowfish serpent camellia twofish twofish_common 
ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart 
rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor 
mperf appletouch applesmc uvcvideo[   30.354255]
[   30.354255] Pid: 2252, comm: X Not tainted 
2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2
[   30.354255] RIP: 0010:[a035811b]  [a035811b] 
radeon_read_ring_rptr+0x2b/0x2f [radeon]

[   30.354255] RSP: 0018:8800360dfc80  EFLAGS: 00010202
[   30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: 
c9cf8000
[   30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 
8800385e8848
[   30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 
0010
[   30.354255] R10:  R11: ea930af0 R12: 
0010
[   30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 
8800385e8178
[   30.354255] FS:  7f0aaa823840() GS:880001a0() 
knlGS:

[   30.354255] CS:  0010 DS:  ES:  CR0: 80050033
[   30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 
06f0
[   30.354255] DR0:  DR1:  DR2: 

[   30.354255] DR3:  DR6: 0ff0 DR7: 
0400
[   30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 
880033dc5c40)
[   30.354255]  8800360dfc90 a0358130 8800360dfca8 
a035881c
[   30.354255] 0 8800385e8848 8800360dfcc8 a0359ac7 

[   30.354255] 0 8800385e8848 8800360dfce8 a035c961 
8800385e8848
[   30.354255]  [a0358130] radeon_get_ring_head+0x11/0x3c 
[radeon]
[   30.354255]  [a035881c] radeon_commit_ring+0x48/0x97 
[radeon]
[   30.354255]  [a0359ac7] radeon_do_cp_idle+0x140/0x14d 
[radeon]
[   30.354255]  [a035c961] 
radeon_apply_surface_regs+0x22/0x138 [radeon]

[   30.354255]  [a035cb4f] free_surface+0xd8/0xee [radeon]
[   30.354255]  [a0365036] radeon_driver_lastclose+0x3c/0x56 
[radeon]

[   30.354255]  [a031440b] drm_lastclose+0x44/0x2ad [drm]
[   30.354255]  [a0314eda] drm_release+0x656/0x6a3 [drm]
[   30.354255]  [8105abaf] put_files_struct+0x65/0xb3
[   30.354255]  [8105ac43] exit_files+0x46/0x4e
[   30.354255]  [8105c2e6] do_exit+0x214/0x69f
[   30.354255]  [810ebc2e] ? fput+0x1e2/0x1f1
[   30.354255]  [8105c7e3] do_group_exit+0x72/0x9a
[   30.354255]  [8105c81d] sys_exit_group+0x12/0x16
[   30.354255]  [81026442] system_call_fastpath+0x16/0x1b
[   30.354255]  RSP 8800360dfc80
[   31.312879] ---[ end trace 9a7b92300d4121f6 ]---
[   30.354255]  [810ebb6e] fput+0x122/0x1f1
[   30.354255]  [810e9181] filp_close+0x63/0x6d

Justin P. Mattock



o.k. finished bisecting.. the results point to this: 6a4f3b523 doing a 
git revert gets me to startx without crashing and burning.

the problem code is this:
new-subtree_max_end = new-end;

which sends me to: (if im reading correctly)
if (match-type != found_type  newtype == NULL)
goto failure;

so how/what might be happening here?!

Justin P. Mattock


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