[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel

https://bugs.freedesktop.org/show_bug.cgi?id=99488 --- Comment #16 from nixscrip...@gmail.com --- Good news! I tried a new version: LLVM r302002 Mesa commit 3bf3f9866c And the unit tests on the ImageMagick master branch don't hang anymore! A little more testing today, and I may be able to

Re: [git pull] drm pull for v4.12

On Tue, May 2, 2017 at 8:44 PM, Dave Airlie wrote: > > i915: > vblank evasion improvements These may be "improvements", but they end up being very noisy. I geta fair amount of messages like [drm] Atomic update on pipe (A) took 161 us, max time under evasion is 100 us on

[Bug 100941] Improve time to suspend on Radeon HD 6310

https://bugs.freedesktop.org/show_bug.cgi?id=100941 --- Comment #3 from Paul Menzel --- (In reply to Christian König from comment #2) > That is expected. During suspend we need to backup VRAM and that can be > multiple gigs of memory. The board has the Fusion

[Bug 100941] Improve time to suspend on Radeon HD 6310

https://bugs.freedesktop.org/show_bug.cgi?id=100941 Christian König changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 100941] Improve time to suspend on Radeon HD 6310

https://bugs.freedesktop.org/show_bug.cgi?id=100941 Paul Menzel changed: What|Removed |Added Summary|Improve time to suspend on

[Bug 100577] DC + TearFree display lock

https://bugs.freedesktop.org/show_bug.cgi?id=100577 --- Comment #4 from Nikola Forró --- Bisected to this commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.9=afbeb2d0961b2139bcf6553a710e6a8ae5d09d34 Which makes me think I'm experiencing a

Re: GPU-DRM-STI: Fine-tuning for some function implementations

>> 1. I suggest to combine a few functions into fewer ones. >>* Do you spot any programming mistakes in these concrete cases? > > Not in the patches I skimmed. Thanks for such feedback. > However, your history of breaking code tells me that there have been mistakes > missed in the past. I

Re: GPU-DRM-STI: Fine-tuning for some function implementations

On Sat, May 06, 2017 at 03:54:51PM +0200, SF Markus Elfring wrote: > > Generally speaking, I don't care about checkpatch/cocci changes that aren't > > tested. > > I find this view interesting only to some degree. We're bordering on becoming unproductive here, but I'll try once more. > > 1. I

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

Mario Kleiner writes: > Just please make sure that one (user configurable/opt-in if necessary) > policy from the beginning is to allow leasing out any output to > applications, not just HMDs. That's entirely a given -- the leasing API is under the control of the

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #8 from Samuel Pitoiset --- Thanks for the trace. The issue can be reproduced with mesa/llvm from today on RX480. I'm investigating. -- You are receiving this mail because: You are the assignee for the

Re: GPU-DRM-STI: Fine-tuning for some function implementations

> Generally speaking, I don't care about checkpatch/cocci changes that aren't > tested. I find this view interesting only to some degree. 1. I suggest to combine a few functions into fewer ones. * Do you spot any programming mistakes in these concrete cases? * Can such code reduction

Re: GPU-DRM-STI: Fine-tuning for some function implementations

On Fri, May 05, 2017 at 05:04:40PM +0200, SF Markus Elfring wrote: > > It seems like you're back to submitting cocci patches again :) > > My contribution activities are varying also for Linux software over time. > ;-) > > The corresponding source code search patterns get different popularity.

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

Hi Tomi, I did some more testing, and I discovered a bug in this code, but I am not sure how to solve it. On 04/14/2017 12:25 PM, Hans Verkuil wrote: > From: Hans Verkuil > > Hook up the HDMI CEC support in the hdmi4 driver. > > It add the CEC irq handler, the CEC

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

On 05/05/2017 04:25 PM, Keith Packard wrote: Pekka Paalanen writes: I disagree on the details, more below. Such a RandR request is something I would not like to have to replicate on Wayland. The display server contains the policy, it should not just expose everything

I2C failures with recent laptops and docking stations

The following bug was just posted: i915 failures with recent chips and docking stations and follows up this thread in the intel-gfx mailing list. Per suggestion of Jani