[Bug 83436] Sudden framerate drops in multiple games

gt; http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html > > > > > > Greetings and happy 'bisecting'...;-) > > > > > > Dieter > > > > So what is the solution for that after one month? Simply to use -O0 maybe > > :) > > Ping Jason Ekstrand, maybe 8-) Ping. -- 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/20140905/e013bfe6/attachment-0001.html>

[Bug 83436] Sudden framerate drops in multiple games

t; ?id=d55f77b503ab7b59ecdd8f31c4f7dc498710e75b > > > > For this look, here: > > > > http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html > > > > Greetings and happy 'bisecting'...;-) > > > > Dieter > > So what is the solution for that after one month? Simply to use -O0 maybe :) Ping Jason Ekstrand, maybe 8-) -- 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/20140905/7e393b0e/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

and happy 'bisecting'...;-) > > Dieter So what is the solution for that after one month? Simply to use -O0 maybe :) -- 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/20140905/bc5a4aaa/attachment.html>

[Bug 81382] Text console blanking does not go away

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/97f440e7/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

For this look, here: http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html Greetings and happy 'bisecting'...;-) Dieter -- 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/20140905/1df3fb46/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/7a876377/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

ists.freedesktop.org/archives/dri-devel/attachments/20140905/899aff3a/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

org/archives/dri-devel/attachments/20140905/a5fc9598/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140905/64c7e6ab/attachment.html>

[Bug 82711] After update to kernel soft lockup (oops) and incomplete boot and shutdown fail

https://bugzilla.kernel.org/show_bug.cgi?id=82711 --- Comment #10 from Mike Cloaked --- The nouveau-dri package in my system was actually updated after I sent this report (actually three days after my last comment), and therefore presumably compiled for the new kernel. [2014-08-21 20:40]

[Bug 83510] Graphical glitches in Unreal Engine 4

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/9ba8a4a3/attachment.html>

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Michel D?nzer writes: > On 30.08.2014 22:59, Mikael Pettersson wrote: > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption > > after a while in X + firefox. This still occurs with yesterday's HEAD > > of Linus' repo. 3.16 and ealier kernels are fine. > > > > I

[Bug 83436] Sudden framerate drops in multiple games

<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/7de9ba42/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/9432b998/attachment.html>

[PATCH -v5 3/4] drm/i915: split intel_cursor_plane_update() into check() and commit()

From: Gustavo Padovan Due to the upcoming atomic modesetting feature we need to separate some update functions into a check step that can fail and a commit step that should, ideally, never fail. The commit part can still fail, but that should be solved in

[PATCH -v4 4/4] drm/i915: split intel_primary_plane_setplane() into check() and commit()

From: Gustavo Padovan As a preparation for atomic updates we need to split the code to check everything we are going to commit first. This patch starts the work to split intel_primary_plane_setplane() into check() and commit() parts. More work is expected on

[PATCH -v4 3/4] drm/i915: split intel_cursor_plane_update() into check() and commit()

From: Gustavo Padovan Due to the upcoming atomic modesetting feature we need to separate some update functions into a check step that can fail and a commit step that should, ideally, never fail. The commit part can still fail, but that should be solved in

[PATCH -v4 2/4] drm/i915: split intel_update_plane into check() and commit()

From: Gustavo Padovan Due to the upcoming atomic modesetting feature we need to separate some update functions into a check step that can fail and a commit step that should, ideally, never fail. This commit splits intel_update_plane() and its commit part can

[PATCH -v4 1/4] drm/i915: create struct intel_plane_state

From: Gustavo Padovan This new struct will be the storage of src and dst coordinates between the check and commit stages of a plane update. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_drv.h | 12 1 file changed, 12 insertions(+)

[PATCH -v4 0/4] split plane's updates functions into check() and commit()

From: Gustavo Padovan This is the beginning of the work to prepare i915 for the upcoming atomic modesetting API. Here we split the plane update fucntions in the check and commit states. v2: use struct intel_plane_state to keep states between check and commit

[PATCH v2] clk: Don't hold prepare_lock across debugfs creation

On 09/04, Stephen Boyd wrote: > > I don't understand why we need to hold the prepare lock around > the kref_put(), so I changed the flow so that we don't do this > when we unregister a clock. Ok we hold the prepare mutex to make sure get and put are serialized. Good. Here's the interdiff to move

[Bug 82711] After update to kernel soft lockup (oops) and incomplete boot and shutdown fail

https://bugzilla.kernel.org/show_bug.cgi?id=82711 EmanueL Czirai changed: What|Removed |Added CC||somelinuxbugs at riseup.net --- Comment

[RFC v2] device coredump: add new device coredump class

On Fri, Sep 05, 2014 at 10:50:54AM +0200, Johannes Berg wrote: > From: Johannes Berg > > Many devices run firmware and/or complex hardware, and most of that > can have bugs. When it misbehaves, however, it is often much harder > to debug than software running on the host. > > Introduce a

[PATCH] drm: Drop modeset locking from crtc init function

At driver init no one can access modeset objects and we're single-threaded. So locking is just cargo-culting here. Worse, with the new ww mutexes and ww mutex slowpath debugging the mutex_lock might actually fail, and we don't have the full-blown ww recovery dance. Which then leads to fireworks

[PATCH RFC v2] vga_switcheroo: restore mux and power states upon resume from hibernation.

On Fri, 31 Jan 2014, Alex Deucher wrote: > On Thu, Jan 30, 2014 at 6:46 PM, Stefan Demharter > wrote: >> Saves the current state of the mux and restores it upon resume from >> hibernation. >> This is needed for muxed systems because the state of the mux doesn't >> survive a >>

[PATCH] drm: use trylock to avoid fault injection antics

On Fri, Sep 05, 2014 at 07:59:45AM -0400, Rob Clark wrote: > While in real life, we could never fail to grab the newly created mutex, > ww_mutex fault injection has no way to know this. Which could result > that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to > acquire the new

[Bug 83436] Sudden framerate drops in multiple games

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/2d35e3ea/attachment-0001.html>

[PATCH] drm/vmwgfx: Fix drm.h include

The userspace drm.h include doesn't prefix the drm directory. This can lead to compile failures as /usr/include/drm/ isn't in the standard gcc include paths. Fix it to be , which matches the rest of the driver drm header files that get installed into /usr/include/drm. Red Hat Bugzilla:

[RFC v2] device coredump: add new device coredump class

On Fri, 2014-09-05 at 11:40 +0200, Jonas Gorski wrote: > On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg > wrote: > > From: Johannes Berg > > Can't you just send from the correct address? ;p Not easily :) > How about the following to avoid negative options: > > config DEV_COREDUMP >

[RFC v2] device coredump: add new device coredump class

On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg wrote: > From: Johannes Berg Can't you just send from the correct address? ;p (snip) > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index 4e7f0ff83ae7..134f763d90fd 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig >

[Bug 83500] si_dma_copy_tile causes GPU hangs

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140905/422c8919/attachment.html>

[RFC v2] device coredump: add new device coredump class

From: Johannes Berg Many devices run firmware and/or complex hardware, and most of that can have bugs. When it misbehaves, however, it is often much harder to debug than software running on the host. Introduce a "device coredump" mechanism to allow dumping internal

[Bug 83500] si_dma_copy_tile causes GPU hangs

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/64f324b5/attachment.html>

[Bug 83500] si_dma_copy_tile causes GPU hangs

, this is the IB we're talking about: http://pastebin.com/jFWk9bU5 -- 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/20140905/bd979

TTM placement & caching issue/questions

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/5e7b13cf/attachment.html>

[Bug 44126] [r300g] 0ad: carpet textures "flash" and get hidden by ground texture.

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/35a0e43c/attachment.html>

X.Org looking for projects and mentors for the Outreach Program for Women

Hi everyone, X.Org will join the Outreach Program for Women (OPW) in Round 9 (December 2014 - March 2015). The OPW is "open to anyone who was assigned female at birth and anyone who identifies as a woman, genderqueer, genderfluid, or genderfree regardless of gender presentation or assigned sex at

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/b22eda4d/attachment.html>

[Bug 83500] si_dma_copy_tile causes GPU hangs

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/e07f52e3/attachment.html>

[Bug 83500] si_dma_copy_tile causes GPU hangs

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/20140905/cc0cf9f0/attachment.html>

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/4862337b/attachment.html>

[PATCH] drm: use trylock to avoid fault injection antics

While in real life, we could never fail to grab the newly created mutex, ww_mutex fault injection has no way to know this. Which could result that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to acquire the new crtc lock. Which results in bad things when the locks are dropped.

[Bug 60553] [trine2] wrong colors when executed fullscreen

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140905/bbfc012b/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

ed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/8bf11e1d/attachment.html>

[Bug 83500] si_dma_copy_tile causes GPU hangs

vel/attachments/20140905/68b36b0a/attachment.html>

[git pull] drm fixes (resend + one patch)

Hi Linus, send one yesterday, it bounced due to LF mail fail (linux-foundation.org), hopefully this one makes it. i915 fixes, a few display regressions vmwgfx, possible loop forever fix nouveau, one userspace interface fix. Dave. The following changes since commit

[PATCH v2] clk: Don't hold prepare_lock across debugfs creation

Rob Clark reports a lockdep splat that involves the prepare_lock chained with the mmap semaphore. == [ INFO: possible circular locking dependency detected ] 3.17.0-rc1-00050-g07a489b #802 Tainted: GW

[PATCH 1/2] clk: Make __clk_lookup() use a list instead of tree search

On 09/04, Stephen Boyd wrote: > In the near future we're going to move the prepare lock to be a > per-clock ww_mutex. __clk_lookup() is called very deep in the > set-rate path and we would like to avoid having to take all the > locks in the clock tree to search for a clock (basically > defeating