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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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|

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

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

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

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

[PATCH 05/11] drm_mm: extract check_free_mm_node

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:

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

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

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

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

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

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 +

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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:

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

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

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

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]

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

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

hardware implementation of Xorg

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.

Re: hardware implementation of Xorg

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

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

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

> 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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

> 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

Closed source userspace graphics drivers with an open source kernel component

> 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

Closed source userspace graphics drivers with an open source kernel component

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

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

> 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

Closed source userspace graphics drivers with an open source kernel component

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

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.

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

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|

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

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

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

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

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

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

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

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

[PATCH 05/11] drm_mm: extract check_free_mm_node

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

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

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

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

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

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

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

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

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 +

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

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

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

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

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

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

Closed source userspace graphics drivers with an open source kernel component

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.

Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

Closed source userspace graphics drivers with an open source kernel component

-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

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

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

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

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 >