[Bug 73911] Color Banding on radeon

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

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

--- Comment #25 from M132  ---
It looks like Catalyst uses some kind of "dynamic" dithering, like NVIDIA's
proprietary drivers, which generates different noise everytime the screen is
refreshed, so isn't really noticeable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/1e5744be/attachment.html>

[Bug 73911] Color Banding on radeon

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

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

--- Comment #24 from Paula Breton  ---
(In reply to comment #23)
> My laptop with A8-4500m is also affected. With fglrx colors are fine, but I
> can see little amount of noise (dithering?). With open source drivers, there
> is no noise.

the noise is definitely dithering, since dithering accomplishes colour blending
using patterns similar to noise. it shouldn't be so noticeable in general use,
but, trying to accomplish smooth gradients with only 1/4 of the colour values
per channel is difficult.

haven't been able to sort this out, catalyst isn't really an acceptable
alternative.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/b2f39171/attachment.html>

[Bug 73911] Color Banding on radeon

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

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

--- Comment #23 from M132  ---
My laptop with A8-4500m is also affected. With fglrx colors are fine, but I can
see little amount of noise (dithering?). With open source drivers, there is no
noise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/a6dd3794/attachment.html>

[Bug 78264] New: the game, the swapper, does crash while initing

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

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

  Priority: medium
Bug ID: 78264
  Assignee: dri-devel at lists.freedesktop.org
   Summary: the game, the swapper, does crash while initing
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: sylvain.bertrand at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

catalyst works fine

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/dadaf40b/attachment.html>

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

newgarry at mail.ru changed:

   What|Removed |Added

 Attachment #135131|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #9 from newgarry at mail.ru ---
Created attachment 135131
  --> https://bugzilla.kernel.org/attachment.cgi?id=135131=edit
kernel log

Kernel log includes suspend-resume info and error messages.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

newgarry at mail.ru changed:

   What|Removed |Added

 CC||newgarry at mail.ru

--- Comment #8 from newgarry at mail.ru ---
I have same dual graphics configuration (Intel graphics and ATI HD 5650) and
also have problems with resume. It takes 40 seconds, and I get following error
messages:

[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing CD0C (len 62,
WS 0, PS 0) @ 0xCD28
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing BA84 (len 937,
WS 4, PS 0) @ 0xBB94
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing BA1A (len 76,
WS 0, PS 8) @ 0xBA22
[drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed

I use 3.14.2 kernel, system init is systemd. The problems began since switching
from 3.12 to 3.13. I use vgaswitcheroo to disable discrete GPU during boot
time. Beginning with 3.13 kernel radeon use runtime power management (runpm),
and I have to pass "runpm=0" to radeon module, because runpm automatically
reenables discrete GPU and brings another problems
(https://bugs.gentoo.org/show_bug.cgi?id=506188).

Without parameter "runpm=0" my system rusumes immediately. Please let me know
if you need additional information. Thank you!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78262] New: [trine2] rendering is wrong

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

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

  Priority: medium
Bug ID: 78262
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [trine2] rendering is wrong
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: sylvain.bertrand at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

The rendering is quite wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/65afea81/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

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

--- Comment #42 from filipp.andjelo at gmail.com ---
I just can't get it running. LLVM + mesa is compiled, but as far as I install
and restart it, my system falls back to swrast and that's all as I said,
I'm not familiar with mesa/llvm development and just don't know what's wrong...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/293eb7c4/attachment.html>

[Bug 32319] Display fades to white screen instead of blanking out in DPMS mode on a Sony Vaio VPCEC3L1E

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

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

Nikolay Amiantov  changed:

   What|Removed |Added

 CC||nikoamia at gmail.com

--- Comment #17 from Nikolay Amiantov  ---
I have the same problem with Samsung R20+ laptop. What info can be useful?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/ded533b4/attachment.html>

[Intel-gfx] [PATCH v2] drm/i915: restore backlight precision when converting from opregion

[Aaron Lu]

On 05/04/2014 03:22 PM, Chris Wilson wrote:
> On Sun, May 04, 2014 at 03:16:05PM +0800, Aaron Lu wrote:
>> On 04/28/2014 09:41 PM, Daniel Vetter wrote:
>>> 64bit divisions won't compile on 32bit. You need one of the DO_DIV macros,
>>> or whatever they're called again. I pain, I know ;-)
>>
>> Thanks for the correction, here is an updated patch :-)
>>
>> From: Aaron Lu 
>> Date: Mon, 28 Apr 2014 11:02:52 +0800
>> Subject: [PATCH v2] drm/i915: restore backlight precision when converting 
>> from
>>  ACPI
>>
>> When we set backlight on behalf of ACPI opregion, we will convert the
>> backlight value in the 0-255 range defined in opregion to the actual
>> hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
>> when doing scale) is meant to fix the overflow problem when doing the
>> conversion, but it also caused a problem that the converted hardware
>> level doesn't quite represent the intended value: say user wants maximum
>> backlight level(255 in opregion's range), then we will calculate the
>> actual hardware level to be: level = freq / max * level, where freq is
>> the hardware's max backlight level(937 on an user's box), and max and
>> level are all 255. The converted value should be 937 but the above
>> calculation will yield 765.
>>
>> To fix this issue, just use 64 bits to do the calculation to keep the
>> precision and avoid overflow at the same time.
>>
>> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
>> Reported-by: Nico Schottelius 
>> Signed-off-by: Aaron Lu 
>> ---
>> v2: use do_div as reminded by Daniel.
>>
>>  drivers/gpu/drm/i915/intel_panel.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index a953b081ee38..8725917a3d0d 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -492,6 +492,7 @@ void intel_panel_set_backlight(struct intel_connector 
>> *connector, u32 level,
>>  enum pipe pipe = intel_get_pipe_from_connector(connector);
>>  u32 freq;
>>  unsigned long flags;
>> +u64 n;
>>  
>>  if (!panel->backlight.present || pipe == INVALID_PIPE)
>>  return;
>> @@ -502,10 +503,9 @@ void intel_panel_set_backlight(struct intel_connector 
>> *connector, u32 level,
>>  
>>  /* scale to hardware max, but be careful to not overflow */
>>  freq = panel->backlight.max;
>> -if (freq < max)
>> -level = level * freq / max;
>> -else
>> -level = freq / max * level;
>> +n = level * freq;
> 
> 32b * 32b = 32b
> 
> n = (u64)level * freq; to avoid overflow as you claim.

Ah...yes, my fault, thanks.

> 
> Also this still has the same rounding error as before.

I didn't get this, care to explain?

[PATCH v2] drm/i915: restore backlight precision when converting from opregion

[Aaron Lu]

On 04/28/2014 09:41 PM, Daniel Vetter wrote:
> 64bit divisions won't compile on 32bit. You need one of the DO_DIV macros,
> or whatever they're called again. I pain, I know ;-)

Thanks for the correction, here is an updated patch :-)

From: Aaron Lu 
Date: Mon, 28 Apr 2014 11:02:52 +0800
Subject: [PATCH v2] drm/i915: restore backlight precision when converting from
 ACPI

When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
Reported-by: Nico Schottelius 
Signed-off-by: Aaron Lu 
---
v2: use do_div as reminded by Daniel.

 drivers/gpu/drm/i915/intel_panel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index a953b081ee38..8725917a3d0d 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -492,6 +492,7 @@ void intel_panel_set_backlight(struct intel_connector 
*connector, u32 level,
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 freq;
unsigned long flags;
+   u64 n;

if (!panel->backlight.present || pipe == INVALID_PIPE)
return;
@@ -502,10 +503,9 @@ void intel_panel_set_backlight(struct intel_connector 
*connector, u32 level,

/* scale to hardware max, but be careful to not overflow */
freq = panel->backlight.max;
-   if (freq < max)
-   level = level * freq / max;
-   else
-   level = freq / max * level;
+   n = level * freq;
+   do_div(n, max);
+   level = n;

panel->backlight.level = level;
if (panel->backlight.device)
-- 
1.9.0

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #86 from adb76 at gmx.de ---
Sorry. Here it is: 

http://sprunge.us/NhCD

Because of the small dmesg log buffer I can't get all of the output from the
second 0. Hope the necessary information is included.

Regards,

Andr?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/fe5a304a/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #85 from Christian K?nig  ---
(In reply to comment #84)
> Since the dmesg log buffer seems very small, I called "dmesg | pastebinit"
> directly afterwards the missed frame counter increased. I made this three
> times:
> 
> http://sprunge.us/gCRU
> http://sprunge.us/EHNG
> http://sprunge.us/MWEY

The dmesg after the missed frame is uninteresting. I need the dmesg of the boot
process with drm.debug=0xE.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/afc11def/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #84 from adb76 at gmx.de ---
Since the dmesg log buffer seems very small, I called "dmesg | pastebinit"
directly afterwards the missed frame counter increased. I made this three
times:

http://sprunge.us/gCRU
http://sprunge.us/EHNG
http://sprunge.us/MWEY

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/63c44ebf/attachment.html>

[Bug 75471] Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

Tasev Nikola  changed:

   What|Removed |Added

 Regression|No  |Yes

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75471] Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

--- Comment #4 from Tasev Nikola  ---
Created attachment 135091
  --> https://bugzilla.kernel.org/attachment.cgi?id=135091=edit
git bisect 3.15-rc3 3.15-rc2 log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75471] Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

--- Comment #3 from Tasev Nikola  ---
Oop's

Ignore my first post, i must made a copy paste error somewhere !

The first bad commit is indeed this one :

c2fb3094669a3205f16a32f4119d0afe40b1a1fd is the first bad commit
commit c2fb3094669a3205f16a32f4119d0afe40b1a1fd
Author: Christian K?nig 
Date:   Sun Apr 20 13:24:32 2014 +0200

drm/radeon: improve PLL limit handling in post div calculation

This improves the PLL parameters when we work at
the limits of the allowed ranges.

Signed-off-by: Christian K?nig 


I just revert the commit, rebuild and is working fine again now.

Sorry for my first report.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75471] Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

Christian K?nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #2 from Christian K?nig  ---
That's a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=75241

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75471] Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

--- Comment #1 from Tasev Nikola  ---
Created attachment 135081
  --> https://bugzilla.kernel.org/attachment.cgi?id=135081=edit
dmesg working 3.15-rc2 kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75471] New: Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880

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

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

Bug ID: 75471
   Summary: Black screen with frequency out of range with kernel
3.15-rc3 on radeon RS880
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc3
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: tasev.stefanoska at skynet.be
Regression: No

Created attachment 135071
  --> https://bugzilla.kernel.org/attachment.cgi?id=135071=edit
dmesg broken 3.15-rc3 kernel

I just have a black screen with frequency out of range on the monitor with the
kernel 3.15-rc3.The system boot normaly but after 3 seconds wen it should
display the splash screen comme the frequency out of range on the monitor, but
the boot process continue in the dark as normal and the system is responsive.
Everything work fine in 3.15-rc1 and rc2 kernels.

I'm running Kubuntu 12.04 Precise.
I have a RS880 motherboard with :

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880
[Radeon HD 4200].

After bisecting the first bad commit found :

first bad commit 24315814239a3fdb306244c99bd076bc79db4ade

Auteur: Christian K?nig   2014-04-19 18:57:14
Auteur du commit: Christian K?nig   2014-04-19
18:57:14
Parent: 76e6dcece841faebbee78895780e8209ff40d922 (drm/radeon: disable dpm on
rv770 by default)
Branche: master, remotes/origin/master
Suit: v3.15-rc1
Pr?c?de: v3.15-rc3

drm/radeon: use fixed PPL ref divider if needed

Signed-off-by: Christian K?nig 

--- drivers/gpu/drm/radeon/radeon_display.c ---
index 2f7cbb9..e6c3c54 100644
@@ -880,7 +880,12 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 ref_div_min = pll->reference_div;
 else
 ref_div_min = pll->min_ref_div;
-ref_div_max = pll->max_ref_div;
+
+if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV &&
+pll->flags & RADEON_PLL_USE_REF_DIV)
+ref_div_max = pll->reference_div;
+else
+ref_div_max = pll->max_ref_div;

 /* determine allowed post divider range */
 if (pll->flags & RADEON_PLL_USE_POST_DIV) {


But sadly reverting the patch and rebuild the kernel doesn't fix the issue.

Attached are dmesg with drm_debug=0xe for the 3.15rc3 (broken) and 3.15-rc2 
kernels, and also the bisect.log.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

creich  changed:

   What|Removed |Added

 CC||creich at linux.com

--- Comment #38 from creich  ---
had the same issue over here. switched over to 3.14.2 which fixed the problem
for me.

maybe that's an option for you :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [PATCH v2] drm/i915: restore backlight precision when converting from opregion

[Chris Wilson]

On Sun, May 04, 2014 at 03:31:01PM +0800, Aaron Lu wrote:
> On 05/04/2014 03:22 PM, Chris Wilson wrote:
> > Also this still has the same rounding error as before.
> 
> I didn't get this, care to explain?

The calculation you use, truncates, rather than say round to nearest,
would is the same discrepancy in your changelog.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #83 from Christian K?nig  ---
(In reply to comment #79)
> Created attachment 98406 [details]
> adb76 dmesg output

Please provide a dmesg output generated with drm.debug=0xE.

Thanks,
Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/cd469cae/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

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

--- Comment #41 from filipp.andjelo at gmail.com ---
Hi Damian,

unfortunately, I didn't have enough time to build appropriate packages. I built
patched LLVM manually and modified mesa package from Arch repository to use my
LLVM. Nevertheless, it doesn't work yet as expected. I need more time to figure
out, what went wrong... when I'm done, I will probably be able to supply
PKGBUILD for you...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/bfad7c0f/attachment.html>

[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)

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

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/ddd1aa9c/attachment.html>

[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)

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

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

--- Comment #1 from Laurent carlier  ---
rm
/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1

should fix the problem. It's a steam bug, not a mesa one

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/5a136bba/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

adb76 at gmx.de changed:

   What|Removed |Added

  Attachment #98409|adb76 xbmc-xrandr ouput |adb76 xbmc-xrandr output
description||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/96cd9b84/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #82 from adb76 at gmx.de ---
Created attachment 98409
  --> https://bugs.freedesktop.org/attachment.cgi?id=98409=edit
adb76 xbmc-xrandr ouput

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/75660c85/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #81 from adb76 at gmx.de ---
Created attachment 98408
  --> https://bugs.freedesktop.org/attachment.cgi?id=98408=edit
adb76 xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/9b71f366/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #80 from adb76 at gmx.de ---
Created attachment 98407
  --> https://bugs.freedesktop.org/attachment.cgi?id=98407=edit
adb76 lspci output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/cf0191a2/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #79 from adb76 at gmx.de ---
Created attachment 98406
  --> https://bugs.freedesktop.org/attachment.cgi?id=98406=edit
adb76 dmesg output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/8da18480/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

adb76 at gmx.de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #78 from adb76 at gmx.de ---
I've tested the attached patch, which is now included in OpenELEC 4.0 Beta 7 on
my AMD Fusion E-350 with Radeon HD 6310 system (see adb76_lspci.txt). There
seems to be still a problem with which I was alread in contact with Peter
Fr?hberger (fritsch) on the github site for OpenELEC:
https://github.com/OpenELEC/OpenELEC.tv/issues/3163 . Peter asked me to attach
my information to this bug:

The problem is that when I watch videos with XBMC on OpenELEC 4.0 Beta 7 the
"missed frames" counter (not the skipped frames counter!) increases constantly
during playback. In around 45 minutes there are approximately 30 "missed
frames". The missed frames are recognisable, so when I see a stuttering I look
afterwards on the OSD of XBMC and the missed frame counter increased by +1 or
+2. I previously had installed OpenELEC 3.2 where I didn't get any missed
frames during the full playback. The assumption of Peter is that "the driver
did not do swaps".

My TV is displaying the framerate of all the tested videos natively:
1920x1080 at 25fps and 1280x720 at 25fps. See also the attached file 
adb76_xrandr.txt
for the display properties.

On XBMC side I have set the following preferences (according to the suggestions
of Peter): 

Enable Adjust Refreshrate to match video (On Start / Stop)
Enable Sync Playback to Display Method Video Clock (Drop / Dupe)
Deinterlace: Auto 
Deinterlace Method: Bob
Scaling: Bilinear
Vertical Blank Setting: Let Driver Decide
Enalbe HQ Scaler: above 20%

I have attached multiple logs from my system (adb76_*). Which further
informations are required to narrow down the problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/15592798/attachment.html>

[Intel-gfx] [PATCH v2] drm/i915: restore backlight precision when converting from opregion

[Chris Wilson]

On Sun, May 04, 2014 at 03:16:05PM +0800, Aaron Lu wrote:
> On 04/28/2014 09:41 PM, Daniel Vetter wrote:
> > 64bit divisions won't compile on 32bit. You need one of the DO_DIV macros,
> > or whatever they're called again. I pain, I know ;-)
> 
> Thanks for the correction, here is an updated patch :-)
> 
> From: Aaron Lu 
> Date: Mon, 28 Apr 2014 11:02:52 +0800
> Subject: [PATCH v2] drm/i915: restore backlight precision when converting from
>  ACPI
> 
> When we set backlight on behalf of ACPI opregion, we will convert the
> backlight value in the 0-255 range defined in opregion to the actual
> hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
> when doing scale) is meant to fix the overflow problem when doing the
> conversion, but it also caused a problem that the converted hardware
> level doesn't quite represent the intended value: say user wants maximum
> backlight level(255 in opregion's range), then we will calculate the
> actual hardware level to be: level = freq / max * level, where freq is
> the hardware's max backlight level(937 on an user's box), and max and
> level are all 255. The converted value should be 937 but the above
> calculation will yield 765.
> 
> To fix this issue, just use 64 bits to do the calculation to keep the
> precision and avoid overflow at the same time.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
> Reported-by: Nico Schottelius 
> Signed-off-by: Aaron Lu 
> ---
> v2: use do_div as reminded by Daniel.
> 
>  drivers/gpu/drm/i915/intel_panel.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index a953b081ee38..8725917a3d0d 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -492,6 +492,7 @@ void intel_panel_set_backlight(struct intel_connector 
> *connector, u32 level,
>   enum pipe pipe = intel_get_pipe_from_connector(connector);
>   u32 freq;
>   unsigned long flags;
> + u64 n;
>  
>   if (!panel->backlight.present || pipe == INVALID_PIPE)
>   return;
> @@ -502,10 +503,9 @@ void intel_panel_set_backlight(struct intel_connector 
> *connector, u32 level,
>  
>   /* scale to hardware max, but be careful to not overflow */
>   freq = panel->backlight.max;
> - if (freq < max)
> - level = level * freq / max;
> - else
> - level = freq / max * level;
> + n = level * freq;

32b * 32b = 32b

n = (u64)level * freq; to avoid overflow as you claim.

Also this still has the same rounding error as before.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 78242] New: Steam cannot load mesa drivers (libGL error: driver pointer missing)

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

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

  Priority: medium
Bug ID: 78242
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Steam cannot load mesa drivers (libGL error: driver
pointer missing)
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: laszlo.kertesz at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

I rebuilt mesa recently (on Debian Testing 64 bit) an i see that Steam is
broken again. I get this in a terminal (accompanied by a graphical popup saying
"OpenGL GLX context is not using direct rendering, which may cause performance
problems.") :

Running Steam on debian  64-bit
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for
appid(steam)/version(1398120891_client)
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/r600_dri.so failed
(/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1:
version `GCC_4.7.0' not found (required by
/usr/lib/i386-linux-gnu/dri/r600_dri.so))
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed
(/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1:
version `GCC_4.7.0' not found (required by
/usr/lib/i386-linux-gnu/dri/swrast_dri.so))
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

Then other Steam specific stuff.
The Steam GUI launches but cannot launch anything.

Now i dont know what is the issue here since i built Mesa this way since a very
long time ago, with my current (gcc 4.8) compiler and had no such issues.

strings
/media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1
| grep GCC_4
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.4.0
GCC_4.5.0

Other 64 and 32 bit opengl games seems to work fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/ce35f4c5/attachment-0001.html>

[Bug 75401] vgaswitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class)

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

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

drill87 at gmail.com changed:

   What|Removed |Added

Summary|vgaswtitcheroo doesn't work |vgaswitcheroo doesn't work
   |for AMD Radeon 8870m|for AMD Radeon 8870m
   |(possibly due to "wrong"|(possibly due to "wrong"
   |PCI class)  |PCI class)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78238] GPU lockup on opening new tab in Chromium

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

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

--- Comment #1 from russianneuromancer at ya.ru ---
Created attachment 98396
  --> https://bugs.freedesktop.org/attachment.cgi?id=98396=edit
Xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/8e4915e0/attachment.html>

[Bug 78238] New: GPU lockup on opening new tab in Chromium

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

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

  Priority: medium
Bug ID: 78238
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU lockup on opening new tab in Chromium
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: russianneuromancer at ya.ru
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 98395
  --> https://bugs.freedesktop.org/attachment.cgi?id=98395=edit
dmesg

If GPU blacklist is disabled in Chromium (on chrome://flags; so hardware
accelerated rendering become enabled, judging from chrome://gpu) GPU sometimes
lockup on just opening new tab (at least one time per day). After lockup I
observe same behaviour like in Bug 77892 - reset happens but X is unresponsive
except mouse.

Radeon HD 6620G, Kubuntu 14.04 x86_64, Linux 3.15rc3, X.Org Server 1.15.1,
libdrm 2.4.54+git1405030630.5126fc, Mesa 10.3~git1405030730.64c467, radeon
driver 7.3.99+git1405030730.be1469.

As I remember, this behaviour (GPU hang on opening new tab) introduced since
Linux 3.15.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/876fcbfd/attachment.html>

[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps

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

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

m.a.riosv  changed:

   What|Removed |Added

 CC||kabull3 at vodafone.co.nz

--- Comment #22 from m.a.riosv  ---
*** Bug 78235 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140504/64f954a7/attachment.html>