https://bugs.freedesktop.org/show_bug.cgi?id=73127
Priority: medium
Bug ID: 73127
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [r600g] Possible memory leak when playing WoW with
CAICOS
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: rankincj(a)googlemail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 91298
--> https://bugs.freedesktop.org/attachment.cgi?id=91298&action=edit
Message log showing page allocation failure
I finally managed to build some libdrm-2.4.50 RPMs for Fedora 19 so that I
could compile a recent -git snapshot. The HEAD commit was:
author Alex Deucher <alexander.deucher(a)amd.com> 2013-12-24 20:22:31 (GMT)
committer Alex Deucher <alexander.deucher(a)amd.com> 2013-12-24 20:22:31
(GMT)
commit e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363 (patch) (side-by-side diff)
tree 51caa6afa79db9a733198f6bf5c6224c023fea2f
parent 35a34143026785e015adb906756651807de89bde (diff)
download mesa-e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363.zip
mesa-e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363.tar.gz
r600g: fix SUMO2 pci id
0x9649 is sumo2, not sumo.
This resulted in an eventual crash of WoW and Minecraft, apparently due to
memory exhaustion. (The messages log is attached).
Reverting to my previous build seemed to fix things:
author Marek Olšák <marek.olsak(a)amd.com> 2013-11-20 00:47:36 (GMT)
committer Marek Olšák <marek.olsak(a)amd.com> 2013-11-23 00:54:57 (GMT)
commit a3969aa125c8f61b093a5f5f69e8265a131051d0 (patch) (side-by-side diff)
tree aaa0b9350231b29d9dd51c49c5c86e1fe78a6096
parent 46cf80fb366cb14827724a7fea004e81400cc602 (diff)
download mesa-a3969aa125c8f61b093a5f5f69e8265a131051d0.zip
mesa-a3969aa125c8f61b093a5f5f69e8265a131051d0.tar.gz
mesa: initialize gl_renderbuffer::Depth in core
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73088
Priority: medium
Bug ID: 73088
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up
system after several minutes of use
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: appletorch(a)hotmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 91246
--> https://bugs.freedesktop.org/attachment.cgi?id=91246&action=edit
Xorg.log
Gone Home and Unigine Heaven 4.0 lock up my system after a few minutes of
operation when using this ppa:
https://launchpad.net/~oibaf/+archive/graphics-drivers/
When using mesa 9.2.1 provided in ubuntu 13.10 this does not occur with Gone
Home. Same lock up issue happens when using ubuntu 14.04 development with mesa
10.0.1. In all cases I had radeon.audio=1, radeon.dpm=1, and R600_DEBUG=sb.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=72732
Priority: medium
Bug ID: 72732
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Missing NULL check; radeon_drm_winsys.c
Severity: normal
Classification: Unclassified
OS: All
Reporter: freedesktop(a)treblig.org
Hardware: Other
Status: NEW
Version: unspecified
Component: Drivers/DRI/R600
Product: Mesa
I can sometime trigger a seg in do_winsys_init at radeon_drm_winsys.c on my
HD4350
There seems to be a simple missing NULL check:
214 version = drmGetVersion(ws->fd);
215 if (version->version_major != 2 ||
216 version->version_minor < 3) {
All the other users of drmGetVersion do a NULL check, so I suggest adding:
if (!version) {
fprintf(stderr,"%s: drmGetVersion NULL - bad fd (%d)?\n", __FUNCTION__,
ws->fd);
return FALSE;
}
I believe this to be part of the reason for:
https://bugzilla.redhat.com/show_bug.cgi?id=993463
why drmGetVersion is failing is a different matter (probably a bad fd at that
point - but why?) , but at least the NULL check would stop the seg.
Dave
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=72699
Priority: medium
Bug ID: 72699
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [llvm] Europa Universalis 4 closes its window and eats
all memory while loading
Severity: normal
Classification: Unclassified
OS: All
Reporter: nikoamia(a)gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Hello,
While using new llvm from svn (rev. 197173) Europa Universalis 4 closes its
window on "Loading Graphics" stage but retains as process and eats up all
memory and swap, so it is needed to kill it manually. Problem disappears after
reverting to rev. 196300.
Kernel: 3.12.5, was also tested on earlier
Mesa: git 60139.40070e7
Video: Mobility Radeon HD 5650M
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=72387
Priority: medium
Bug ID: 72387
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Tearing at one specific part of the screen on CAYMAN
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v10lator(a)myway.de
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
I see this with games as well as on my (composited) desktop when scrolling very
fast in firefox, for example.
Let me try to explain:
If you would cut the screen horizontally in 3 pieces the line between the
middle and the down piece is where the tearing appears. It appears even with
vsync.
I tried to capture it with gtk-rekordmydesktop but for some reason the video is
tear-free.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71923
Priority: medium
Bug ID: 71923
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Screen corruption when watching VDPAU-accelerated H264
video
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: kaszak696(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: 9.2
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 89641
--> https://bugs.freedesktop.org/attachment.cgi?id=89641&action=edit
Dmesg log with the described errors
Hi, i have a trouble watching some H264 videos when using VDPAU acceleration.
What happens is the screen gets completly corrupted (gray bars cover the whole
screen) when player plays a certain frame in the video. It always happens at
the same point of the video, for some videos it doesn't happen at all. I
managed to blindly save smesg output to a file when this happened, and it's
filled with these kinds of messages:
[ 47.595028] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 48.303022] Forbidden register 0x0020 in cs at 9
[ 48.303029] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 56.146022] Forbidden register 0x0024 in cs at 9
[ 56.146029] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 57.148021] Forbidden register 0x0028 in cs at 9
[ 57.148028] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 57.523022] Forbidden register 0x0024 in cs at 9
[ 57.523030] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
I'm using Arch Linux with 3.12.1-ck at the moment, but it also happened on
3.11-ck and 3.11 vanilla.
lspci reports this card name, it's a Radeon 4570:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV710/M92 [Mobility Radeon HD 4530/4570/545v]
I'm using the newest stable mesa 9.2.3 and xf86-video-ati 7.2.0. The issue
happens with mpv and mplayer.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71812
Priority: medium
Bug ID: 71812
Assignee: dri-devel(a)lists.freedesktop.org
Summary: VDPAU: MPEG-4 ASP Garbling/Corruption
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: adam(a)aphirst.karoo.co.uk
Hardware: x86-64 (AMD64)
Status: NEW
Version: 9.2
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 89489
--> https://bugs.freedesktop.org/attachment.cgi?id=89489&action=edit
Playback log from mpv-player
I initially reported this over at the FFmpeg Trac, so just in case I
accidentally omit to mention something I've already considered (or just for
reference), that's over at https://ffmpeg.org/trac/ffmpeg/ticket/3138
== Relevant Software / Hardware: ==
* AMD E2-1800 APU (/w Radeon HD 7340), i.e. PALM
* Linux 3.12 (Distro: Arch)
* FFmpeg 2.1
* mesa, mesa-libgl & ati-dri 9.2.3
* mplayer r36498, mpv 0.2.3 & VLC 2.1.1
== Summary: ==
Some files encoded into "MPEG-4 part 2" (seemingly, those using GMC, if zgreg's
hunch on #radeon is anything to go by) render/decode incorrectly using VDPAU
hardware-decoding on my AMD chipset. The files work fine using software
decoding, and worked fine back when using Catalyst & VA-API (which should mean
that the files and the hardware are fine).
By "incorrectly", I don't mean complete garbage. About half of the image
renders fine, it's just that between reference frames it progressively garbles
into a bright-green mess in heavily-updated areas. I'll try to catch a decent
screenshot demonstrating this when I can. In the meantime, I've put a sample
affected file up on my Dropbox account:
https://dl.dropboxusercontent.com/u/3219541/harlock-ep20.mkv
I'll re-attach here some mplayer/mpv logs, and some output from vdpauinfo and
ffprobe; and I'll also attach output from glxinfo. If there's anything extra I
ought to provide, please say so :)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71796
Priority: medium
Bug ID: 71796
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Hardware assisted (VDPAU) decoding of MPEG-2 causes
GPU lockup - Radeon HD6950
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: libgradev(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Created attachment 89477
--> https://bugs.freedesktop.org/attachment.cgi?id=89477&action=edit
DMESG output showing hardware info and lockup.
Playing back MPEG-2 compressed video causes a GPU lockup and reset. This
happens about 9 times out of 10 upon start of playback - the other time
playback starts fine.
About 4 out of 5 times the reset is successful and playback begins a catchup
phase before continuing normally - otherwise it results in a complete system
freeze.
If playback actually starts it continues fine.
Using VDPAU assisted playback via XBMC. Using software only playback works fine
every time. h264 playback seems unaffected.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71326
Priority: medium
Bug ID: 71326
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [r600g] Texture artifacts when viewed from a distance
in WoW
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: rankincj(a)googlemail.com
Hardware: x86 (IA32)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Dual P4 Xeon, 2 GB RAM, Mesa HEAD is:
commit 110009302bddb4c42a5b3ed5ca451d6bb50a06a0
Author: Fabio Pedretti <fabio.ped(a)libero.it>
Date: Wed Nov 6 10:55:28 2013 +0100
gallium: fix build on GNU/kFreeBSD
I am currently playing WoW with my HD4670 (AGP), and I am noticing that various
textures are being rendered incorrectly when viewed beyond a certain distance.
However, as I approach the badly rendered area, all of the artifacts disappear!
It's as if my character is surrounded by an invisible bubble, and everything
within the bubble becomes correctly rendered. (The visual effect reminds me of
the "Genesis wave" demonstration video from "Star Trek: The Wrath of Khan" - if
that means anything to anyone...;-).)
This problem is not visible with the HD4890 on my 64 bit machine.
I have attached a couple of screenshots showing the problem.
--
You are receiving this mail because:
You are the assignee for the bug.