https://bugs.freedesktop.org/show_bug.cgi?id=58150
Priority: medium
Bug ID: 58150
Assignee: dri-devel(a)lists.freedesktop.org
Summary: LLVM regression on 4090 since r600g: Use default
mul/mad function for tgsi-to-llvm
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: lists(a)andyfurniss.entadsl.com
Hardware: x86 (IA32)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
HD4890, git ~/tstellar/llvm, drm-next. since mesa commit -
commit 0ad1fefd6951aa47ab58a41dc9ee73083cbcf85c
Author: Vincent Lejeune <vljn(a)ovi.com>
Date: Wed Nov 28 00:35:55 2012 +0100
r600g: Use default mul/mad function for tgsi-to-llvm
Reveiwed-by: Tom Stellard <thomas.stellard at amd.com>
Mesa demos gearbox and fbo_firecube get one of the internal faces blacked out
at certain angles.
R600_LLVM=0 renders properly.
Happens before and after the commits that just went into ~/tstellar/llvm.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=56936
Priority: medium
Bug ID: 56936
Assignee: dri-devel(a)lists.freedesktop.org
Summary: cube map array support breaks rendering on BARTS
Severity: major
Classification: Unclassified
OS: All
Reporter: maxijac(a)free.fr
Hardware: Other
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 69839
--> https://bugs.freedesktop.org/attachment.cgi?id=69839&action=edit
Hon garbage rendering
Possibly affects other cards.
I bisected and the first bad commit is eb44c36df842af010269eda1be77c4aea8ebe736
r600g: add initial cube map array support (v2).
It either displays plain black or garbage textures.
I tested with Heroes of Newerth and Unigine heaven.
--
You are receiving this mail because:
You are the assignee for the bug.
It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
creating SG table for the buffers having more than 204 physical pages i.e.
equal to SG_MAX_SINGLE_ALLOC.
When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
page list will be passes to get each contiguous section which is represented
by a single entry in the table. For a Contiguous Buffer, number of entries
should be equal to 1.
Following check is causing the failure which is not applicable for Non-Contig
buffers:
if (WARN_ON_ONCE(nents > max_ents))
return -EINVAL;
Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
helper function.
This set is base on "exynos-drm-fixes" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
Signed-off-by: Rahul Sharma <rahul.sharma(a)samsung.com>
---
drivers/gpu/drm/drm_prime.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..072ee08 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -217,21 +217,17 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
{
struct sg_table *sg = NULL;
- struct scatterlist *iter;
- int i;
int ret;
sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!sg)
goto out;
- ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
+ ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
+ nr_pages << PAGE_SHIFT, GFP_KERNEL);
if (ret)
goto out;
- for_each_sg(sg->sgl, iter, nr_pages, i)
- sg_set_page(iter, pages[i], PAGE_SIZE, 0);
-
return sg;
out:
kfree(sg);
--
1.8.0
This series adds support for handling compact dma scatter lists to the
i915 driver. This is a dependency for the related upcoming change in the
PRIME interface:
http://www.spinics.net/lists/dri-devel/msg33917.html
Imre Deak (4):
drm: add helper to walk a dma scatter list a page at a time
drm: handle compact dma scatter lists in drm_clflush_sg()
drm/i915: handle walking compact dma scatter lists
drm/i915: create compact dma scatter lists for gem objects
drivers/gpu/drm/drm_cache.c | 7 ++---
drivers/gpu/drm/i915/i915_drv.h | 17 ++++------
drivers/gpu/drm/i915/i915_gem.c | 53 +++++++++++++++++---------------
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 ++++----
drivers/gpu/drm/i915/i915_gem_tiling.c | 18 ++++++-----
include/drm/drmP.h | 44 ++++++++++++++++++++++++++
6 files changed, 98 insertions(+), 54 deletions(-)
--
1.7.10.4
Hi Dave,
The big ticket item here is the new i915 modeset infrastructure.
Shockingly it didn't not blow up all over the place (i.e. I've managed to
fix the ugly issues before merging). 1-2 smaller corner cases broke, but
we have patches. Also, there's tons of patches on top of this that clean
out cruft and fix a few bugs that couldn't be fixed with the crtc helper
based stuff. So more stuff to come ;-)
Also a few other things:
- Tiny fix in the fb helper to go through the official dpms interface
instead of calling the crtc helper code.
- forcewake code frobbery from Ben, code should be more in-line with
what Windows does now.
- fixes for the render ring flush on hsw (Paulo)
- gpu frequency tracepoint
- vlv forcewake changes to better align it with our understanding of the
forcewake magic.
- a few smaller cleanups
Cheers, Daniel
The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:
drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-09-09
for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:
drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 00:51:15 +0200)
----------------------------------------------------------------
Ben Widawsky (5):
drm/i915: Extract forcewake ack timeout
drm/i915: use cpu_relax() in wait_for_atomic
drm/i915: Change forcewake timeout to 2ms
drm/i915: Never read FORCEWAKE
drm/i915: Enable some sysfs stuff without CONFIG_PM
Chris Wilson (1):
drm/i915: Convert remaining debugfs iterators over rings to for_each_ring()
Daniel Vetter (66):
drm/ips: move drps/ips/ilk related variables into dev_priv->ips
drm/i915: add a tracepoint for gpu frequency changes
drm/i915: align vlv forcewake with common lore
drm/i915: differ error message between forcwake timeouts
drm/i915: add crtc->enable/disable vfuncs insted of dpms
drm/i915: rip out crtc prepare/commit indirection
drm/i915: add direct encoder disable/enable infrastructure
drm/i915/hdmi: convert to encoder->disable/enable
drm/i915/tv: convert to encoder enable/disable
drm/i915/lvds: convert to encoder disable/enable
drm/i915/dp: convert to encoder disable/enable
drm/i915/crt: convert to encoder disable/enable
drm/i915/sdvo: convert to encoder disable/enable
drm/i915/dvo: convert to encoder disable/enable
drm/i915: convert dpms functions of dvo/sdvo/crt
drm/i915: rip out encoder->disable/enable checks
drm/i915: clean up encoder_prepare/commit
drm/i915: copy&paste drm_crtc_helper_set_config
drm/i915: call set_base directly
drm/i915: inline intel_best_encoder
drm/i915: copy&paste drm_crtc_helper_set_mode
drm/i915: simplify intel_crtc_prepare_encoders
drm/i915: rip out encoder->prepare/commit
drm/i915: call crtc functions directly
drm/i915: WARN when trying to enabled an unused crtc
drm/i915: Add interfaces to read out encoder/connector hw state
drm/i915/dp: implement get_hw_state
drm/i915/hdmi: implement get_hw_state
drm/i915/tv: implement get_hw_state
drm/i915/lvds: implement get_hw_state
drm/i915/crt: implement get_hw_state
drm/i915/sdvo: implement get_hw_state
drm/i915/dvo: implement get_hw_state
drm/i915: read out the modeset hw state at load and resume time
drm/i915: check connector hw/sw state
drm/i915: rip out intel_crtc->dpms_mode
drm/i915: rip out intel_dp->dpms_mode
drm/i915: ensure the force pipe A quirk is actually followed
drm/i915: introduce struct intel_set_config
drm/i915: extract modeset config save/restore code
drm/i915: extract intel_set_config_compute_mode_changes
drm/i915: extract intel_set_config_update_output_state
drm/i915: implement crtc helper semantics relied upon by the fb helper
drm/i915: don't update the fb base if there is no fb
drm/i915: convert pointless error checks in set_config to BUGs
drm/i915: don't save all the encoder/crtc state in set_config
drm/i915: stage modeset output changes
drm/i915: push crtc->fb update into pipe_set_base
drm/i915: remove crtc disabling special case
drm/i915: move output commit and crtc disabling into set_mode
drm/i915: extract adjusted mode computation
drm/i915: use staged outuput config in tv->mode_fixup
drm/i915: use staged outuput config in lvds->mode_fixup
drm/i915: compute masks of crtcs affected in set_mode
drm/i915: implement new set_mode code flow
drm/i915: push commit_output_state past crtc disabling
drm/i915: s/intel_encoder_disable/intel_encoder_noop
drm/i915: WARN if the pipe won't turn off
drm/i915: switch the load detect code to the staged modeset config
drm/i915: push commit_output_state past the crtc/encoder preparing
drm/i915: disable all crtcs at suspend time
drm/i915: no longer call drm_helper_resume_force_mode
drm/i915: add tons of modeset state checks
drm/i915: improve modeset state checking after dpms calls
Merge the modeset-rework, basic conversion into drm-intel-next
drm/fb helper: don't call drm_helper_connector_dpms directly
Jani Nikula (2):
drm/i915: only enable sdvo hotplug irq if needed
drm/i915: fix sdvo hotplug support check and activation
Paulo Zanoni (3):
drm/i915: add gen7_render_ring_flush
drm/i915: add workarounds directly to gen6_render_ring_flush
drm/i915: add workarounds to gen7_render_ring_flush
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Priority: medium
Bug ID: 60802
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Kernel 3.8-rc7 breaks rendering on Radeon (confirmed
on Cayman)
Severity: normal
Classification: Unclassified
OS: All
Reporter: alexandre.f.demers(a)gmail.com
Hardware: Other
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI
Since temporary fix for bug 58354, I'm able to test some applications once
again and I've found out some rendering issues. In Unigine Tropics, Unigine
Heaven and under another test that used to be OK (I'll come back with its name
soon, I think it was Amnesia's render test), some textures are not rendered
correctly with kernel 3.8-rc7 (vanilla), but are OK with kernel 3.7.7 from
Archlinux 64. I'm pretty sure an earlier 3.8-rcX was rendering OK with the
"still unamed" application.
I'm testing with latest mesa and drm on a XFX HD6950.
I'll try to bisect it later.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=54581
Summary: Radeon: Failed to parse relocation, gem object lookup
failed
Product: Drivers
Version: 2.5
Kernel Version: 3.8
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org
ReportedBy: mezin.alexander(a)gmail.com
Regression: No
When I run Xonotic on discrete gpu (DRI_PRIME=1), sometimes I see only black
screen, and dmesg is full of these messages:
[ 5172.729073] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed
0xa
[ 5172.729078] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
Radeon starts working again only after reboot
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=58372
Priority: medium
Bug ID: 58372
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [KMS][Cayman] Garbled screen and gpu crash with 6950
with drm-next
Severity: normal
Classification: Unclassified
OS: All
Reporter: serkan(a)hosca.com
Hardware: Other
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI
Created attachment 71594
--> https://bugs.freedesktop.org/attachment.cgi?id=71594&action=edit
dmesg with drm-next
Using linus + airlied's drm-next produces garbled screen and gpu crashes after
login.
Using mesa git and xf86-ati git.
--
You are receiving this mail because:
You are the assignee for the bug.