[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled

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

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

--- Comment #4 from Dave Airlie  2011-03-12 
16:04:54 PST ---
 no it just moves things around to avoid hitting those registers at runtime.

The speed increase you'll see is with fullscreen apps running at less than
vblank frames. You should see more fps or get closer to vblank.

However currently page flip is limited to vblank synced rendering.

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

[Bug 33515] System lockup with Page-flipping

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

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

--- Comment #11 from Marek Ol??k  2011-03-12 14:25:53 PST 
---
Does this kernel patch help?

https://bugs.freedesktop.org/attachment.cgi?id=44345

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

[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled

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

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

--- Comment #3 from ?lmos  2011-03-12 14:07:12 PST ---
2.6.38-rc8 with the patch seems stable so far.
Doesn't it disable pageflip, though? According to phoronix there should be some
3d performance increase with pageflip, but I haven't noticed any.

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

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

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

https://bugzilla.kernel.org/show_bug.cgi?id=29412





--- Comment #2 from Jon Dowland   
2011-03-12 13:43:17 ---
I did bisect to identify the first bad commit as
17d857be649a21ca90008c6dc425d849fa83db5c , which is merely tagging 2.6.32-rc1. 
I suspect some user space component is only enabling KMS if the kernel version
equals or exceeds this tag and that's why it is only triggered from that
commit.

Can you give me any hints on how to do a more useful bisect? Perhaps limiting
the scope to a particular source path?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Yong Zhang]

On Sat, Mar 12, 2011 at 12:34:09PM +0800, Yong Zhang wrote:
> On Fri, Mar 11, 2011 at 12:46:59PM +0100, Thomas Renninger wrote:
> > Happy testing..., if you have a recent machine, you'll like it!
> > 
> > After some testing phase it would be great to get this tool
> > merged into the kernel git repo under:
> > tools/power/cpupower
> > and replace the Intel HW only supporting tools in tools/power/x86.
> 
> I got below output on my laptop:
> 
> |Mperf   || Idle_Stats
> CPU | C0   | Cx   | Freq || POLL | C1   | C2   | C3   
>0| 36.00| 64.00|   820||1843411670376227.2|1843411670376692.2|  0.00|  0.00
>1| 44.69| 55.31|   920||  0.00|  0.00|  0.00|  0.00
> 
> Seems below patch fix it:

forget the declaration of value :)

---
--- utils/helpers/sysfs-orig.c  2011-03-12 12:32:06.179827929 +0800
+++ utils/helpers/sysfs.c   2011-03-12 12:35:21.512796546 +0800
@@ -111,7 +111,7 @@
 unsigned int idlestate,
 enum idlestate_value which)
 {
-   unsigned long value;
+   unsigned long long value;
unsigned int len;
char linebuf[MAX_LINE_LEN];
char *endp;
@@ -126,7 +126,7 @@
return 0;
}

-   value = strtoul(linebuf, , 0);
+   value = strtoull(linebuf, , 0);

if ( endp == linebuf || errno == ERANGE )
return 0;

[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Yong Zhang]

On Fri, Mar 11, 2011 at 12:46:59PM +0100, Thomas Renninger wrote:
> Happy testing..., if you have a recent machine, you'll like it!
> 
> After some testing phase it would be great to get this tool
> merged into the kernel git repo under:
> tools/power/cpupower
> and replace the Intel HW only supporting tools in tools/power/x86.

I got below output on my laptop:

|Mperf   || Idle_Stats
CPU | C0   | Cx   | Freq || POLL | C1   | C2   | C3   
   0| 36.00| 64.00|   820||1843411670376227.2|1843411670376692.2|  0.00|  0.00
   1| 44.69| 55.31|   920||  0.00|  0.00|  0.00|  0.00

Seems below patch fix it:

Thanks,
Yong

---
--- utils/helpers/sysfs-orig.c  2011-03-12 12:32:06.179827929 +0800
+++ utils/helpers/sysfs.c   2011-03-12 12:24:36.865599924 +0800
@@ -126,7 +126,7 @@
return 0;
}

-   value = strtoul(linebuf, , 0);
+   value = strtoull(linebuf, , 0);

if ( endp == linebuf || errno == ERANGE )
return 0;

[Bug 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #4 from Tom Stellard  2011-03-12 12:10:48 
PST ---
Like Marek said, this isn't a bug it is a hardware limitation.  The only way
this could work is with changes to Gnome Shell, so you should contact the Gnome
Shell developers, although they might tell your hardware is unsupported.

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

[Bug 30750] [r300g] Too many ALU instructions

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

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

--- Comment #6 from Ionut Biru  2011-03-12 11:51:46 
PST ---
(In reply to comment #5)
> (In reply to comment #3)
> > @Tom is the fix available in mesa 7.10.1?
> > 
> > i'm still having this bug when using gnome-shell
> 
> Yes, it's in 7.10.
> 
> Note that this is not a bug, it's a hardware limitation. Sometimes we can
> improve the compiler so that it generates a little less instructions, but that
> only applies to shaders the size of which is very close to the hardware limit.
> Too long shaders are simply NOT supported by hardware. Period.
> 
> Please set the environment variable RADEON_DEBUG=fp and attach the output
> gnome-shell will generate (in a new bug).


thanks for explaining what does that mean. 

bug reported here: https://bugs.freedesktop.org/show_bug.cgi?id=35257

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

[Bug 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

--- Comment #3 from Ionut Biru  2011-03-12 11:49:50 
PST ---
Created an attachment (id=44404)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44404)
log generated using RADEON_DEBUG=fp when using gnome-shell

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

[Bug 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

--- Comment #2 from Tom Stellard  2011-03-12 11:49:08 
PST ---
Can you set the environment variable RADEON_DEBUG=fp and post the
.xsession-errors file?

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

[Bug 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

Tom Stellard  changed:

   What|Removed |Added

  Attachment #44402|application/octet-stream|text/plain
  mime type||

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

[Bug 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

--- Comment #1 from Ionut Biru  2011-03-12 11:25:17 
PST ---
Created an attachment (id=44403)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44403)
preview of the bug

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

[Bug 35257] New: r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

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

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

   Summary: r300_fragprog_emit.c::emit_alu(): Too many ALU
instructions
   Product: Mesa
   Version: 7.10
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: biru.ionut at gmail.com


Created an attachment (id=44402)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44402)
xorg log

when using gnome shell 2.91.91, clicking on Applications, in the location where
the icons should be listed,i have a big black square. Clicking on the other
categories the icons are show normally, only the All category has this problem

.xsession-errors has


r300 FP: Compiler Error:
r300_fragprog_emit.c::emit_alu(): Too many ALU instructions
Using a dummy shader instead.


mesa 7.10.1
clutter 1.6.8

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

[Bug 35249] Noise fails

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #2 from Marek Ol??k  2011-03-12 11:16:41 PST 
---
This is correct. GLSL doesn't require the noise function to return random
values, so it always returns the same constant. There are no plans to implement
the noise differently. I don't think hardware can do it. Closing.

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

[Bug 30750] [r300g] Too many ALU instructions

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

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

--- Comment #5 from Marek Ol??k  2011-03-12 11:11:51 PST 
---
(In reply to comment #3)
> @Tom is the fix available in mesa 7.10.1?
> 
> i'm still having this bug when using gnome-shell

Yes, it's in 7.10.

Note that this is not a bug, it's a hardware limitation. Sometimes we can
improve the compiler so that it generates a little less instructions, but that
only applies to shaders the size of which is very close to the hardware limit.
Too long shaders are simply NOT supported by hardware. Period.

Please set the environment variable RADEON_DEBUG=fp and attach the output
gnome-shell will generate (in a new bug).

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

[Bug 30750] [r300g] Too many ALU instructions

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

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

--- Comment #4 from Tom Stellard  2011-03-12 10:57:12 
PST ---
(In reply to comment #3)
> @Tom is the fix available in mesa 7.10.1?
> 
> i'm still having this bug when using gnome-shell

Can you file a new bug.  This is a different problem.

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

[Bug 35248] Texture lookup in vertex shader broken

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

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

--- Comment #3 from Henri Verbeet  2011-03-12 10:36:02 
PST ---
The r600_shader_from_tgsi() change is wrong, but I've pushed the rest.

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

[Bug 34618] Slow text scrolling on tty after suspend-cycle

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

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

--- Comment #21 from peterle at hottemptation.org 2011-03-12 10:33:04 PST ---
Still occurs with Linux-Kernel 2.6.38-rc8

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

[Bug 35248] Texture lookup in vertex shader broken

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

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

--- Comment #2 from s3734770 at mail.zih.tu-dresden.de 2011-03-12 10:10:24 PST 
---
Created an attachment (id=44399)
 View: https://bugs.freedesktop.org/attachment.cgi?id=44399
 Review: https://bugs.freedesktop.org/review?bug=35248=44399

Patch: also regard vs resources

I found the problem:
077c448d184799e0d9ec962013ec784c6a5c1807 did not pay attention at vs
The fix also adds the resource offset to vs

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

[PATCH 09/10] MCDE: Add build files and bus

[Rob Clark]

On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter  wrote:
> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>> This doesn't seem that different from the graphics chips we support
>> with kms. ?I don't think it would require much work to use KMS. ?One
>> thing we considered, but never ended up implementing was a generic
>> overlay API for KMS. ?Most PC hardware still has overlays, but we
>> don't use them much any more on the desktop side. ?It may be
>> worthwhile to design an appropriate API for them for these type of
>> hardware.
>
> Just fyi about a generic overlay api: I've looked a bit into this when
> doing the intel overlay support and I think adding special overlay crtcs
> that can be attached real crtcs gives a nice clean api. We could the reuse
> the existing framebuffer/pageflipping api to get the buffers to the
> overlay engine.

btw, has there been any further thought/discussion on this topic..
I've been experimenting with a drm driver interface on the OMAP SoC.
It is working well now for framebuffer type usage (mode setting,
virtual framebuffer spanning multiple diplays, and those types of
xrandr things)..  the next step that I've started thinking about is
overlay (or underlay.. the z-order is flexible) support..

I was thinking in a similar direction (ie. a special, or maybe not so
special, sort of crtc) and came across this thread, so I thought I'd
resurrect the topic.

In our case, most of the CRTCs in our driver could be used either with
(A)RGB buffers as a traditional framebuffer, or with a few different
formats of YUV as video under/overlays.  So if you had one display
attached, you might only use one CRTC for traditional GUI/gfx layer,
and the rest are available for video.  If you had two displays, then
you'd steal one of the video CRTCs and use it for the gfx layer on the
second display.  And so on.

Rough thinking:
+ add some 'caps' to the CRTC to indicate whether it can handle YUV,
ARGB, scaling
+ add an x/y offset relative to the encoder (as opposed to the
existing x/y offset relative to the framebuffer)
+ add a z-order parameter

Not sure about intel hw if it is supporting clip-rects.. if so, maybe
need to add something about that.  In our case we jut put the video
behind the gfx layer and use the alpha channel in the gfx framebuffer
to clip/blend rather than using clip-rects.


> The real pain starts when we want format discovery from userspace with all
> the alignement/size/layout constrains. Add in tiling support and its
> almost impossible to do in a generic way. But also for kms userspace needs
> to know these constrains (implemented for generic use in libkms). I favor
> such an approach for overlays, too (if it ever happens) - i.e. a few
> helpers in libkms that allocate an appropriate buffer for a given format
> and size and returns the buffer, strides and offsets for the different
> planes.

hmm, I guess I know about the OMAP display subsystem, and it's overlay
formats/capabilities.. but not enough about other hw to say anything
intelligent here.  But I guess even if we ignore the format of the
data in the buffer, at least the APIs to setup/attach overlay CRTCs at
various positions could maybe be something we can start with as a
first step.  At least standardizing this part seems like a good first
step.  But I'm definitely interested if someone has some ideas.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[Bug 35254] Radeon TTM Crash With E-350 Fusion

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

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

--- Comment #1 from Michael Larabel  2011-03-12 
09:31:25 PST ---
Created an attachment (id=44398)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44398)
dmesg 2

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

[Bug 35254] New: Radeon TTM Crash With E-350 Fusion

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

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

   Summary: Radeon TTM Crash With E-350 Fusion
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: Michael at phoronix.com


Created an attachment (id=44397)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44397)
dmesg 1

Dave & co: Another Fusion problem on my E35M1-M PRO setup... With Git of all
major components as of few days plus the kernel with the Fusion fix talked
about a few days ago, Warsow and Padman at least are crashing on load, 100%
reproducible so far for me (OpenArena though runs fine, haven't tested anything
else yet). Two example dmesg outputs attached, plus one with drm.debug=15.

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

[Bug 35248] Texture lookup in vertex shader broken

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

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

--- Comment #1 from s3734770 at mail.zih.tu-dresden.de 2011-03-12 09:14:52 PST 
---
An additional info: the texture to fetch has float texels and is a luminance
texture.

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

[Bug 35249] Noise fails

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

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

--- Comment #1 from s3734770 at mail.zih.tu-dresden.de 2011-03-12 05:14:37 PST 
---
noise2 also does not work (shows me a gray circle)

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

[Bug 35249] New: Noise fails

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

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

   Summary: Noise fails
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: s3734770 at mail.zih.tu-dresden.de


The mesa-demo src/glsl/noise shows me a brown picture

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

[Bug 35248] New: Texture lookup in vertex shader broken

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

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

   Summary: Texture lookup in vertex shader broken
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: s3734770 at mail.zih.tu-dresden.de


I ran the demo mesa-demos/src/glsl/vert-tex and fetch instructions only return
memory garbage.

The same problem appears when running games via wine where hardware skinned
models are not shown (better: vertices are spread around the whole coordinate
system)

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

[Bug 30750] [r300g] Too many ALU instructions

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

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

--- Comment #3 from Ionut Biru  2011-03-12 04:52:02 
PST ---
@Tom is the fix available in mesa 7.10.1?

i'm still having this bug when using gnome-shell

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

[Bug 30507] [RADEON:KMS:R600C] caster (commercial game) crash

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

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

--- Comment #5 from regnak90 at gmail.com 2011-03-12 03:14:49 PST ---
(In reply to comment #4)
> Does it works with r600g ?

Still segfault with lastest git and classic.
Works with r600g :D

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

[Bug 31776] R300 (Compiz 0.9) crash on resizing windows

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Marek Ol??k  2011-03-12 03:02:50 PST 
---
No feedback for a month and I believe commit
94ccc31ba4f64ac480137fd90f1ded44d2072f6e does fix this bug.

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

[Bug 32688] [RADEON:KMS:R300G] some games have a wireframe or outline visible

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Marek Ol??k  2011-03-12 03:01:34 PST 
---
Commit 6da4866ffdb19315bbb48f6778d1a5297b842a77 fixes it here. Closing.

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

drm/i915: Fix DPMS and suspend interaction for intel_panel.c

[Indan Zupancic]

On Fri, March 11, 2011 18:27, Jesse Barnes wrote:
> On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
> "Indan Zupancic"  wrote:
>
>> drm/i915: Fix DPMS and suspend interaction for intel_panel.c
>>
>> When suspending intel_panel_disable_backlight() is never called,
>> but intel_panel_enable_backlight() is called at resume. With the
>> effect that if the brightness was ever changed after screen
>> blanking, the wrong brightness gets restored at resume time.
>>
>> Nothing guarantees that those calls will be balanced, so having
>> backlight_enabled makes no sense, as the real state can change
>> without the panel code noticing. So keep things as stateless as
>> possible.
>>
>> Signed-off-by: Indan Zupancic 
>
> Chris is right that we don't always control the backlight brightness
> directly, so we'll want a more complete solution at any rate.

Well, not having control basically means not caching any register
values, or as little as possible. For gen >=4 there's the top bit
of BLC_PWM_CTL2, so the brightness handling can be cleanly separated
from the panel disabling/enabling. For older gens we need to save
the brightness and then set it to zero, as happens now.

For brightness control we only need to set the new brightness on
systems with ASLE.

> I don't think this one is urgent enough to send upstream now, and it
> would be good to make a couple of other fixes as well, while you're
> fixing things up. :)  Comments below.

It's not urgent, it's just a bugfix. I did my best to resist the
urge to do other cleanups as well, so close to the release cycle.

[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Thomas Renninger]

> cpupowerutils is based on the well known cpufrequtils project.

Forgot to mention:
Big thanks to Dominik Brodowski who already gave this some tests!

Outcome (heavily shortened):
"You can add that you have my Signed-off-by / Acked-by to all these 
patches"

Thomas

No subject

backlight handling, and it would be sad if it wasn't fixed in 2.6.38.
But I think this is only because I have a gen 2 and the check for
combination mode for gen 2 was added in 2.6.37, everyone else already
had the buggy backlight behaviour for ages. Without the check gen 2
works correctly because the PWM value never changes, only LBPC, and
the driver didn't touch LBPC.

>> -/* i915_suspend.c */
>> -extern int i915_save_state(struct drm_device *dev);
>> -extern int i915_restore_state(struct drm_device *dev);
>> -
>
> Looks like a spurious cleanup hunk, should be a separate hunk (possibly
> along with other save/restore state cleanups, like removing all the
> ILK+ code that probably won't work well :).

Wild guess: ILK+ means Ironlake+?

But indeed, though as the duplicate declaration is in the diff context
it seemed safe enough at the time. ;-)

>> -void intel_panel_setup_backlight(struct drm_device *dev)
>> -{
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>> -
>> -dev_priv->backlight_level = intel_panel_get_backlight(dev);
>> -dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
>>  }
>
> This is getting pretty messy.

That functions was added in the 2.6.38 cycle I think, in an attempt
to fix the backlight problems.

>  Your patch is a step in the right
> direction, but I think we may as well go further:
>   - suspend/resume of backlight state belongs in the backlight class
> driver

There is no backlight suspend/resume handling, the panel just gets
enabled at resume. The registers save/restore is done i915_suspend.c,
where it belongs. The current bugginess is not only for suspend, but
for any two DPMS on calls without a disable in between. Try

xset dpms force off
xset dpms force on
..change brightness..
xset dpms force on

I think you'll get the old brightness.

>   - that driver should call into the registered i915 backlight handler
> if i915 is controlling it natively (PWM native, combo, legacy)

Brightness setting is only needed for ASLE, otherwise it's never set
by the driver. So in the end most complexity is only there because of
one combination: ASLE + legacy combination mode.

>   - we need a backlight driver struct with function pointers for the
> various calls, so we can split out the PCH functions from the rest;
> might be good to separate native, combo, and legacy that way as
> well; even if results in some code duplication it might make each
> easier to read and less likely to break others when we make changes

Problem is, are we sure that systems don't change from legacy combination
mode to BLC_PWM_CTL only? Otherwise you have to check every time.

I must admit I'm not sure what the backlight hierarchy is, but I don't
think the intel_panel.c code has much to do with it: It has nothing to
do with backlight key events and doesn't handle them. All it does is
enabling or disabling the panel for DPMS. The only thing that needs to
set the backlight is intel_opregion.c when ASLE is used, and that bit
should indeed go somewhere else.

So if I'd clean up the code, I think this is what I would try first:

Rip out all brightness control out of intel_panel.c and replace it
with a generic, minimal register saving for disabling the panel, with
all system specific info (which registers to use, masks, etc.) stored
in struct intel_device_info.

All the extra complexity comes from ASLE. As you wrote the Intel ASLE
documentation, I hope you can give some more information about it:

1) First, are there any gen 2 or gen 3 systems with ASLE? If not, there
is no need to handle legacy combination mode for those gens. I think
ASLE came with gen 4, but can you confirm that? Either the gen 2 check
for legacy mode is not needed, or a gen 3 check needs to be added.

2) What happens if the driver doesn't support ASLE? If the BIOS changes
the brightness directly, then we can rip out the whole ASLE thing, as
it's useless. This is probably not possible, so we have to keep the
ASLE madness.

If ASLE needs to set the brightness then we need a way to do that.
But I'd change the interface to a percentage or 0-255 scale, that
fits better with the ASLE thing and the max brightness is hidden.

(I dislike ASLE because it's clear the BIOS knows how to do what it
wants, but bothers the driver with it, which has to do it the same
way as the BIOS, or things stop working.)

And instead of all those almost duplicate functions I'd have one
generic one that works for all, with system specific stuff put in
struct intel_device_info.

i915_read_blc_pwm_ctl() can be greatly simplified by calling
i915_save_state() early and often enough. I don't think you want crash
recovery scattered around the code like that, but done centrally so it's
easier to recover from a hardware crash. I guess saving state just after
driver initialisation and after every modeset is close to enough, but I
have no idea about 3D. My hope is that after a GPU hang, the system can
be restored by resetting the GPU and 

[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Thomas Renninger]

Hi,

cpupowerutils is based on the well known cpufrequtils project.

Where do I find it?
---

A git repository is hosted on gitorious:
git://gitorious.org/cpupowerutils/cpupowerutils.git
Be careful, it's not the default, but the cpupowerutils branch!

You can also directly download a tarball of the cpupowerutils branch:
wget http://gitorious.org/cpupowerutils/cpupowerutils/archive-
tarball/cpupowerutils cpupowerutils.tar.gz

How to make it run
--

You need the pcitutils package (or whatever provides libpci) at runtime
and pcitutils-devel package (or whatever provides /usr/include/pci/pci.h)
at compile time.
Also a gcc version that provides cpuid.h is needed, but it's in there for
some time already afaik.

Don't forget to use the right branch if you use the git repo:
git branch --track cpupowerutils origin/cpupowerutils
git checkout cpupowerutils

make
# There is nothing for choosing lib vs lib64, default is
# /usr/lib,therefore you might need:
libdir=/usr/lib64 make install-lib
ldconfig
./cpupower

There is one known compile warning in get_cpu_topology, it's
on the ToDo list.

Why is there need for another tool?
---

CPU power consumption vs performance tuning is not about
CPU frequency switching anymore for quite some time.
Deep sleep states, traditional dynamic frequency scaling and
hidden turbo/boost frequencies are tight close together and
depend on each other. The first two exist on different architectures
like PPC, Itanium and ARM the latter only on X86.
On X86 the APU (CPU+GPU) will only run most efficiently if CPU
and GPU has proper power management in place.

Users and Developers want to have *one* tool to get an overview what their 
system supports and to monitor and debug CPU power management in detail.

The tool should compile and work on as much architectures as
possible.

What is this tool doing?


It provides all features cpufrequtils does.
It got enhanced with cpuidle and turbo/boost mode (on X86) statistics.
On AMD the exact amount of supported boost states and their frequencies
are shown. On Intel only turbo/boost support is shown.

It got enhanced with a generic HW monitor tool (cpupower monitor).

The generic HW monitor tool is the most powerful enhancement.
It is a framework to monitor kernel or HW power statistics.
It's easy to extend with additional, architecture or processor model
specific counters.
It's based on turbostat which got merged into the kernel recently:
tools/power/x86/turbostat

In fact turbostat functionality is integrated as three separate monitors
implementing the cpupower monitor API:
  - Nehalem
  - SandyBridge
  - Mperf
While Nehalem and SandyBridge HW sleep counters are Intel specific, the
mperf functionality is now available on other HW than Intel, supporting 
the
needed registers (Functionality includes: average frequency including
turbo/boost frequency, C0 vs Cx idle count).

Additionally there is a monitor to collect kernel idle statistics and 
display them (separate or together) in the same format. This works on all 
architectures using the cpuidle kernel framework including different ARM
architectures and there were patches for powerpc (not in the mainline
kernel yet).
This allows to compare kernel and HW statistics on specific workloads and
figure out how the HW performs compared to OS behavior.

Additionally there is an AMD Liano (fam 12h) and Ontario (fam 14h) family 
specific monitor. This one shows different Package Core (!PC0, PC1, PC7)
sleep state statistics directly read out from HW, similar to Nehalem
and SandyBridge coutners.
The registers are accessed via PCI and therefore can still be read out 
while cores have been offlined.
The Liano/Ontario monitor has one special counter: NBP1 (North Bridge P1).
This one always returns 0 or 1, depending on whether the North Bridge P1
power state got entered at least once during measure time.
Being able to enter NBP1 state also depends on graphics power management.
Therefore this counter can be used to verify whether the graphics' driver
power management is working as expected. (E.g. this counter proves that
radeon KMS graphics drivers are missing functionality and NBP1 will only
be entered when using the fglrx driver).


Some examples
-

On a somewhat older Intel machine where turbostat complaints about:
/archteam/trenn/packages/turbostat/turbostat
No invariant TSC

You still get mperf statistics (here core 1 is 100% utilized):
/archteam/trenn/git/latest_cpupowerutils/cpufrequtils/cpupower monitor 
|Mperf   || Idle_Stats
CPU | C0   | Cx   | Freq || POLL | C1   | C2   | C3   
   0|  3.71| 96.29|  2833||  0.00|  0.00|  0.02| 96.32
   1| 100.0| -0.00|  2833||  0.00|  0.00|  0.00|  0.00
   2|  9.06| 90.94|  1983||  0.00|  7.69|  6.98| 76.45
   3|  7.43| 92.57|  2039||  0.00|  2.60| 12.62| 77.52

Hm, mperf (C0 vs Cx) implementation also depends on a correct working
TSC, but shows 

Re: [ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Corentin Chary]

On Fri, Mar 11, 2011 at 11:46 AM, Thomas Renninger tr...@suse.de wrote:
 Why is there need for another tool?
 ---

 CPU power consumption vs performance tuning is not about
 CPU frequency switching anymore for quite some time.
 Deep sleep states, traditional dynamic frequency scaling and
 hidden turbo/boost frequencies are tight close together and
 depend on each other. The first two exist on different architectures
 like PPC, Itanium and ARM the latter only on X86.
 On X86 the APU (CPU+GPU) will only run most efficiently if CPU
 and GPU has proper power management in place.

 Users and Developers want to have *one* tool to get an overview what their
 system supports and to monitor and debug CPU power management in detail.

 The tool should compile and work on as much architectures as
 possible.


Hi Thomas,
Do you think handling really vendor specific boosts like EeePC's SHE
is in cpupower scope ?
Still, it would not solve the issue of setting SHE mode in a standard
way, or associating it with a governor.
Thanks,

-- 
Corentin Chary
http://xf.iksaif.net
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Thomas Renninger]

 cpupowerutils is based on the well known cpufrequtils project.

Forgot to mention:
Big thanks to Dominik Brodowski who already gave this some tests!

Outcome (heavily shortened):
You can add that you have my Signed-off-by / Acked-by to all these 
patches

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

Re: [ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features

[Yong Zhang]

On Fri, Mar 11, 2011 at 12:46:59PM +0100, Thomas Renninger wrote:
 Happy testing..., if you have a recent machine, you'll like it!
 
 After some testing phase it would be great to get this tool
 merged into the kernel git repo under:
 tools/power/cpupower
 and replace the Intel HW only supporting tools in tools/power/x86.

I got below output on my laptop:

|Mperf   || Idle_Stats
CPU | C0   | Cx   | Freq || POLL | C1   | C2   | C3   
   0| 36.00| 64.00|   820||1843411670376227.2|1843411670376692.2|  0.00|  0.00
   1| 44.69| 55.31|   920||  0.00|  0.00|  0.00|  0.00

Seems below patch fix it:

Thanks,
Yong

---
--- utils/helpers/sysfs-orig.c  2011-03-12 12:32:06.179827929 +0800
+++ utils/helpers/sysfs.c   2011-03-12 12:24:36.865599924 +0800
@@ -126,7 +126,7 @@
return 0;
}
 
-   value = strtoul(linebuf, endp, 0);
+   value = strtoull(linebuf, endp, 0);
 
if ( endp == linebuf || errno == ERANGE )
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32688] [RADEON:KMS:R300G] some games have a wireframe or outline visible

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Marek Olšák mar...@gmail.com 2011-03-12 03:01:34 PST ---
Commit 6da4866ffdb19315bbb48f6778d1a5297b842a77 fixes it here. Closing.

-- 
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 30507] [RADEON:KMS:R600C] caster (commercial game) crash

[bugzilla-daemon]

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

--- Comment #5 from regna...@gmail.com 2011-03-12 03:14:49 PST ---
(In reply to comment #4)
 Does it works with r600g ?

Still segfault with lastest git and classic.
Works with r600g :D

-- 
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 30750] [r300g] Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #3 from Ionut Biru biru.io...@gmail.com 2011-03-12 04:52:02 PST 
---
@Tom is the fix available in mesa 7.10.1?

i'm still having this bug when using gnome-shell

-- 
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 35248] New: Texture lookup in vertex shader broken

[bugzilla-daemon]

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

   Summary: Texture lookup in vertex shader broken
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: s3734...@mail.zih.tu-dresden.de


I ran the demo mesa-demos/src/glsl/vert-tex and fetch instructions only return
memory garbage.

The same problem appears when running games via wine where hardware skinned
models are not shown (better: vertices are spread around the whole coordinate
system)

-- 
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 35249] New: Noise fails

[bugzilla-daemon]

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

   Summary: Noise fails
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: s3734...@mail.zih.tu-dresden.de


The mesa-demo src/glsl/noise shows me a brown picture

-- 
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 35249] Noise fails

[bugzilla-daemon]

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

--- Comment #1 from s3734...@mail.zih.tu-dresden.de 2011-03-12 05:14:37 PST ---
noise2 also does not work (shows me a gray circle)

-- 
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 29412] fans running at full-speed after resume from suspend with radeon and KMS

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=29412





--- Comment #2 from Jon Dowland jon+bugzilla.kernel@alcopop.org  
2011-03-12 13:43:17 ---
I did bisect to identify the first bad commit as
17d857be649a21ca90008c6dc425d849fa83db5c , which is merely tagging 2.6.32-rc1. 
I suspect some user space component is only enabling KMS if the kernel version
equals or exceeds this tag and that's why it is only triggered from that
commit.

Can you give me any hints on how to do a more useful bisect? Perhaps limiting
the scope to a particular source path?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/10] MCDE: Add build files and bus

[Rob Clark]

On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
 This doesn't seem that different from the graphics chips we support
 with kms.  I don't think it would require much work to use KMS.  One
 thing we considered, but never ended up implementing was a generic
 overlay API for KMS.  Most PC hardware still has overlays, but we
 don't use them much any more on the desktop side.  It may be
 worthwhile to design an appropriate API for them for these type of
 hardware.

 Just fyi about a generic overlay api: I've looked a bit into this when
 doing the intel overlay support and I think adding special overlay crtcs
 that can be attached real crtcs gives a nice clean api. We could the reuse
 the existing framebuffer/pageflipping api to get the buffers to the
 overlay engine.

btw, has there been any further thought/discussion on this topic..
I've been experimenting with a drm driver interface on the OMAP SoC.
It is working well now for framebuffer type usage (mode setting,
virtual framebuffer spanning multiple diplays, and those types of
xrandr things)..  the next step that I've started thinking about is
overlay (or underlay.. the z-order is flexible) support..

I was thinking in a similar direction (ie. a special, or maybe not so
special, sort of crtc) and came across this thread, so I thought I'd
resurrect the topic.

In our case, most of the CRTCs in our driver could be used either with
(A)RGB buffers as a traditional framebuffer, or with a few different
formats of YUV as video under/overlays.  So if you had one display
attached, you might only use one CRTC for traditional GUI/gfx layer,
and the rest are available for video.  If you had two displays, then
you'd steal one of the video CRTCs and use it for the gfx layer on the
second display.  And so on.

Rough thinking:
+ add some 'caps' to the CRTC to indicate whether it can handle YUV,
ARGB, scaling
+ add an x/y offset relative to the encoder (as opposed to the
existing x/y offset relative to the framebuffer)
+ add a z-order parameter

Not sure about intel hw if it is supporting clip-rects.. if so, maybe
need to add something about that.  In our case we jut put the video
behind the gfx layer and use the alpha channel in the gfx framebuffer
to clip/blend rather than using clip-rects.


 The real pain starts when we want format discovery from userspace with all
 the alignement/size/layout constrains. Add in tiling support and its
 almost impossible to do in a generic way. But also for kms userspace needs
 to know these constrains (implemented for generic use in libkms). I favor
 such an approach for overlays, too (if it ever happens) - i.e. a few
 helpers in libkms that allocate an appropriate buffer for a given format
 and size and returns the buffer, strides and offsets for the different
 planes.

hmm, I guess I know about the OMAP display subsystem, and it's overlay
formats/capabilities.. but not enough about other hw to say anything
intelligent here.  But I guess even if we ignore the format of the
data in the buffer, at least the APIs to setup/attach overlay CRTCs at
various positions could maybe be something we can start with as a
first step.  At least standardizing this part seems like a good first
step.  But I'm definitely interested if someone has some ideas.

BR,
-R

 -Daniel
 --
 Daniel Vetter
 Mail: dan...@ffwll.ch
 Mobile: +41 (0)79 365 57 48
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bug 35248] Texture lookup in vertex shader broken

[bugzilla-daemon]

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

--- Comment #1 from s3734...@mail.zih.tu-dresden.de 2011-03-12 09:14:52 PST ---
An additional info: the texture to fetch has float texels and is a luminance
texture.

-- 
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 35254] New: Radeon TTM Crash With E-350 Fusion

[bugzilla-daemon]

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

   Summary: Radeon TTM Crash With E-350 Fusion
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mich...@phoronix.com


Created an attachment (id=44397)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=44397)
dmesg 1

Dave  co: Another Fusion problem on my E35M1-M PRO setup... With Git of all
major components as of few days plus the kernel with the Fusion fix talked
about a few days ago, Warsow and Padman at least are crashing on load, 100%
reproducible so far for me (OpenArena though runs fine, haven't tested anything
else yet). Two example dmesg outputs attached, plus one with drm.debug=15.

-- 
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 35254] Radeon TTM Crash With E-350 Fusion

[bugzilla-daemon]

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

--- Comment #1 from Michael Larabel mich...@phoronix.com 2011-03-12 09:31:25 
PST ---
Created an attachment (id=44398)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=44398)
dmesg 2

-- 
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 35248] Texture lookup in vertex shader broken

[bugzilla-daemon]

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

--- Comment #2 from s3734...@mail.zih.tu-dresden.de 2011-03-12 10:10:24 PST ---
Created an attachment (id=44399)
 View: https://bugs.freedesktop.org/attachment.cgi?id=44399
 Review: https://bugs.freedesktop.org/review?bug=35248attachment=44399

Patch: also regard vs resources

I found the problem:
077c448d184799e0d9ec962013ec784c6a5c1807 did not pay attention at vs
The fix also adds the resource offset to vs

-- 
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 34618] Slow text scrolling on tty after suspend-cycle

[bugzilla-daemon]

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

--- Comment #21 from pete...@hottemptation.org 2011-03-12 10:33:04 PST ---
Still occurs with Linux-Kernel 2.6.38-rc8

-- 
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 35248] Texture lookup in vertex shader broken

[bugzilla-daemon]

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

--- Comment #3 from Henri Verbeet hverb...@gmail.com 2011-03-12 10:36:02 PST 
---
The r600_shader_from_tgsi() change is wrong, but I've pushed the rest.

-- 
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 30750] [r300g] Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #4 from Tom Stellard tstel...@gmail.com 2011-03-12 10:57:12 PST 
---
(In reply to comment #3)
 @Tom is the fix available in mesa 7.10.1?
 
 i'm still having this bug when using gnome-shell

Can you file a new bug.  This is a different problem.

-- 
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 30750] [r300g] Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #5 from Marek Olšák mar...@gmail.com 2011-03-12 11:11:51 PST ---
(In reply to comment #3)
 @Tom is the fix available in mesa 7.10.1?
 
 i'm still having this bug when using gnome-shell

Yes, it's in 7.10.

Note that this is not a bug, it's a hardware limitation. Sometimes we can
improve the compiler so that it generates a little less instructions, but that
only applies to shaders the size of which is very close to the hardware limit.
Too long shaders are simply NOT supported by hardware. Period.

Please set the environment variable RADEON_DEBUG=fp and attach the output
gnome-shell will generate (in a new bug).

-- 
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 35249] Noise fails

[bugzilla-daemon]

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

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #2 from Marek Olšák mar...@gmail.com 2011-03-12 11:16:41 PST ---
This is correct. GLSL doesn't require the noise function to return random
values, so it always returns the same constant. There are no plans to implement
the noise differently. I don't think hardware can do it. Closing.

-- 
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 35257] New: r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

   Summary: r300_fragprog_emit.c::emit_alu(): Too many ALU
instructions
   Product: Mesa
   Version: 7.10
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: biru.io...@gmail.com


Created an attachment (id=44402)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=44402)
xorg log

when using gnome shell 2.91.91, clicking on Applications, in the location where
the icons should be listed,i have a big black square. Clicking on the other
categories the icons are show normally, only the All category has this problem

.xsession-errors has


r300 FP: Compiler Error:
r300_fragprog_emit.c::emit_alu(): Too many ALU instructions
Using a dummy shader instead.


mesa 7.10.1
clutter 1.6.8

-- 
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 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #1 from Ionut Biru biru.io...@gmail.com 2011-03-12 11:25:17 PST 
---
Created an attachment (id=44403)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=44403)
preview of the bug

-- 
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 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

  Attachment #44402|application/octet-stream|text/plain
  mime type||

-- 
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 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #2 from Tom Stellard tstel...@gmail.com 2011-03-12 11:49:08 PST 
---
Can you set the environment variable RADEON_DEBUG=fp and post the
.xsession-errors file?

-- 
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 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #3 from Ionut Biru biru.io...@gmail.com 2011-03-12 11:49:50 PST 
---
Created an attachment (id=44404)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=44404)
log generated using RADEON_DEBUG=fp when using gnome-shell

-- 
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 30750] [r300g] Too many ALU instructions

[bugzilla-daemon]

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

--- Comment #6 from Ionut Biru biru.io...@gmail.com 2011-03-12 11:51:46 PST 
---
(In reply to comment #5)
 (In reply to comment #3)
  @Tom is the fix available in mesa 7.10.1?
  
  i'm still having this bug when using gnome-shell
 
 Yes, it's in 7.10.
 
 Note that this is not a bug, it's a hardware limitation. Sometimes we can
 improve the compiler so that it generates a little less instructions, but that
 only applies to shaders the size of which is very close to the hardware limit.
 Too long shaders are simply NOT supported by hardware. Period.
 
 Please set the environment variable RADEON_DEBUG=fp and attach the output
 gnome-shell will generate (in a new bug).


thanks for explaining what does that mean. 

bug reported here: https://bugs.freedesktop.org/show_bug.cgi?id=35257

-- 
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 35257] r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

[bugzilla-daemon]

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

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #4 from Tom Stellard tstel...@gmail.com 2011-03-12 12:10:48 PST 
---
Like Marek said, this isn't a bug it is a hardware limitation.  The only way
this could work is with changes to Gnome Shell, so you should contact the Gnome
Shell developers, although they might tell your hardware is unsupported.

-- 
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 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled

[bugzilla-daemon]

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

--- Comment #3 from Álmos aaalmo...@gmail.com 2011-03-12 14:07:12 PST ---
2.6.38-rc8 with the patch seems stable so far.
Doesn't it disable pageflip, though? According to phoronix there should be some
3d performance increase with pageflip, but I haven't noticed any.

-- 
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 33515] System lockup with Page-flipping

[bugzilla-daemon]

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

--- Comment #11 from Marek Olšák mar...@gmail.com 2011-03-12 14:25:53 PST ---
Does this kernel patch help?

https://bugs.freedesktop.org/attachment.cgi?id=44345

-- 
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 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled

[bugzilla-daemon]

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

--- Comment #4 from Dave Airlie airl...@freedesktop.org 2011-03-12 16:04:54 
PST ---
 no it just moves things around to avoid hitting those registers at runtime.

The speed increase you'll see is with fullscreen apps running at less than
vblank frames. You should see more fps or get closer to vblank.

However currently page flip is limited to vblank synced rendering.

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

sent a pull for the first one already, but not sure if you pushed it out,

the second fix is very urgent, it fixes complete system hangs with certain 
older radeon GPUs and pageflipping enabled. Nasty to track down, since 
everything dies hard, when the gpu takes out the PCIE bus.

Dave.

The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6:

  Merge branch 'media_fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 
13:22:10 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Dave Airlie (1):
  drm/radeon: add pageflip hooks for fusion

 drivers/gpu/drm/radeon/radeon_asic.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

(this time after scping the correct file to my mailserver).

 Hi Linus,
 
 sent a pull for the first one already, but not sure if you pushed it out,
 
 the second fix is very urgent, it fixes complete system hangs with certain 
 older radeon GPUs and pageflipping enabled. Nasty to track down, since 
 everything dies hard, when the gpu takes out the PCIE bus.
 
 Dave.

The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6:

  Merge branch 'media_fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 
13:22:10 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Dave Airlie (2):
  drm/radeon: add pageflip hooks for fusion
  drm/radeon: fix page flipping hangs on r300/r400

 drivers/gpu/drm/radeon/r100.c   |   17 -
 drivers/gpu/drm/radeon/radeon_asic.c|3 +++
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |3 ++-
 3 files changed, 5 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel