bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/7f52e010/attachment.html>
pau was compiled with dri2proto support, but
is there a way to confirm?
--
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/20130824/09
=76 R600_SB_DSKIP_END=76 R600_SB_DSKIP_MODE=2
produces glitches.
--
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/20130824/67f5fb80/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/825c3f33/attachment.html>
A basic, no-frills recovery mechanism in case the gpu gets wedged. We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple. This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.
Add initial support for a3xx 3d core.
So far, with hardware that I've seen to date, we can have:
+ zero, one, or two z180 2d cores
+ a3xx or a2xx 3d core, which share a common CP (the firmware
for the CP seems to implement some different PM4 packet types
but the basics of cmdstream
Generated from rnndb files in:
https://github.com/freedreno/envytools
Keep this split out as a separate commit to make it easier to review the
actual driver.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 1438
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared
Generated from rnndb files in:
https://github.com/freedreno/envytools
Keep this split out as a separate commit to make it easier to review the
actual driver.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 502
drivers/gpu/drm/msm/dsi/mmss_cc.xml.h |
This patchset can also be found here, for easier browsing:
http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next
git://people.freedesktop.org/~robclark/linux drm-next
In userspace, I've a libdrm branch with libdrm_freedreno updated to
work on top of either this driver or the downstream
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/2b1009da/attachment.html>
vel/attachments/20130824/951f0c89/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/4ad137fd/attachment.html>
p.org/archives/dri-devel/attachments/20130824/ea051a96/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/8514e856/attachment.html>
On 15/07/2013 10:39, Maarten Lankhorst wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>> wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks
>>> decoding 1080p
>>> VDPAU at boot speed. With this patch
Em Thu, 22 Aug 2013 18:00:14 +0200
Wolfram Sang escreveu:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register
intro start (so latter), new shader dump
attached
--
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/20130824/cf487ad5/attachment.html>
On Fri, Aug 23, 2013 at 11:46:02PM +0300, Dan Carpenter wrote:
> There is a typo so deadlocks on error instead of unlocking.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7ae2bfc..276d470 100644
> ---
On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian H?gsberg
>
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
>
> Cc: Daniel Vetter
> Signed-off-by: Kristian H?gsberg
> Signed-off-by: David
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/8c2f7879/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130824/1a964fbe/attachment.html>
There is a typo so deadlocks on error instead of unlocking.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7ae2bfc..276d470 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -552,7 +552,7 @@ fail:
*/
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See
On 15/07/2013 10:39, Maarten Lankhorst wrote:
Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With
https://bugs.freedesktop.org/show_bug.cgi?id=68224
--- Comment #6 from Laurent carlier lordhea...@gmail.com ---
(In reply to comment #5)
Created attachment 84544 [details] [review]
LLVM Patch #3
If you apply all three of these patches, does it fix the crash?
It's better, now it crash before
https://bugs.freedesktop.org/show_bug.cgi?id=68224
--- Comment #7 from Laurent carlier lordhea...@gmail.com ---
Created attachment 84551
-- https://bugs.freedesktop.org/attachment.cgi?id=84551action=edit
Shader dump with 3 patches applied
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=68503
Priority: medium
Bug ID: 68503
Assignee: dri-devel@lists.freedesktop.org
Summary: Graphical glitches in Serious Sam 3 when SB is enabled
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=68503
--- Comment #1 from kwah...@wp.pl ---
Pics (if you cannot open the atachment):
http://postimg.org/image/rpg5b0oz3/
http://postimg.org/image/h5acgr97n/
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #4 from Peter Kraus peter.kr...@geeksonbikes.net ---
Hello,
did not have a time to bisect yet (seems to be a bit more complex than I
thought, or I'm just daft).
The behaviour is not fixed by yesterday's game update, and it's not
https://bugs.freedesktop.org/show_bug.cgi?id=68503
--- Comment #2 from Vadim Girlin pt...@yandex.ru ---
Please attach the output with R600_DEBUG=sb,ps,vs.
Could you also record the GL trace that reproduces the issue using apitrace -
http://apitrace.github.io/
You can just upload the trace if
https://bugs.freedesktop.org/show_bug.cgi?id=68503
--- Comment #3 from kwah...@wp.pl ---
Created attachment 84563
-- https://bugs.freedesktop.org/attachment.cgi?id=84563action=edit
output with R600_DEBUG=sb,ps,vs
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=68503
--- Comment #4 from kwah...@wp.pl ---
Created attachment 84566
-- https://bugs.freedesktop.org/attachment.cgi?id=84566action=edit
shader no 76 enabled
Seems that shader number 76 is the culprit.
R600_DEBUG=sb R600_SB_DSKIP_START=76
This patchset can also be found here, for easier browsing:
http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next
git://people.freedesktop.org/~robclark/linux drm-next
In userspace, I've a libdrm branch with libdrm_freedreno updated to
work on top of either this driver or the downstream
A basic, no-frills recovery mechanism in case the gpu gets wedged. We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple. This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.
https://bugs.freedesktop.org/show_bug.cgi?id=64582
--- Comment #4 from John john.etted...@gmail.com ---
Same issue here:
Inconsistency detected by ld.so: dl-close.c: 771: _dl_close: Assertion
`map-l_init_called' failed!
Mesa 9.2rc2 (same with rc1), dri2proto 2.8, libvdpau 0.7.
I believe my
https://bugs.freedesktop.org/show_bug.cgi?id=68503
--- Comment #5 from Vadim Girlin pt...@yandex.ru ---
Created attachment 84573
-- https://bugs.freedesktop.org/attachment.cgi?id=84573action=edit
patch
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com ---
After bisect in one direction, I've ended up with the following commit:
f90555cbe629e14c6af1dcec1933a3833ecd321f is the first bad commit
commit
38 matches
Mail list logo
