From: Lauri Kasanen <cand@gmx.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Lauri Kasanen <cand@gmx.com>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/radeon: fix TOPDOWN handling for bo_create
Date: Thu, 12 Mar 2015 12:21:23 +0200 [thread overview]
Message-ID: <20150312122123.bd75b5e1.cand@gmx.com> (raw)
In-Reply-To: <55015640.4020008@daenzer.net>
On Thu, 12 Mar 2015 18:02:56 +0900
Michel Dänzer <michel@daenzer.net> wrote:
> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> problem is really that some BOs are expected to be within a certain
> range from the beginning of VRAM, but lpfn isn't set accordingly. It
> would be better to fix that by setting lpfn directly than indirectly via
> RADEON_GEM_CPU_ACCESS.
>
>
> Anyway, since this isn't the first bug which prevents
> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
> wonder if its performance impact should be re-evaluated. Lauri?
I'm sorry, I'm not in a place where I could spend the time to redo the
benchmarks.
If it causes too many issues it is of course easy to disable, but so
far the issues shown have not been caused by it - it merely exposed
wrong settings/bugs elsewhere. From this POV I would say it's good to
have it enabled, to stress the various parts.
This doesn't warm the heart of the guy with flicker after suspend, so
perhaps a kernel module parameter to disable it (defaulting to enabled)?
- Lauri
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-03-12 10:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 15:44 [PATCH] drm/radeon: fix TOPDOWN handling for bo_create Alex Deucher
2015-03-11 18:21 ` Christian König
2015-03-11 20:51 ` Alex Deucher
2015-03-11 21:14 ` Alex Deucher
2015-03-12 9:02 ` Michel Dänzer
2015-03-12 9:23 ` Christian König
2015-03-12 9:30 ` Oded Gabbay
2015-03-12 9:36 ` Christian König
2015-03-15 15:07 ` Oded Gabbay
2015-03-12 13:09 ` Alex Deucher
2015-03-13 2:55 ` Michel Dänzer
2015-03-16 22:32 ` Alex Deucher
2015-03-17 3:48 ` Michel Dänzer
2015-03-17 15:19 ` Alex Deucher
2015-03-17 15:43 ` Christian König
2015-03-17 15:50 ` Alex Deucher
2015-03-17 11:40 ` Christian König
2015-03-17 13:49 ` Alex Deucher
2015-03-12 10:21 ` Lauri Kasanen [this message]
2015-03-13 9:11 ` Daniel Vetter
2015-03-13 9:46 ` Michel Dänzer
2015-03-13 16:36 ` Daniel Vetter
2015-03-13 17:57 ` Alex Deucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150312122123.bd75b5e1.cand@gmx.com \
--to=cand@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.