[PATCH 1/2] drm/radeon: fix render backend setup for SI and CIK
From: Marek Ol??k
Only the render backends of the first shader engine were enabled. The others
were erroneously disabled. Enabling the other render backends improves
performance a lot.
Unigine Sanctuary on Bonaire:
Before: 15 fps
After: 90 fps
Judging from the fan noise, the GPU was also underclocked when the other
render backends were disabled, resulting in horrible performance. The fan is
a lot noisy under load now.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/cik.c | 10 +-
drivers/gpu/drm/radeon/si.c | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b43a3a3..138a776 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3057,7 +3057,7 @@ static u32 cik_create_bitmask(u32 bit_width)
* Returns the disabled RB bitmask.
*/
static u32 cik_get_rb_disabled(struct radeon_device *rdev,
- u32 max_rb_num, u32 se_num,
+ u32 max_rb_num_per_se,
u32 sh_per_se)
{
u32 data, mask;
@@ -3071,7 +3071,7 @@ static u32 cik_get_rb_disabled(struct radeon_device *rdev,
data >>= BACKEND_DISABLE_SHIFT;
- mask = cik_create_bitmask(max_rb_num / se_num / sh_per_se);
+ mask = cik_create_bitmask(max_rb_num_per_se / sh_per_se);
return data & mask;
}
@@ -3088,7 +3088,7 @@ static u32 cik_get_rb_disabled(struct radeon_device *rdev,
*/
static void cik_setup_rb(struct radeon_device *rdev,
u32 se_num, u32 sh_per_se,
-u32 max_rb_num)
+u32 max_rb_num_per_se)
{
int i, j;
u32 data, mask;
@@ -3098,7 +3098,7 @@ static void cik_setup_rb(struct radeon_device *rdev,
for (i = 0; i < se_num; i++) {
for (j = 0; j < sh_per_se; j++) {
cik_select_se_sh(rdev, i, j);
- data = cik_get_rb_disabled(rdev, max_rb_num, se_num,
sh_per_se);
+ data = cik_get_rb_disabled(rdev, max_rb_num_per_se,
sh_per_se);
if (rdev->family == CHIP_HAWAII)
disabled_rbs |= data << ((i * sh_per_se + j) *
HAWAII_RB_BITMAP_WIDTH_PER_SH);
else
@@ -3108,7 +3108,7 @@ static void cik_setup_rb(struct radeon_device *rdev,
cik_select_se_sh(rdev, 0x, 0x);
mask = 1;
- for (i = 0; i < max_rb_num; i++) {
+ for (i = 0; i < max_rb_num_per_se * se_num; i++) {
if (!(disabled_rbs & mask))
enabled_rbs |= mask;
mask <<= 1;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index a36736d..3eed9a1 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2811,7 +2811,7 @@ static void si_setup_spi(struct radeon_device *rdev,
}
static u32 si_get_rb_disabled(struct radeon_device *rdev,
- u32 max_rb_num, u32 se_num,
+ u32 max_rb_num_per_se,
u32 sh_per_se)
{
u32 data, mask;
@@ -2825,14 +2825,14 @@ static u32 si_get_rb_disabled(struct radeon_device
*rdev,
data >>= BACKEND_DISABLE_SHIFT;
- mask = si_create_bitmask(max_rb_num / se_num / sh_per_se);
+ mask = si_create_bitmask(max_rb_num_per_se / sh_per_se);
return data & mask;
}
static void si_setup_rb(struct radeon_device *rdev,
u32 se_num, u32 sh_per_se,
- u32 max_rb_num)
+ u32 max_rb_num_per_se)
{
int i, j;
u32 data, mask;
@@ -2842,14 +2842,14 @@ static void si_setup_rb(struct radeon_device *rdev,
for (i = 0; i < se_num; i++) {
for (j = 0; j < sh_per_se; j++) {
si_select_se_sh(rdev, i, j);
- data = si_get_rb_disabled(rdev, max_rb_num, se_num,
sh_per_se);
+ data = si_get_rb_disabled(rdev, max_rb_num_per_se,
sh_per_se);
disabled_rbs |= data << ((i * sh_per_se + j) *
TAHITI_RB_BITMAP_WIDTH_PER_SH);
}
}
si_select_se_sh(rdev, 0x, 0x);
mask = 1;
- for (i = 0; i < max_rb_num; i++) {
+ for (i = 0; i < max_rb_num_per_se * se_num; i++) {
if (!(disabled_rbs & mask))
enabled_rbs |= mask;
mask <<= 1;
--
1.8.3.2
[PATCH 2/2] drm/radeon: expose render backend mask to the userspace
From: Marek Ol??k
This will allow userspace to correctly program the PA_SC_RASTER_CONFIG
register, so it can be considered a fix.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/cik.c| 2 ++
drivers/gpu/drm/radeon/radeon.h | 4 ++--
drivers/gpu/drm/radeon/radeon_kms.c | 9 +
drivers/gpu/drm/radeon/si.c | 2 ++
include/uapi/drm/radeon_drm.h | 2 ++
5 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 138a776..e950fab 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3114,6 +3114,8 @@ static void cik_setup_rb(struct radeon_device *rdev,
mask <<= 1;
}
+ rdev->config.cik.backend_enable_mask = enabled_rbs;
+
for (i = 0; i < se_num; i++) {
cik_select_se_sh(rdev, i, 0x);
data = 0;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b1f990d..45e1f44 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1940,7 +1940,7 @@ struct si_asic {
unsigned sc_earlyz_tile_fifo_size;
unsigned num_tile_pipes;
- unsigned num_backends_per_se;
+ unsigned backend_enable_mask;
unsigned backend_disable_mask_per_asic;
unsigned backend_map;
unsigned num_texture_channel_caches;
@@ -1970,7 +1970,7 @@ struct cik_asic {
unsigned sc_earlyz_tile_fifo_size;
unsigned num_tile_pipes;
- unsigned num_backends_per_se;
+ unsigned backend_enable_mask;
unsigned backend_disable_mask_per_asic;
unsigned backend_map;
unsigned num_texture_channel_caches;
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 55d0b47..21d593c 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -461,6 +461,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
case RADEON_INFO_SI_CP_DMA_COMPUTE:
*value = 1;
break;
+ case RADEON_INFO_SI_BACKEND_ENABLED_MASK:
+ if (rdev->family >= CHIP_BONAIRE) {
+ *value = rdev->config.cik.backend_enable_mask;
+ } else if (rdev->family >= CHIP_TAHITI) {
+ *value = rdev->config.si.backend_enable_mask;
+ } else {
+ DRM_DEBUG_KMS("BACKEND_ENABLED_MASK is si+ only!\n");
+ }
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 3eed9a1..85e1edf 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2855,6 +2855,8 @@ static void si_setup_rb(struct radeon_device *rdev,
mask <<= 1;
}
+ rdev->config.si.backend_enable_mask = enabled_rbs;
+
for (i = 0; i < se_num; i++) {
si_select_se_sh(rdev, i, 0x);
data = 0;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 2f3f7ea..fe421e8 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -983,6 +983,8 @@ struct drm_radeon_cs {
#define RADEON_INFO_SI_CP_DMA_COMPUTE 0x17
/* CIK macrotile mode array */
#define RADEON_INFO_CIK_MACROTILE_MODE_ARRAY 0x18
+/* query the number of render backends */
+#define RADEON_INFO_SI_BACKEND_ENABLED_MASK0x19
struct drm_radeon_info {
--
1.8.3.2
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #85 from Alexandre Demers --- (In reply to comment #84) > (In reply to comment #83) > > Alex Deucher, would there be any interest in testing "[PATCH 00/18] Rework > > PM init order" and the following ones? > > Yeah, probably worth a shot. For convenience, I've pushed the patches to a > branch: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=dpm-reorder Nope, not working... -- 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/20131222/e8139c13/attachment.html>
[PATCH] staging: imx-drm: imx-tve: Fix a sparse warning
This patch declares the function of_get_tve_mode
as a static one to fix this sparse warning:
drivers/staging/imx-drm/imx-tve.c:563:11: warning: \
symbol 'of_get_tve_mode' was not declared. \
Should it be static?
Signed-off-by: Liu Ying
---
drivers/staging/imx-drm/imx-tve.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 2c44fef..9abc7ca 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -560,7 +560,7 @@ static const char *imx_tve_modes[] = {
[TVE_MODE_VGA] = "vga",
};
-const int of_get_tve_mode(struct device_node *np)
+static const int of_get_tve_mode(struct device_node *np)
{
const char *bm;
int ret, i;
--
1.7.9.5
[Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 --- Comment #5 from Barto --- I did a bisect with git, and the culprit seems to be : 59b01ca252bd6706f08cd80a864819d71dfe741c is the first bad commit commit 59b01ca252bd6706f08cd80a864819d71dfe741c Author: Fredrik H?glund Date: Tue Apr 9 20:54:25 2013 +0200 mesa: Add ARB_vertex_attrib_binding update_array() and update_array_format() are changed to update the new attrib and binding states, and the client arrays become derived state. Reviewed-by: Eric Anholt :04 04 e1270491ec1e0f8a98f930a0cf959038a56c4449 d2f6ee337ecbf36f764921474f2c69a67308eafa M src you can fin the git log for the bisect in attachment with this message, the bisect wad doing by setting the first good bissect with the revision 9.2.5 of mesa and the bad bissect with the HEAD revision of mesa mastering ( last revision on git ), I hope we have enough clues to fix this bug -- 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/20131222/18e6b2ba/attachment-0001.html>
[Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 --- Comment #6 from Barto --- Created attachment 91114 --> https://bugs.freedesktop.org/attachment.cgi?id=91114&action=edit git bisect log the git bisect log, # first bad commit: [59b01ca252bd6706f08cd80a864819d71dfe741c] mesa: Add ARB_vertex_attrib_binding -- 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/20131222/ecae3c29/attachment.html>
[Bug 70647] [radeonsi] Crash unigine-heaven 3.0 with msaa enabled
https://bugs.freedesktop.org/show_bug.cgi?id=70647 robert at familiegrosskopf.de changed: What|Removed |Added CC||tonicose at gmail.com --- Comment #9 from robert at familiegrosskopf.de --- *** Bug 72876 has been marked as a duplicate of this bug. *** -- 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/20131222/d6c9e651/attachment.html>
[PATCH] dma-buf: avoid using IS_ERR_OR_NULL
Em Sat, 21 Dec 2013 07:42:17 -0500
Rob Clark escreveu:
> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote:
> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
> > ERR_PTR on a error. This encourages a common buggy pattern in
> > callers:
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> > if (IS_ERR_OR_NULL(sgt))
> > return PTR_ERR(sgt);
> >
> > This causes the caller to return 0 on an error. IS_ERR_OR_NULL
> > is almost always a sign of poorly-defined error handling.
> >
> > This patch converts dma_buf_map_attachment to always return
> > ERR_PTR, and fixes the callers that incorrectly handled NULL.
> > There are a few more callers that were not checking for NULL
> > at all, which would have dereferenced a NULL pointer later.
> > There are also a few more callers that correctly handled NULL
> > and ERR_PTR differently, I left those alone but they could also
> > be modified to delete the NULL check.
> >
> > This patch also converts dma_buf_vmap to always return NULL.
> > All the callers to dma_buf_vmap only check for NULL, and would
> > have dereferenced an ERR_PTR and panic'd if one was ever
> > returned. This is not consistent with the rest of the dma buf
> > APIs, but matches the expectations of all of the callers.
> >
> > Signed-off-by: Colin Cross
> > ---
> > drivers/base/dma-buf.c | 18 +++---
> > drivers/gpu/drm/drm_prime.c| 2 +-
> > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
> > drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
> > 4 files changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> > index 1e16cbd61da2..cfe1d8bc7bb8 100644
> > --- a/drivers/base/dma-buf.c
> > +++ b/drivers/base/dma-buf.c
> > @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> > * @dmabuf:[in]buffer to attach device to.
> > * @dev: [in]device to be attached.
> > *
> > - * Returns struct dma_buf_attachment * for this attachment; may return
> > negative
> > - * error codes.
> > - *
> > + * Returns struct dma_buf_attachment * for this attachment; returns
> > ERR_PTR on
> > + * error.
> > */
> > struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > struct device *dev)
> > @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
> > * @attach:[in]attachment whose scatterlist is to be returned
> > * @direction: [in]direction of DMA transfer
> > *
> > - * Returns sg_table containing the scatterlist to be returned; may return
> > NULL
> > - * or ERR_PTR.
> > - *
> > + * Returns sg_table containing the scatterlist to be returned; returns
> > ERR_PTR
> > + * on error.
> > */
> > struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> > enum dma_data_direction direction)
> > @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
> > dma_buf_attachment *attach,
> > return ERR_PTR(-EINVAL);
> >
> > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> > + if (!sg_table)
> > + sg_table = ERR_PTR(-ENOMEM);
> >
> > return sg_table;
> > }
> > @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
> > * These calls are optional in drivers. The intended use for them
> > * is for mapping objects linear in kernel space for high use objects.
> > * Please attempt to use kmap/kunmap before thinking about these
> > interfaces.
> > + *
> > + * Returns NULL on error.
> > */
> > void *dma_buf_vmap(struct dma_buf *dmabuf)
> > {
> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > BUG_ON(dmabuf->vmap_ptr);
> >
> > ptr = dmabuf->ops->vmap(dmabuf);
> > - if (IS_ERR_OR_NULL(ptr))
> > + if (WARN_ON_ONCE(IS_ERR(ptr)))
>
> since vmap is optional, the WARN_ON might be a bit strong.. although
> it would be a bit strange for an exporter to supply a vmap fxn which
> always returned NULL, not sure about that. Just thought I'd mention
> it in case anyone else had an opinion about that.
>
> But either way:
>
> Reviewed-by: Rob Clark
IMHO, a WARN_ON_ONCE() here (or some other error report printk) seems ok,
as, if this function is called, the caller would be expecting it to not
fail.
Either way:
Reviewed-by: Mauro Carvalho Chehab
>
>
> > + ptr = NULL;
> > + if (!ptr)
> > goto out_unlock;
> >
> > dmabuf->vmap_ptr = ptr;
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 56805c39c906..bb516fdd195d 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
> > drm_device *dev,
> > get_dma_buf(dma_buf);
> >
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> >
[Bug 71431] radeon graphics stopped working since kernel 3.10 on AMD a4-3300
https://bugs.freedesktop.org/show_bug.cgi?id=71431 --- Comment #12 from ka.nick at mail.ru --- Unfortunately neither 1st one nor the combination of the two helped. It just reshaped the garbage, and X still keeps restarting. But now it looks like the screen is divided in small tiles that are maybe correct by themselves but placed at wrong positions and repeated now and then. -- 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/20131222/47d94aad/attachment.html>
[Bug 70647] [radeonsi] Crash unigine-heaven 3.0 with msaa enabled
https://bugs.freedesktop.org/show_bug.cgi?id=70647 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Marek Ol??k --- Heaven 3.0 needs EXT_gpu_shader4, which most probably won't be implemented in Mesa. Heaven 3.0 doesn't check if the extension is present before using it, which is a bug. There is nothing to fix in Mesa to make it work. -- 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/20131222/41ac85db/attachment.html>
[Bug 71431] radeon graphics stopped working since kernel 3.10 on AMD a4-3300
https://bugs.freedesktop.org/show_bug.cgi?id=71431 --- Comment #13 from ka.nick at mail.ru --- UPD: Tried to set ColorTiling and ColorTiling2D to off. In this case about 60% of the screen is rendered correctly but is placed @ wrong position on the screen. Mouse works but X restarts just the same. -- 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/20131222/b395093d/attachment.html>
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #11 from Giannis --- Bug fixed with Mainline Kernel 3.13-RC4 Thank you Alex. -- You are receiving this mail because: You are watching the assignee of the bug.
