On Fri, Aug 6, 2010 at 01:59, Linux Kernel Mailing List
wrote:
> Gitweb: ? ?
> http://git.kernel.org/linus/dcdb167402cbdca1d021bdfa5f63995ee0a79317
> Commit: ? ? dcdb167402cbdca1d021bdfa5f63995ee0a79317
> Parent: ? ? 01d73a6967f12fe6c4bbde1834a9fe662264a2eb
> Author: ? ? Jordan Crouse
> AuthorDa
On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich wrote:
> Currently, the LVDS connector on i915-equipped laptops
> is always reported as connected, regardless of the lid
> state and presence of external monitors. This was done
> because of too many BIOSes reporting lid status in
> an unreliable w
On Tue, Aug 10, 2010 at 5:41 PM, wrote:
> From: Jerome Glisse
>
> We should not allocate any object into unmappable vram if we
> have no means to access them which on all GPU means having the
> CP running and on newer GPU having the blit utility working.
>
> This patch limit the vram allocation
e: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100810/f99ea41c/attachment.pgp>
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/rad
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich wrote:
> Currently, the LVDS connector on i915-equipped laptops
> is always reported as connected, regardless of the lid
> state and presence of external monitors. This was done
> because of too many BIOSes reporting lid status in
> an unreliable w
Currently, the LVDS connector on i915-equipped laptops
is always reported as connected, regardless of the lid
state and presence of external monitors. This was done
because of too many BIOSes reporting lid status in
an unreliable way. However, in a quite usual setup of
a laptop attached to an ext
Alex Deucher wrote:
> - buffer offsets in the base regs are 256b aligned so
> shift properly when comparing, fixed by Andre Maasikas
> - mipmap size was calculated wrong when nlevel=0
> - texture bo offsets were used after the bo base address was added
> - vertex resource size register is size - 1,
https://bugs.freedesktop.org/show_bug.cgi?id=29495
Summary: [r300g] Shadowgrounds: character portraits rendered
wrong
Product: Mesa
Version: git
Platform: Other
URL: http://demofiles.linuxgamepublishing.com/shadowgrounds
https://bugs.freedesktop.org/show_bug.cgi?id=29495
Summary: [r300g] Shadowgrounds: character portraits rendered
wrong
Product: Mesa
Version: git
Platform: Other
URL: http://demofiles.linuxgamepublishing.com/shadowgrounds
On Tue, Aug 10, 2010 at 5:41 PM, wrote:
> From: Jerome Glisse
>
> We should not allocate any object into unmappable vram if we
> have no means to access them which on all GPU means having the
> CP running and on newer GPU having the blit utility working.
>
> This patch limit the vram allocation
On my laptop X hangs as soon as something uses OpenGL it seems.
Running for example glxinfo or glxgears causes it to freeze.
I have not had any issues like this before, and 2.6.34 works ok but not 2.6.35
I have pasted the Oops here: http://codepad.org/R9Nuheug
I will include it with this email to
On Tue, 2010-08-10 at 22:35 +0200, Geert Uytterhoeven wrote:
> Now, do we really need ? It seems I can make it build and boot
> using:
>
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -31,7 +31,9 @@
> #ifndef LINUX_VGA_H
> #define LINUX_VGA_H
>
> +#ifdef CONFIG_VGA_ARB
>
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
From: Jerome Glisse
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and runn
On Fri, Aug 6, 2010 at 01:59, Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/linus/dcdb167402cbdca1d021bdfa5f63995ee0a79317
> Commit: dcdb167402cbdca1d021bdfa5f63995ee0a79317
> Parent: 01d73a6967f12fe6c4bbde1834a9fe662264a2eb
> Author: Jordan Crouse
> AuthorDa
Rather than calling get_memory_clock and get_engine_clock,
used the tracked values from the pm code. Calling the tables
adds additional latency in the modesetting and pm paths.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_clocks.c |8
drivers/gpu/drm/radeon/radeon_
https://bugs.freedesktop.org/show_bug.cgi?id=29445
--- Comment #7 from 0453411...@netti.fi 2010-08-10 11:11:45 PDT ---
A little update... I've tried out all the different kernel options that I could
think of as well as enable USB debugging output, usb_storage debugging output,
ATA system debugging
https://bugs.freedesktop.org/show_bug.cgi?id=29445
--- Comment #7 from 0453411800 at netti.fi 2010-08-10 11:11:45 PDT ---
A little update... I've tried out all the different kernel options that I could
think of as well as enable USB debugging output, usb_storage debugging output,
ATA system debugg
Rather than calling get_memory_clock and get_engine_clock,
used the tracked values from the pm code. Calling the tables
adds additional latency in the modesetting and pm paths.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_clocks.c |8
drivers/gpu/drm/radeon/radeon_
Alex Deucher wrote:
- buffer offsets in the base regs are 256b aligned so
shift properly when comparing, fixed by Andre Maasikas
- mipmap size was calculated wrong when nlevel=0
- texture bo offsets were used after the bo base address was added
- vertex resource size register is size - 1, not siz
https://bugs.freedesktop.org/show_bug.cgi?id=28940
--- Comment #3 from Nicos Gollan 2010-08-10 08:31:19 PDT
---
It's still there in the 2.6.35 kernel.
I noticed the following messages in dmesg when waking up from suspend-to-RAM:
[1.463035] ATOM BIOS: M54CSP/M52CSP
[27369.832013] [drm:atom_
https://bugs.freedesktop.org/show_bug.cgi?id=28940
--- Comment #3 from Nicos Gollan 2010-08-10 08:31:19
PDT ---
It's still there in the 2.6.35 kernel.
I noticed the following messages in dmesg when waking up from suspend-to-RAM:
[1.463035] ATOM BIOS: M54CSP/M52CSP
[27369.832013] [drm:atom_
On my laptop X hangs as soon as something uses OpenGL it seems.
Running for example glxinfo or glxgears causes it to freeze.
I have not had any issues like this before, and 2.6.34 works ok but not 2.6.35
I have pasted the Oops here: http://codepad.org/R9Nuheug
I will include it with this email t
https://bugs.freedesktop.org/show_bug.cgi?id=28517
--- Comment #13 from Sven Arvidsson 2010-08-10 07:51:36 PDT ---
Created an attachment (id=37768)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37768)
Screenshot of oversized character
I added a screenshot of the character, if that's helpf
https://bugs.freedesktop.org/show_bug.cgi?id=28517
--- Comment #13 from Sven Arvidsson 2010-08-10 07:51:36 PDT ---
Created an attachment (id=37768)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37768)
Screenshot of oversized character
I added a screenshot of the character, if that's helpf
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #25 from pete...@hottemptation.org 2010-08-10 04:22:23 PDT ---
I mean "immediatley"
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #25 from peterle at hottemptation.org 2010-08-10 04:22:23 PDT ---
I mean "immediatley"
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #24 from pete...@hottemptation.org 2010-08-10 04:20:44 PDT ---
I'am sorry, the patch doesn't fix 29384 and 27744.
The system reacts like before, dmesg output is also exactly the same.
To new hints/quesitions:
With 2.6.34 I had no del
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #24 from peterle at hottemptation.org 2010-08-10 04:20:44 PDT ---
I'am sorry, the patch doesn't fix 29384 and 27744.
The system reacts like before, dmesg output is also exactly the same.
To new hints/quesitions:
With 2.6.34 I had no
I just updated the tree, I had to drop one of the cleanups for now, same
tree has the initial mail.
The following changes since commit 96576a9e1a0cdb8a43d3af5846be0948f52b4460:
agp: intel-agp: do not use PCI resources before pci_enable_device()
(2010-08-05 12:28:25 +1000)
are available in t
https://bugs.freedesktop.org/show_bug.cgi?id=28517
--- Comment #12 from Pavel Ondračka 2010-08-10 01:33:26 PDT
---
Created an attachment (id=37759)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37759)
RADEON_DEBUG=vp log with vs-if-loop.patch
Characters are being rendered now with your p
https://bugs.freedesktop.org/show_bug.cgi?id=28517
--- Comment #12 from Pavel Ondra?ka 2010-08-10 01:33:26
PDT ---
Created an attachment (id=37759)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37759)
RADEON_DEBUG=vp log with vs-if-loop.patch
Characters are being rendered now with your p
https://bugs.freedesktop.org/show_bug.cgi?id=29363
Pavel Ondračka changed:
What|Removed |Added
Attachment #37528|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=29363
Pavel Ondra?ka changed:
What|Removed |Added
Attachment #37528|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=29363
Pavel Ondračka changed:
What|Removed |Added
Attachment #37530|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=29363
Pavel Ondra?ka changed:
What|Removed |Added
Attachment #37530|0 |1
is obsolete|
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/rad
acked-by: Thomas Hellstr?m
On 08/05/2010 03:09 PM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> In order to properly deal with GPU reordering of blocks in physical VRAM,
> Nouveau needs to be able to have better control over VRAM allocations.
>
> Currently nouveau is extremely wasteful and forces ma
41 matches
Mail list logo
