Doesn't really buy much, but looks nicer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_evict.c | 31 ---
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
With the switch to implicit free space accounting one pointer
got unused when scanning. Use it to create a single-linked list
to ensure correct unwinding of the scan state.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c |4
include/drm/drm_mm.h |8
2 files ch
Use the list iterator provided by drm_mm instead.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |4
drivers/gpu/drm/i915/i915_gem.c |4
drivers/gpu/drm/i915/i915_gem_gtt.c |4 +++-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/dri
It's a copy of obj->gtt_space.start. With all the recent massive
sed-processing over the tree, removing this wont hurt. And with
gtt_space embedded it can't be called a performance optimization
anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 ---
driv
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |6 +-
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 93 ++---
drivers/gpu/drm/i915/i915_gem_evict.c |6 +-
drivers/gpu/drm/i915/i915_gem_gtt.c
The old api has a two-step process: First search for a suitable
free hole, then allocate from that specific hole. No user used
this to do anything clever. So drop it.
With struct drm_mm_node embedded, we cannot track allocations
anymore by checking for a NULL pointer. So keep track of this
and add
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 67 -
1 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 4fa33e1..fecb406 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/d
The idea is to track free holes implicitly by marking the allocation
immediatly preceeding a hole.
To avoid an ugly corner case add a dummy head_node to struct drm_mm
to track the hole that spans to complete allocation area when the
memory manager is empty.
To guarantee that there's always a prec
Nouveau was checking drm_mm internals on teardown to see whether the
memory manager was initialized. Hide these internals in a small
inline helper function.
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_object.c |2 +-
drivers/gpu/drm/nouveau/nv50_instmem.c
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be done anymore
in drm_mm. It looks like some dece
On Fri, 12 Nov 2010 18:36:32 +0100, Daniel Vetter
wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible.
I like the end result for i915 in that it couples the
On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds wrote:
> But when you cherry-pick it from some random internal tree that nobody
> will necessarily ever see, and that you don't even describe what it
> is, it's only pure confusion. I do
>
> [torvalds at i5 linux]$ git show 6aa56062eaba67adfb2
On Fri, 12 Nov 2010 18:36:32 +0100, Daniel Vetter
wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible.
I like the end result for i915 in that it couples the
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously not
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson
wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously no
Doesn't really buy much, but looks nicer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_evict.c | 31 ---
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
It's a copy of obj->gtt_space.start. With all the recent massive
sed-processing over the tree, removing this wont hurt. And with
gtt_space embedded it can't be called a performance optimization
anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 ---
driv
With the switch to implicit free space accounting one pointer
got unused when scanning. Use it to create a single-linked list
to ensure correct unwinding of the scan state.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c |4
include/drm/drm_mm.h |8
2 files ch
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |6 +-
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 93 ++---
drivers/gpu/drm/i915/i915_gem_evict.c |6 +-
drivers/gpu/drm/i915/i915_gem_gtt.c
Use the list iterator provided by drm_mm instead.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |4
drivers/gpu/drm/i915/i915_gem.c |4
drivers/gpu/drm/i915/i915_gem_gtt.c |4 +++-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/dri
The old api has a two-step process: First search for a suitable
free hole, then allocate from that specific hole. No user used
this to do anything clever. So drop it.
With struct drm_mm_node embedded, we cannot track allocations
anymore by checking for a NULL pointer. So keep track of this
and add
The idea is to track free holes implicitly by marking the allocation
immediatly preceeding a hole.
To avoid an ugly corner case add a dummy head_node to struct drm_mm
to track the hole that spans to complete allocation area when the
memory manager is empty.
To guarantee that there's always a prec
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 67 -
1 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 4fa33e1..fecb406 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/d
Nouveau was checking drm_mm internals on teardown to see whether the
memory manager was initialized. Hide these internals in a small
inline helper function.
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_object.c |2 +-
drivers/gpu/drm/nouveau/nv50_instmem.c
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be done anymore
in drm_mm. It looks like some dece
Hi, Lee,
there are several regressions caused by this patch,
http://marc.info/?l=linux-acpi&m=128872402020412&w=2
http://marc.info/?l=linux-acpi&m=128858111022621&w=2
Yes, We can fix it by "select INPUT if ACPI"/"select
VIDEO_OUTPUT_CONTROL if ACPI".
But IMO, STUB_POULSBO should not select ACPI_
On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds
wrote:
> But when you cherry-pick it from some random internal tree that nobody
> will necessarily ever see, and that you don't even describe what it
> is, it's only pure confusion. I do
>
> [torva...@i5 linux]$ git show 6aa56062eaba67adfb247
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #9 from Maximiliano Castañón 2010-11-12
09:14:31 PST ---
Ok, I have created a bug against OpenOffice, LibreOffice and GLX
GLX https://bugs.freedesktop.org/show_bug.cgi?id=31586
OpenOffice and GLX http://www.openoffice.org/issues/sh
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #9 from Maximiliano Casta??n 2010-11-12
09:14:31 PST ---
Ok, I have created a bug against OpenOffice, LibreOffice and GLX
GLX https://bugs.freedesktop.org/show_bug.cgi?id=31586
OpenOffice and GLX http://www.openoffice.org/issues/sh
https://bugs.freedesktop.org/show_bug.cgi?id=31586
Summary: using GLX module screw the X server when it's used
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=31586
Summary: using GLX module screw the X server when it's used
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote:
> On 11/11/2010 04:27 PM, Jerome Glisse wrote:
> > On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom
> > wrote:
> >
> >> The following patch is really intended for the next merge window.
> >>
> >> RFC:
> >> 1) Are there any implementa
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #8 from Maximiliano Castañón 2010-11-12
08:26:55 PST ---
[13:15] yeah, webchat is blocked due to spammers
[13:15] agd5f i disabled the GLX module
[13:16] you also have to be logged in to send to the channel
[13:17] now the X are
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #8 from Maximiliano Casta??n 2010-11-12
08:26:55 PST ---
[13:15] yeah, webchat is blocked due to spammers
[13:15] agd5f i disabled the GLX module
[13:16] you also have to be logged in to send to the channel
[13:17] now the X are
On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.
Btw, Chris - don't do this:
commit 08deebf98783d3de553eed2c9b6b8dc
On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.
Btw, Chris - don't do this:
commit 08deebf98783d3de553eed2c9b6b8dc
On 11/11/2010 11:46 PM, Ben Skeggs wrote:
> On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote:
>
>> On 11/11/2010 04:27 PM, Jerome Glisse wrote:
>>
>>> On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
The following patch is really intended for t
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #7 from Maximiliano Castañón 2010-11-12
08:11:41 PST ---
Ok, the X server are running much better, but still existing the problem of
Fullscreen with Openoffice, what can i provide to get that working?
Thanks guys
--
Configure bugm
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #7 from Maximiliano Casta??n 2010-11-12
08:11:41 PST ---
Ok, the X server are running much better, but still existing the problem of
Fullscreen with Openoffice, what can i provide to get that working?
Thanks guys
--
Configure bugm
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #6 from Maximiliano Castañón 2010-11-12
08:05:23 PST ---
I guess i found the problem, GLX it´s a module loaded by the Xorg, i disable it
with
Section "Module"
Disable "glx"
EndSection
And now it seems to work normall
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #6 from Maximiliano Casta??n 2010-11-12
08:05:23 PST ---
I guess i found the problem, GLX it?s a module loaded by the Xorg, i disable it
with
Section "Module"
Disable "glx"
EndSection
And now it seems to work normall
https://bugs.freedesktop.org/show_bug.cgi?id=30007
--- Comment #35 from Marek Olšák 2010-11-12 04:33:58 PST ---
(In reply to comment #8)
> r300 FP: Compiler Error:
> Fragment program does not support relative addressing of source operands.
> Using a dummy shader instead.
Relative addressing is
https://bugs.freedesktop.org/show_bug.cgi?id=30007
--- Comment #35 from Marek Ol??k 2010-11-12 04:33:58 PST
---
(In reply to comment #8)
> r300 FP: Compiler Error:
> Fragment program does not support relative addressing of source operands.
> Using a dummy shader instead.
Relative addressing is
https://bugs.freedesktop.org/show_bug.cgi?id=31578
Summary: r600g: enforce minimum stride on render target texture
images causes texture corruption on teapot demp.
Product: Mesa
Version: git
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=31578
Summary: r600g: enforce minimum stride on render target texture
images causes texture corruption on teapot demp.
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Hi Rui,
First, thank's for your review and take care.
於 五，2010-11-12 於 09:31 +0800，Zhang Rui 提到：
> Hi, Lee,
>
> there are several regressions caused by this patch,
> http://marc.info/?l=linux-acpi&m=128872402020412&w=2
> http://marc.info/?l=linux-acpi&m=128858111022621&w=2
>
> Yes, We can fix
Hi, Lee,
there are several regressions caused by this patch,
http://marc.info/?l=linux-acpi&m=128872402020412&w=2
http://marc.info/?l=linux-acpi&m=128858111022621&w=2
Yes, We can fix it by "select INPUT if ACPI"/"select
VIDEO_OUTPUT_CONTROL if ACPI".
But IMO, STUB_POULSBO should not select ACPI_
On Thu, Nov 11, 2010 at 22:10, Alex Riesen wrote:
> an alternative way to reproduce it, is to just wait for screensaver.
> Only the backlight is off, it is possible to see the image on LCD
> matrix if you get the angle right.
Bugzilla bug:
https://bugzilla.kernel.org/show_bug.cgi?id=22672
__
48 matches
Mail list logo
