[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

[bugzilla-daemon]

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

--- Comment #16 from Adam Bolte  ---
Confirming, it works now - provided I set the MESA_GL_VERSION_OVERRIDE first.
Failure to set this causes a blank screen (but audio can be heard from the
intro video).

The following game launch option can be set in Steam:
MESA_GL_VERSION_OVERRIDE=4.1 %command%

4.1 is the minimum that works and does not throw the warning box (shown in
Jan's attached image). Setting the override to 3.3 also gets the game to run (I
didn't bother testing any lower than that), but with the warning.

The game still runs too slow to be enjoyable - it's borderline unplayable. I
was never able to hit 30 FPS (quite bad for this type of game), but at least
it's running.

Having said that, using MESA_GL_VERSION_OVERRIDE=4.5 seems to give me a few
extra in-game FPS. My overclocked i7-6700k and Fury X at 2560x1440 with high
detail settings and maximum draw depth (but no AA and motion blur) was giving
me on average around 26 FPS in the camp where I restored my save point from
(running back and forth), whereas I was never able to get past 23 FPS in the
same area by setting the override to 4.1. I tested that twice to be sure.

Would be great if there were a way to take care of these overrides
automatically in drirc - which is what this bug was originally about. Are we
certain this is still WONTFIX?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load

[bugzilla-daemon]

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

--- Comment #16 from Adam Bolte  ---
Looks like this patch has found its way into 4.12-rc1. Thanks again Alex.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: remove NULL pointer check for clk_disable_unprepare

[Rob Clark]

On Sat, May 20, 2017 at 3:04 PM, Masahiro Yamada
 wrote:
> 2017-05-21 2:58 GMT+09:00 Masahiro Yamada :
>> After long term efforts of fixing non-common clock implementations,
>> clk_disable() is a no-op for a NULL pointer input, and this is now
>> tree-wide consistent.
>>
>> All clock consumers can safely call clk_disable(_unprepare) without
>> NULL pointer check.
>>
>> Signed-off-by: Masahiro Yamada 
>
>
> Sorry, I retract this patch.
>
> Krzysztof pointed out
> cleanups only for clk_disable_unprepare() will lose the code symmetry.
>
> NULL pointer checks for clk_prepare_enable() should be
> removed to keep the code symmetrical.
>
> This is possible for common-clock framework because
> clk_prepare_enable() is also a no-op for a NULL clk input.
> But it is not necessarily true for non-common clock implementations.

At least for drm/msm, upstream I think we can assume CCF.. I still
need to check for possible downstream kernels to which someone might
want to backport drm/msm.

It might be an idea to split this up per-driver, since at least for
some drivers it might be safe to assume CCF (or non-CCF clk driver
that behaves the same)

BR,
-R

>
> --
> Best Regards
> Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #153 from garththei...@hotmail.com ---
I too have toggled my TPD switch (XFX R9 390) and continue to get black screen
freeze at non-deterministic times with a non-stressful workload. Running 4.11.1
with the latest git firmware (radeon).

My work-around is to set the power_dpm_force_performance_level and the black
screen behaviour is mitigated.

Let me know if I might assist in any way collecting logs etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1

[bugzilla-daemon]

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

--- Comment #19 from Adam Bolte  ---
Updated to a stable Linux 4.11.0 kernel, with the LED patch that's still not
upstream (from https://bugs.freedesktop.org/show_bug.cgi?id=97590). Says
"Tainted" due to using the vhba (Virtual SCSI HBA, built via dkms) kernel
module from the CDEmu project. All config options are typical - built using
`make olddefconfig` on an up to date Debian Stretch install.

[0.00] Linux version 4.11.0+ (root@dragon) (gcc version 6.3.0 20170425
(Debian 6.3.0-16) ) #2 SMP Thu May 18 22:40:08 AEST 2017
[28034.309104] INFO: task Xorg:1278 blocked for more than 120 seconds.
[28034.309106]   Tainted: G   OE   4.11.0+ #2
[28034.309107] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[28034.309107] XorgD0  1278   1239 0x0004
[28034.309108] Call Trace:
[28034.309111]  ? __schedule+0x3c2/0x8b0
[28034.309112]  ? __kfifo_in+0x2d/0x40
[28034.309113]  ? schedule+0x32/0x80
[28034.309124]  ? amd_sched_entity_push_job+0xb9/0x100 [amdgpu]
[28034.309125]  ? remove_wait_queue+0x60/0x60
[28034.309133]  ? amdgpu_job_submit+0x6e/0x90 [amdgpu]
[28034.309140]  ? amdgpu_vm_bo_split_mapping+0x510/0x6f0 [amdgpu]
[28034.309146]  ? amdgpu_vm_do_copy_ptes+0x90/0x90 [amdgpu]
[28034.309152]  ? amdgpu_vm_clear_freed+0x75/0xb0 [amdgpu]
[28034.309158]  ? amdgpu_gem_va_ioctl+0x3a6/0x400 [amdgpu]
[28034.309159]  ? __radix_tree_delete+0x30/0xa0
[28034.309160]  ? __check_object_size+0xfb/0x196
[28034.309164]  ? drm_ioctl+0x1ef/0x440 [drm]
[28034.309167]  ? drm_ioctl+0x1ef/0x440 [drm]
[28034.309173]  ? amdgpu_gem_metadata_ioctl+0x1c0/0x1c0 [amdgpu]
[28034.309174]  ? unmap_region+0xd9/0x120
[28034.309178]  ? amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[28034.309179]  ? do_vfs_ioctl+0x9f/0x600
[28034.309180]  ? do_munmap+0x356/0x470
[28034.309181]  ? SyS_ioctl+0x74/0x80
[28034.309181]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
[28155.142288] INFO: task Xorg:1278 blocked for more than 120 seconds.
[28155.142290]   Tainted: G   OE   4.11.0+ #2
[28155.142290] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[28155.142291] XorgD0  1278   1239 0x0004
[28155.142292] Call Trace:
[28155.142295]  ? __schedule+0x3c2/0x8b0
[28155.142296]  ? __kfifo_in+0x2d/0x40
[28155.142297]  ? schedule+0x32/0x80
[28155.142308]  ? amd_sched_entity_push_job+0xb9/0x100 [amdgpu]
[28155.142309]  ? remove_wait_queue+0x60/0x60
[28155.142317]  ? amdgpu_job_submit+0x6e/0x90 [amdgpu]
[28155.142324]  ? amdgpu_vm_bo_split_mapping+0x510/0x6f0 [amdgpu]
[28155.142330]  ? amdgpu_vm_do_copy_ptes+0x90/0x90 [amdgpu]
[28155.142336]  ? amdgpu_vm_clear_freed+0x75/0xb0 [amdgpu]
[28155.142342]  ? amdgpu_gem_va_ioctl+0x3a6/0x400 [amdgpu]
[28155.142343]  ? __radix_tree_delete+0x30/0xa0
[28155.142344]  ? __check_object_size+0xfb/0x196
[28155.142349]  ? drm_ioctl+0x1ef/0x440 [drm]
[28155.142352]  ? drm_ioctl+0x1ef/0x440 [drm]
[28155.142357]  ? amdgpu_gem_metadata_ioctl+0x1c0/0x1c0 [amdgpu]
[28155.142359]  ? unmap_region+0xd9/0x120
[28155.142363]  ? amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[28155.142364]  ? do_vfs_ioctl+0x9f/0x600
[28155.142365]  ? do_munmap+0x356/0x470
[28155.142366]  ? SyS_ioctl+0x74/0x80
[28155.142366]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
(END)

This happened while playing The Darkness II (a d3d9 game) under a patched (for
Darkness II compatibility - https://bugs.winehq.org/attachment.cgi?id=54454)
Wine 2.8. This was *not* using Gallium on Nine. The screen froze up (I couldn't
alt-tab or switch virtual desktops) so I had to SSH in from a laptop to power
off safely.

Device: AMD FIJI (DRM 3.10.0 / 4.11.0+, LLVM 4.0.1) (0x7300)
Version: 17.2.0
OpenGL renderer string: Gallium 0.4 on AMD FIJI (DRM 3.10.0 / 4.11.0+, LLVM
4.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-devel
(git-3db35a8bb9)
OpenGL core profile shading language version string: 4.50

Happened while running Mesa master (currently
f347bac30f4045a9583f95a5776484b1a2947183, Thu May 18 10:21:59 2017 +0300), with
the Dying Light patch set from
https://lists.freedesktop.org/archives/mesa-dev/2017-May/155428.html on top.

I only observed a crash just the one time during the entire ~6h play-through.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

[bugzilla-daemon]

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

--- Comment #15 from Samuel Pitoiset  ---
The following commit should fix Dying Light:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=2b878cb8fdb99dd84602553c2e95ef47747f4529

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #9 from Francesco Turco  ---
I have upgraded media-libs/mesa from 17.1.0_rc4 to 17.1.0.

After running "eselect mesa set i915 2" (gallium) both qupzilla and mpv crash.
After running "eselect mesa set i915 1" (classic) both qupzilla and mpv run
successfully.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

[Christian König]

Am 20.05.2017 um 01:48 schrieb Lyude:

This is the first part of me going through and cleaning up the IRQ handling
code for radeon, since after taking a look at it the other day while trying to
debug something I realized basically all of the code was copy pasted
everywhere, and quite difficult to actually read through.

Will come up with something for r600 and cik once I've got the chipsets on hand
to test with.

Lyude (3):
   drm/radeon: Cleanup display interrupt handling for evergreen, si
   drm/radeon: Cleanup HDMI audio interrupt handling for evergreen
   drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si


I don't have time to do a line by line review, but what I saw looked 
very good to me.


So the whole seres is Acked-by: Christian König .

BTW: You don't want to take a look at the other hw generations as well?

Regards,
Christian.



  drivers/gpu/drm/radeon/evergreen.c  | 943 ++--
  drivers/gpu/drm/radeon/radeon.h |  27 +-
  drivers/gpu/drm/radeon/radeon_irq_kms.c |  35 ++
  drivers/gpu/drm/radeon/si.c | 655 +-
  4 files changed, 344 insertions(+), 1316 deletions(-)



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