[Bug 82667] "Distance" game closed alpha: Changing shadow settings segfaults

e for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/0bba279b/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

to default, not sure what of these make is work normal :) -- 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/20140904/af930

ccf vs iommu vs drm locking fun

So, I was looking at the below lockdep splat, and discussing it a bit w/ sboyd on IRC, and came to a slightly disturbing realization.. The interaction between prepare_lock and debugfs bits is a little bit worrying. In particular, it is probably not a good idea to assume that anyone who needs to

[Bug 81644] Random crashes on RadeonSI with Chromium.

don't have so many other things going on I'll bisect it over a week or so. -- 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/20140

[PATCH 3/3] drm/radeon: allow concurrent buffer reads

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index ec4840c..f662de4 100644

[PATCH 2/3] drm/radeon: add the infrastructure for concurrent buffer access

From: Christian K?nig This allows us to specify if we want to sync to the shared fences of a reservation object or not. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik.c | 25 ++- drivers/gpu/drm/radeon/cik_sdma.c | 25

[PATCH 1/3] drm/ttm: allow fence to be added as shared

From: Christian K?nig This patch adds a new flag to the ttm_validate_buffer list to add the fence as shared to the reservation object. Signed-off-by: Christian K?nig --- drivers/gpu/drm/qxl/qxl_release.c| 1 + drivers/gpu/drm/radeon/radeon_cs.c | 1 +

[Bug 83510] Graphical glitches in Unreal Engine 4

h?v=3AAf_2vry8A -- 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/20140904/262af647/attachment-0001.html>

[Bug 83510] Graphical glitches in Unreal Engine 4

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/abf5ce60/attachment.html>

[Bug 83510] Graphical glitches in Unreal Engine 4

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/bbe93ee6/attachment.html>

[Bug 83510] Graphical glitches in Unreal Engine 4

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/1ecd54ce/attachment.html>

[Bug 83510] New: Graphical glitches in Unreal Engine 4

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

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote: > On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote: > > Last time I tested, (and it seems like Michel is on the same track), > > writing with the CPU to write-combined memory was substantially faster > > than writing to cached

[PATCH 9/9] drm/ttm: Sanity check mapping attributes on powerpc in ttm_io_prot()

On Thu, 2014-09-04 at 16:52 +0900, Michel D?nzer wrote: > > #endif > > +#if defined(__powerpc__) && !defined(CONFIG_NOT_COHERENT_CACHE) > > + /* > > + * Using a non-cachable mapping of system memory on > > + * cache coherent powerpc's can be fatal, let's make > > + * sure this

[Bug 83436] Sudden framerate drops in multiple games

fferent code to be generated ? -- 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/20140904/d439c493/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

L attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/07e398d8/attachment.html>

[PATCH 9/9] drm/ttm: Sanity check mapping attributes on powerpc in ttm_io_prot()

On 04.09.2014 18:34, Benjamin Herrenschmidt wrote: > On Thu, 2014-09-04 at 16:52 +0900, Michel D?nzer wrote: >>>#endif >>> +#if defined(__powerpc__) && !defined(CONFIG_NOT_COHERENT_CACHE) >>> + /* >>> + * Using a non-cachable mapping of system memory on >>> + * cache coherent

[Bug 83861] radeon power management cause audio skips and glitch

https://bugzilla.kernel.org/show_bug.cgi?id=83861 Rafael J. Wysocki changed: What|Removed |Added Component|Other |Video(DRI - non Intel)

[Bug 83436] Sudden framerate drops in multiple games

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

[Bug 83436] Sudden framerate drops in multiple games

old behavior, on 32bit it is unusable produce much corruption. -- 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/20140904/f4

[PATCH 2/2] 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

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 the purpose of introducing per-clock

[Bug 79980] Random radeonsi crashes

a charm on kernel 3.14* -- 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/20140904/851dad81/attachment.html>

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

On Wed, Sep 03, 2014 at 05:10:16PM -0300, Gustavo Padovan wrote: > 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

ccf vs iommu vs drm locking fun

On 09/04/14 17:46, Rob Clark wrote: > So, I was looking at the below lockdep splat, and discussing it a bit > w/ sboyd on IRC, and came to a slightly disturbing realization.. > > The interaction between prepare_lock and debugfs bits is a little bit > worrying. In particular, it is probably not a

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 16:59 +0900, Michel D?nzer wrote: > > Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm > not alone, at least with AGP 1x it seems to work quite well for most > people. So I don't see the justification for intentionally breaking it > completely for

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

On Wed, Sep 03, 2014 at 05:10:18PM -0300, Gustavo Padovan wrote: > 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

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote: > > This will, from what I can tell, try to use the same caching mode as the > > original object: > > > > if ((cur_placement & caching) != 0) > > result |= (cur_placement & caching); > > > > And cur_placement comes from

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

On Wed, Sep 03, 2014 at 05:10:17PM -0300, Gustavo Padovan wrote: > 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

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote: > > +#else /* CONFIG_X86 */ > > +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t > *placement) > > +{ > > + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) { > > + ttm->caching_state = tt_cached; > > +

[PATCH 4/9] drm/ast: Don't assume DVO enabled means SIL164 on uninitialized chips

It looks like the AST2400 comes up with the DVO enable bit set, which causes us to incorrectly assume we have a SIL164 regardless of the value of the scratch registers setup by the BMC firmware. So let's limit that test to the case where the chip has already been setup by a BIOS. Signed-off-by:

[PATCH 3/9] drm/ast: Properly initialize P2A base before using it in ast_init_3rdtx()

If the P2A has been used to target other SOC registers before that call, we're going to hit the wrong place so make sure we set the base address up properly before using it. (P2A stands for PCIe to AHB bridge and is the bride that allows accessing the AST's internal AHB bus using a relocatable

[PATCH 2/9] drm/ast: POST chip at probe time if VGA not enabled

We need to do it on machines without a BIOS such as POWER8. Also for detection to work without triggering PCIe errors, we need to enable VGA early on, inside ast_detect_chip(). While touching those files, replace a few hard coded register numbers with the corresponding symbolic constant.

[PATCH 9/9] drm/ttm: Sanity check mapping attributes on powerpc in ttm_io_prot()

On all current cache coherent powerpc processors, it is not legit to map system memory non-cachable. This will cause aliases with the linear mapping which can be fatal. The TTM should generally avoid it after Jerome placement patches but let's add a sanity check anyway to catch any possible

[PATCH 8/9] drm/ttm: Clean usage of ttm_io_prot() with TTM_PL_FLAG_CACHED

Today, most callers of ttm_io_prot() check TTM_PL_FLAG_CACHED before calling it since on some archs it will unconditionally create non-cached mappings. But not all callers do which is incorrect as far as I can tell. Instead, move that check inside ttm_io_port() itself for all archs and make

[PATCH 7/9] drm: powerpc can use a simpler drm_io_prot()

What the code does is equivalent to the x86 code, so let's use it as well Signed-off-by: Benjamin Herrenschmidt --- drivers/gpu/drm/drm_vm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 24e045c..ed02563 100644

[PATCH 6/9] drm/ttm: force cached mapping on non x86 platform

From: J?r?me Glisse People interested in providing uncached or write combined mapping on there architecture need to do the ground work inside there arch specific code to allow to break the linear kernel mapping so that page mapping attributes can be updated, in the meantime

[PATCH 5/9] drm/ast: Cleanup analog init code path

Move the MMIO mangling to a separate routine and actually disable the DVO output when using pure analog. Signed-off-by: Benjamin Herrenschmidt --- drivers/gpu/drm/ast/ast_dp501.c | 49 ++--- 1 file changed, 31 insertions(+), 18 deletions(-) diff --git

[PATCH 4/9] drm/ast: Don't assume DVO enabled means SIL164 on uninitialized chips

It looks like the AST2400 comes up with the DVO enable bit set, which causes us to incorrectly assume we have a SIL164 regardless of the value of the scratch registers setup by the BMC firmware. So let's limit that test to the case where the chip has already been setup by a BIOS. Signed-off-by:

[PATCH 2/9] drm/ast: POST chip at probe time if VGA not enabled

We need to do it on machines without a BIOS such as POWER8. Also for detection to work without triggering PCIe errors, we need to enable VGA early on, inside ast_detect_chip(). While touching those files, replace a few hard coded register numbers with the corresponding symbolic constant.

[PATCH 1/9] drm/ast: Try to use MMIO registers when PIO isn't supported

If the PIO resources haven't been assigned, then we have no choice but try to use the MMIO version. This is the case for example on POWER8 which doesn't support PIO at all. Chips rev 0x20 or later have MMIO decoding enabled by default. Signed-off-by: Benjamin Herrenschmidt ---

TTM placement & caching issue/questions

On 04.09.2014 16:59, Michel D?nzer wrote: > On 04.09.2014 16:54, Benjamin Herrenschmidt wrote: >> On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote: +#else /* CONFIG_X86 */ +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t >>> *placement) +{ + if

TTM placement & caching issue/questions

On 04.09.2014 16:54, Benjamin Herrenschmidt wrote: > On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote: >>> +#else /* CONFIG_X86 */ >>> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t >> *placement) >>> +{ >>> + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) { >>> +

SI display gap for more than 2 displays

On Thu, Sep 04, 2014 at 03:52:20PM +0200, Sylvain BERTRAND wrote: > Hi, > > In si_program_display_gap we have DISP1_GAP and DISP2_GAP. > > Where are DISP3_GAP to DISP6_GAP? What does expect this hardware > block when more than 2 displays are connected? Is DISP2_GAP > actually stand for

[Bug 83505] New: AMD A4-5300 APU : only radeon.dpm=1 prevents random reboots with 3.16.1 kernel.

hments/20140904/b194d598/attachment.html>

[PATCH 9/9] drm/ttm: Sanity check mapping attributes on powerpc in ttm_io_prot()

On 04.09.2014 16:47, Benjamin Herrenschmidt wrote: > On all current cache coherent powerpc processors, it is not legit > to map system memory non-cachable. This will cause aliases with > the linear mapping which can be fatal. > > The TTM should generally avoid it after Jerome placement patches but

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

[Bug 81239] Evolution window content not shown fully (only desktop background)

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/6a2dba55/attachment.html>

TTM placement & caching issue/questions

On 04.09.2014 11:36, Jerome Glisse wrote: > On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote: >> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote: >>> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote: >>> So in the meantime the attached patch should

TTM placement & caching issue/questions

On 04.09.2014 10:55, Jerome Glisse wrote: > > While i agree about the issue of incoherent double map of same page, i > think we have more issue. For instance lattely AMD have been pushing a > lot of patches to move things to use uncached memory for radeon and as > usual thoses patches comes with

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

Hey, Op 04-09-14 om 15:34 schreef Christian K?nig: >> I need to check the docs how to do this correctly, > The docs don't really cover this case. > > For the GPU waiting on an address there is an extra document just for this > case which I don't have at hand right now. But IIRC it was

SI display gap for more than 2 displays

Hi, In si_program_display_gap we have DISP1_GAP and DISP2_GAP. Where are DISP3_GAP to DISP6_GAP? What does expect this hardware block when more than 2 displays are connected? Is DISP2_GAP actually stand for DISP[3-6]_GAP? Still in the same function, what happened to the pipes for

[Bug 83500] si_dma_copy_tile causes GPU hangs

try. -- 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/20140904/4dc47054/attachment.html>

[PATCH v2] drm/radeon: reduce memory footprint for debugging

There is no need to use hex_dump_to_buffer() since we have a kernel helper to dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes. Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/radeon/atombios_dp.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-)

[PATCH] drm/radeon: reduce memory footprint for debugging

There is no need to use hex_dump_to_buffer() since we have a kernel helper to dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes. Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/radeon/atombios_dp.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-)

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

op.org/archives/dri-devel/attachments/20140904/832b91d8/attachment.html>

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

> I need to check the docs how to do this correctly, The docs don't really cover this case. For the GPU waiting on an address there is an extra document just for this case which I don't have at hand right now. But IIRC it was recommended to use the local memory of the device waiting on the

TTM placement & caching issue/questions

On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote: > On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote: > > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote: > > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote: > > > > > > > So in the meantime the

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/8b653eac/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

[Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process

On Thu, Sep 04, 2014 at 11:52:15AM +, Gupta, Sourab wrote: > On Thu, 2014-09-04 at 10:01 +, Daniel Vetter wrote: > > Interface design discussions should happen in public (so that > > non-intel people can jump in, which happens rather often for other > > drivers actually). But at least

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

Am 04.09.2014 um 14:08 schrieb Maarten Lankhorst: > Hey, > > Op 04-09-14 om 13:54 schreef Christian K?nig: >> Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst: >>> Use the semaphore mechanism to make this happen, this uses signaling >>> from the cpu instead of signaling by the gpu. >> I'm not sure

[Bug 83432] r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ddb19548/attachment.html>

[PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

t; /* Reinitialize corresponding vblank timestamp if high-precision > query > * available. Skip this step if query unsupported or failed. Will > * reinitialize delayed at next vblank interrupt in that case. > -- > 1.8.5.5 > > -- next part -

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

Hey, Op 04-09-14 om 13:54 schreef Christian K?nig: > Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst: >> Use the semaphore mechanism to make this happen, this uses signaling >> from the cpu instead of signaling by the gpu. > > I'm not sure if this will work reliable when the semaphores are in

[Bug 83500] si_dma_copy_tile causes GPU hangs

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140904/520bd07c/attachment.html>

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst: > Use the semaphore mechanism to make this happen, this uses signaling > from the cpu instead of signaling by the gpu. I'm not sure if this will work reliable when the semaphores are in system memory. We might need to reserve some VRAM for them

[Bug 83418] EU IV is incorrectly rendered after git1409011930.d571f2

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/534b5783/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

[Bug 79980] Random radeonsi crashes

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

[Bug 83500] New: si_dma_copy_tile causes GPU hangs

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/683ad5c6/attachment.html>

[PATCH 3/7] drm/radeon: cope with foreign fences inside the reservation object

Am 04.09.2014 um 13:40 schrieb Maarten Lankhorst: > Not the whole world is a radeon! :-) > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/radeon/radeon.h | 11 - > drivers/gpu/drm/radeon/radeon_cs.c | 32 + >

[PATCH 7/7] drm/nouveau: allow asynchronous waiting using gart fences

This requires allocating a fence sooner to annotate any cross-dev fences, and making sure that enough memory is available before emitting the fence. The current seqno is written to the GART bo on completion, and a list of finished fences is kept to allow arbitrary depth. Signed-off-by: Maarten

[PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

Use the semaphore mechanism to make this happen, this uses signaling from the cpu instead of signaling by the gpu. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/radeon.h | 17 ++- drivers/gpu/drm/radeon/radeon_cs.c| 30 ++---

[PATCH 5/7] drm/nouveau: export reservation_object from dmabuf to ttm

Adds an extra argument to nouveau_bo_new, which is used in nouveau_prime.c. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++-- drivers/gpu/drm/nouveau/nouveau_bo.h| 1 +

[PATCH 4/7] drm/radeon: export reservation_object from dmabuf to ttm

Adds an extra argument to radeon_bo_create, which is used in radeon_prime.c. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/cik.c | 4 ++-- drivers/gpu/drm/radeon/evergreen.c| 6 +++--- drivers/gpu/drm/radeon/r600.c | 4 ++--

[PATCH 3/7] drm/radeon: cope with foreign fences inside the reservation object

Not the whole world is a radeon! :-) Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/radeon.h | 11 - drivers/gpu/drm/radeon/radeon_cs.c | 32 + drivers/gpu/drm/radeon/radeon_display.c | 41 -

[PATCH 2/7] drm/ttm: add reservation_object as argument to ttm_bo_init

This allows importing reservation objects from dma-bufs. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ast/ast_ttm.c| 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +- drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-

[PATCH 1/7] drm: Pass dma-buf as argument to, gem_prime_import_sg_table

Allows importing reservation_objects from a dma-buf. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_gem_cma_helper.c| 5 +++-- drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/msm/msm_drv.h | 2 +- drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--

[PATCH 0/7] cross-dev synchronization in TTM through dma-buf.

So this is finally it. After all the work writing support for fences cross-dev synchronization is now possible. :-) The last 2 patches of this series are not needed for cross-dev to work. But without it any waits on cross-device fences will be done synchronously. I've previously tested this

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

[Bug 83418] EU IV is incorrectly rendered after git1409011930.d571f2

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

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

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/20140904/01a410f7/attachment.html>

[Bug 83418] EU IV is incorrectly rendered after git1409011930.d571f2

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/ac463558/attachment.html>

TTM placement & caching issue/questions

On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote: > So in the meantime the attached patch should work, it just silently ignore > the caching attribute request on non x86 instead of pretending that things > are setup as expected and then latter the radeon ou nouveau hw unsetting > the snoop

TTM placement & caching issue/questions

On 09/04/2014 11:43 AM, Benjamin Herrenschmidt wrote: > On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote: >> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote: >>> Last time I tested, (and it seems like Michel is on the same track), >>> writing with the CPU to write-combined

TTM placement & caching issue/questions

On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote: > So i think we need to get a platform flags and or set_pages_array_wc|uc > needs to fail and this would fallback to cached mapping if the fallback > code still works. So if your arch properly return and error for those > cache changing

[Bug 83436] Sudden framerate drops in multiple games

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140904/acc1c2a6/attachment-0001.html>

[Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process

On Thu, Sep 4, 2014 at 9:03 AM, Gupta, Sourab wrote: > On Wed, 2014-09-03 at 13:09 +, Daniel Vetter wrote: >> On Wed, Sep 03, 2014 at 11:49:52AM +, Gupta, Sourab wrote: >> > On Wed, 2014-09-03 at 10:58 +, Daniel Vetter wrote: >> > > On Wed, Sep 03, 2014 at 03:39:55PM +0530,

[Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process

On Thu, 2014-09-04 at 10:01 +, Daniel Vetter wrote: > On Thu, Sep 4, 2014 at 9:03 AM, Gupta, Sourab > wrote: > > On Wed, 2014-09-03 at 13:09 +, Daniel Vetter wrote: > >> On Wed, Sep 03, 2014 at 11:49:52AM +, Gupta, Sourab wrote: > >> > On Wed, 2014-09-03 at 10:58 +, Daniel Vetter

TTM placement & caching issue/questions

On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote: > Last time I tested, (and it seems like Michel is on the same track), > writing with the CPU to write-combined memory was substantially faster > than writing to cached memory, with the additional side-effect that CPU > caches are

TTM placement & caching issue/questions

On 09/04/2014 10:06 AM, Benjamin Herrenschmidt wrote: > On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote: > >>> This will, from what I can tell, try to use the same caching mode as the >>> original object: >>> >>> if ((cur_placement & caching) != 0) >>> result |=

[Bug 83436] Sudden framerate drops in multiple games

nts/20140904/627f9d1b/attachment.html>

[git pull] drm fixes

Hi Linus, just i915 and vmwgfx fixes, i915 contains a bunch of fixes for recent regressions in outputs, vmwgfx fixes a possible loop for ever and a bad return code. Dave. The following changes since commit 59753a805499f1ffbca4ac0a24b3dff67bf1: Merge tag 'backlight-fixes-3.17' of

[Bug 82828] Regression: Crash in 3Dmark2001

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

TTM placement & caching issue/questions

Hi folks ! I've been tracking down some problems with the recent DRI on powerpc and stumbled upon something that doesn't look right, and not necessarily only for us. Now it's possible that I haven't fully understood the code here and I also don't know to what extent some of that behaviour is

[PATCH 6/9] drm/ttm: force cached mapping on non x86 platform

On 09/04/2014 09:46 AM, Benjamin Herrenschmidt wrote: > From: J?r?me Glisse > > People interested in providing uncached or write combined mapping > on there architecture need to do the ground work inside there arch > specific code to allow to break the linear kernel mapping so that > page mapping

TTM placement & caching issue/questions

Hi! Let me try to bring some clarity and suggestions into this. On 09/04/2014 02:12 AM, Benjamin Herrenschmidt wrote: > Hi folks ! > > I've been tracking down some problems with the recent DRI on powerpc and > stumbled upon something that doesn't look right, and not necessarily > only for us. >

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

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/20140904/3727bb5e/attachment.html>

  1   2   >