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
> 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 ar
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-c
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-minu
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 d
>
> 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 bi
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 sev
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
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 rec
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 rec
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
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 alr
-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/Lin
-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/Lin
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
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 fallba
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
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
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 CP
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
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_ge
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 +-
driv
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 evic
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
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 +
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 ++
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
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/t
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 10064
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| 35
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->outpu
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->outpu
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 i
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
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 faile
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
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 PM
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
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
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 submi
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 t
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 t
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
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/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/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
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
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
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 i
> 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 pr
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 d
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
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 alr
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
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 th
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 fallba
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 CP
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
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_ge
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 +-
driv
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 evic
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
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 +
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 ++
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
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/t
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 10064
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| 35
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.
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.freedeskt
> 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
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
__
> 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 ar
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 d
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 i
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
100% agreed on the rationale, and I hope you can keep this crap out!
>
> 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 bi
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 submi
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
> 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
process
81 matches
Mail list logo
