Hello Steffen,
Any update on version 16 ?
Best Wishes,
Leela Krishna Amudala.
On Mon, Nov 26, 2012 at 2:37 PM, Steffen Trumtrar
wrote:
> Hi!
>
> Changes since v14:
> - fix "const struct *" warning
> (reported by: Leela Krishna Amudala )
> - return -EINVAL when ht
On Wed, Dec 05, 2012 at 09:39:11AM +0200, Arto Merilainen wrote:
> On 12/04/2012 05:13 PM, Thierry Reding wrote:
> >+int drm_tegra_open(const char *path, struct drm_tegra **devicep)
> >+{
> >+ struct drm_tegra *device;
> >+ int err;
> >+
> >+ if (!path || !devicep)
> >+
2012/12/5 Inki Dae
>
>
> 2012/12/5 Inki Dae
>
>>
>>
>> 2012/12/5 Prathyush K
>>
>>>
>>>
>>>
>>> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>>>
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>> This patchset fixes a few issues with use of wait f
On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
>> Ok, but in comment 11 in the same thread you mention that reverting
>> this patch didn't fix the issue for you:
>>
>> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue.
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>>
>>
>>
>> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>>
>>>
>>>
>>> 2012/12/5 Inki Dae
>>>
2012/12/5 Prathyush K
> This patchset fixes a few issues with use of wait for vblank in
> exynos drm.
>
> Ple
2012/12/5 Prathyush K
>
>
>
> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>
>>
>>
>> 2012/12/5 Inki Dae
>>
>>>
>>>
>>> 2012/12/5 Prathyush K
>>>
This patchset fixes a few issues with use of wait for vblank in
exynos drm.
Please apply these three patches without "drm/ex
On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
> Ok, but in comment 11 in the same thread you mention that reverting
> this patch didn't fix the issue for you:
>
> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue."
The bisected commit was from between rc2 and rc3:
$ git
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/cf33f0c8/attachment.html>
Hi
2012/12/5 Prathyush K
> Hi,
>
> Please check the reference counts for framebuffers: This is for one
> modetest (without flipping)
>
> Bootup:
> [2.31] KP: drm_framebuffer_init edb86900 - fb0
> refcount 1
> [2.31] KP: drm_framebuffer_reference edb86900
On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>
>
> 2012/12/5 Inki Dae
>
>>
>>
>> 2012/12/5 Prathyush K
>>
>>> This patchset fixes a few issues with use of wait for vblank in
>>> exynos drm.
>>>
>>> Please apply these three patches without "drm/exynos: release fb pended
>>> by page flip"
>>>
On 05.12.2012, Lekensteyn wrote:
> > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
> > compositor. Now I'm trying to hit the bug again...
> Do you have a reliable reproduce method? As you can see in the linked bug it
> was caused by relatively low memory pressure combined wi
al say anyway, so if it is decided
to stick with inline functions I can find a way to live with them.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/21cdb9cc/attachment.pgp>
Hi,
Please check the reference counts for framebuffers: This is for one
modetest (without flipping)
Bootup:
[2.31] KP: drm_framebuffer_init edb86900 - fb0
refcount 1
[2.31] KP: drm_framebuffer_reference edb86900 - fb0
refcount 2
Modetest:
[ 26.56]
On 04.12.2012, Daniel Vetter wrote:
> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.
A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>> This patchset fixes a few issues with use of wait for vblank in
>> exynos drm.
>>
>> Please apply these three patches without "drm/exynos: release fb pended
>> by page flip"
>> patch.
>>
>> Patch 1: modify wait for vsync functions to use wait q
On 04.12.2012, Lekensteyn wrote:
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
> Date: Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable
Ok, b
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|kv
On Tue, Dec 4, 2012 at 9:41 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
>> Btw: which kernel is known to be the "last good one"?
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
>
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Marcelo Tosatti changed:
What|Removed |Added
CC||mtosatti at redhat.com
--- Comment
On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
> Btw: which kernel is known to be the "last good one"?
As mentioned in the linked bug [1], I bisected it to:
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson
Date: Thu Aug 23 13:12:52 2012 +0100
drm/i915: Use cpu
Changelog v2:
fix page fault issue.
- defer to unreference old fb to avoid page fault issue.
So with this fixup, new fb would be updated to hardware
prior to old fb unreferencing. And it removes unnecessary
patch, "drm/exynos: Unreference fb in exynos_disable_plane()"
Changelog v1:
This patch rele
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/e441e77b/attachment.html>
This patchset fixes a few issues with use of wait for vblank in
exynos drm.
Please apply these three patches without "drm/exynos: release fb pended by page
flip"
patch.
Patch 1: modify wait for vsync functions to use wait queues
This modifies the wait_for_vblank functions to use wait queues
thu
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/20121204/ca254407/attachment.html>
The crtc disable function should not disable the overlays if the
crtc is already in DPMS_OFF as this will lead to register access
when clock is off.
Also the crtc disable function should not call DPMS OFF of the
crtc. This is required to ensure we are able to wait for vblank
before freeing any fram
Currently wait_for_vblank is set as an overlay_op which is not
correct since wait for vblank is not dependant on any particular
overlay. It should be grouped with enable/disable vblank calls
inside manager_ops.
Also if wait for vblank is a manager op, the check for DPMS_OFF
of encoder can be remove
It is more optimium to use wait queues while waiting for vsync so
that the current task is put to sleep. This way, the task wont
hog the CPU while waiting. We use wait_event_timeout and not
an interruptible function since we dont want the function to exit
when a signal is pending (e.g. drm release)
2012/12/5 Inki Dae
>
>
> 2012/12/4 Prathyush K
>
>>
>>
>>
>> On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae wrote:
>>
>>> Changelog v2:
>>> fix page fault issue.
>>> - defer to unreference old fb to avoid page fault issue.
>>> So with this fixup, new fb would be updated to hardware
>>> prior to old f
On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
> On 03.12.2012, devendra.aaru wrote:
>
>> Add more CC's
>
> Thanks!
>
> This is a real showstopper for me, it occurs in every session now.
> Booting with "i915.i915_enable_rc6=0" doesn't help
https://bugs.freedesktop.org/show_bug.cgi?id=55984
i
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #6 from Scott Moreau ---
(In reply to comment #5)
> Created attachment 71019 [details] [review]
> Possible fix
>
> Does this patch help?
Yes this fixes the problem. The shaders work without error and the content is
rendered which ma
||
--
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/20121204/c1a79a64/attachment.html>
On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Instead of just printing "status updated from 1 to 2", make those enum
> numbers immediately readable.
>
> Signed-off-by: Damien Lespiau
I like, stupid me can never remember the magic values. For the pat
.freedesktop.org/archives/dri-devel/attachments/20121204/7cbe07d4/attachment.html>
e the fb.
> +*
> +* This means that memory region to the fb isn't accessed by the
> dma
> +* of this plane anymore.
> +*/
> + if (plane->fb)
> + drm_framebuffer_unreference(plane->fb);
> +
> + plane->fb = fb;
> +
> return 0;
> }
>
> @@ -215,6 +233,14 @@ static int exynos_disable_plane(struct drm_plane
> *plane)
> {
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> + /*
> +* Unreference the (current)fb if plane->fb is existed.
> +* In exynos_update_plane(), the new fb reference count can be
> bigger
> +* than 1. So it can't be removed for that reference count.
> +*/
> + if (plane->fb)
> + drm_framebuffer_unreference(plane->fb);
> +
> exynos_plane_dpms(plane, DRM_MODE_DPMS_OFF);
>
> return 0;
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5d0cc13a/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/0811e8d1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/15fbd707/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/48ba6823/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #5 from Tom Stellard ---
Created attachment 71019
--> https://bugs.freedesktop.org/attachment.cgi?id=71019&action=edit
Possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
_
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/c3127275/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/7fd455b6/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/224cc406/attachment.html>
On Tue, Dec 4, 2012 at 4:53 PM, wrote:
> From: Alex Deucher
>
> Need to use the adjusted mode since we are sending native
> timing and using the scaler for non-native modes.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/rade
On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae wrote:
> Changelog v2:
> fix page fault issue.
> - defer to unreference old fb to avoid page fault issue.
> So with this fixup, new fb would be updated to hardware
> prior to old fb unreferencing. And it removes unnecessary
> patch, "drm/exynos: Unreference
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/a3308fde/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51301
--- Comment #6 from Peter Hurley 2012-12-05
00:57:08 ---
This is filesystem/block or memory manager-related.
I just built -next-20121204 and by the end of the build a 10gb machine had <
100mb of zone DMA32 and < 70mb zone
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/20121204/1dc0a12c/attachment.html>
From: Alex Deucher
Need to use the adjusted mode since we are sending native
timing and using the scaler for non-native modes.
Signed-off-by: Alex Deucher
cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
https://bugzilla.kernel.org/show_bug.cgi?id=51301
--- Comment #4 from Peter Hurley 2012-12-04
16:48:22 ---
Not sure why I picked kvm/nouveau for this OOM ;)
Could be any number of apps over a 3.5 period...
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
GEM objects are backed by CMA, and
therefore the offset will be created along with the GEM anyway.
With Terje's upcoming rework that handles all the allocations in host1x
this should become more important, especially when the mapping is done
through the Tegra30's IOMMU.
I'll rework that. Thanks for the quick reply.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/4e69453b/attachment-0001.pgp>
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/20121204/56bb3c9b/attachment.html>
Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.
Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.
Signed-off-by: Thierry Reding
---
Makefile.am | 6 +-
configure.ac | 15 ++-
in
Hi,
I mentioned in a reply to Terje's patch series for 2D acceleration that
I had prototyped some libdrm support a few weeks back. I've spent a bit
of time cleaning it up and decided to post it for early review.
There's really not much interesting code here. A basic API is provided
along with two
From: Damien Lespiau
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/d
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/d1af243a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=37485
gsr.bugs changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
r_res;
> @@ -866,6 +887,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static struct exynos_mixer_ops mixer_ops = {
> /* manager */
> + .iommu_on = mixer_iommu_on,
> .enable_vblank = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = &pdev->dev;
> + ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5f8a7a94/attachment-0001.html>
Changelog v2:
move iommu support feature to mixer side.
And below is Prathyush's comment.
According to the new IOMMU framework for exynos sysmmus,
the owner of the sysmmu-tv is mixer (which is the actual
device that does DMA) and not hdmi.
The mmu-master in sysmmu-tv node is set as below in exynos
On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
>> Ok, but in comment 11 in the same thread you mention that reverting
>> this patch didn't fix the issue for you:
>>
>> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue.
; /* manager */
> + .iommu_on = mixer_iommu_on,
> .enable_vblank = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = &pdev->dev;
> + ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/170f18c4/attachment-0001.html>
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5e766406/attachment.html>
On Tue, Dec 4, 2012 at 4:53 PM, wrote:
> From: Alex Deucher
>
> Need to use the adjusted mode since we are sending native
> timing and using the scaler for non-native modes.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/
This patch changes the omapdrm KMS to bypass the omapdss "compat"
layer and use the core omapdss API directly. This solves some layering
issues that would cause unpin confusion vs GO bit status, because we
would not know whether a particular pageflip or overlay update has hit
the screen or not. N
On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
> On 04.12.2012, Daniel Vetter wrote:
>
> > Yeah, if anyone can somewhat reliably reproduce this
>
> Ok, I see. So the beginning would be to reliably reproduce the the
> hang. I have encountered it in any possbile situasjon, both when
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|kvm
From: Alex Deucher
Need to use the adjusted mode since we are sending native
timing and using the scaler for non-native modes.
Signed-off-by: Alex Deucher
cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/e6ba0598/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Marcelo Tosatti changed:
What|Removed |Added
CC||mtosa...@redhat.com
--- Comment #5
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing
On Mon, Dec 03, 2012 at 12:23:32PM -0700, Stephen Warren wrote:
> On 12/01/2012 07:58 AM, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
> ...
> >> I was thinking of definitions like this:
> >>
> >> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/ef1fb19d/attachment.html>
On 04.12.2012, Daniel Vetter wrote:
> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.
A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/a17f42a3/attachment.html>
On 04.12.2012, Lekensteyn wrote:
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
> Date: Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable
Ok, b
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/e0a0613f/attachment.html>
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/f1437b97/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #2 from Roland Scheidegger ---
Created attachment 71014
--> https://bugs.freedesktop.org/attachment.cgi?id=71014&action=edit
potential fixes for viewport trouble
I had something like this in mind. Untested though and all that viewp
On Tue, Dec 4, 2012 at 9:41 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
>> Btw: which kernel is known to be the "last good one"?
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
>
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #1 from Roland Scheidegger ---
Hmm this is odd I can't see anything wrong with the culling setup wrt fbos.
The viewport, window handling though seems somewhat bogus.
First, r200UpdateViewportOffset() has no callers (it is used in
rade
On 12/04/2012 11:50 AM, Stephen Warren wrote:
> On 12/03/2012 08:00 PM, Mark Zhang wrote:
>> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27
is 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/20121204/76afc31e/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Andreas Boll changed:
What|Removed |Added
Attachment #71005|text/plain |image/png
mime type|
On 11/28/2012 02:37 PM, Mark Zhang wrote:
> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>> Inst
On Tue, Dec 4, 2012 at 10:27 AM, Dave Airlie wrote:
> On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
>> On 03.12.2012, devendra.aaru wrote:
>>
>>> Add more CC's
>>
>> Thanks!
>>
>> This is a real showstopper for me, it occurs in every session now.
>> Booting with "i915.i915_enable_rc6=0" does
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #4 from Scott Moreau ---
Created attachment 71007
--> https://bugs.freedesktop.org/attachment.cgi?id=71007&action=edit
amnesia output with RADEON_DEBUG=fp
(In reply to comment #3)
> Could you run the program with the environment va
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #3 from Roland Scheidegger ---
FWIW the relevant commit fixing this bug was
de694b6b10b7ce23a00cd7296a955f162704ee62.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=34097
--- Comment #6 from Tomasz P. ---
on rv350 rendering in blender looks normal with mesa-git, is the situation
changed with current mesa ?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #3 from Tom Stellard ---
Could you run the program with the environment variable RADEON_DEBUG=fp and
then post the output.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>> I think there's room for letting Terje's complete knowledge of future
>> chips guide the design of the current code that's sent upstream.
>> Certainly we shouldn't add a ton of unnecessary abstraction layers
>> right now that aren't needed for
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #2 from Alex Deucher ---
If the game uses compressed textures, you may need to install libtxc_dxtn.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
On 12/03/2012 05:40 PM, Daniel Vetter wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang wrote:
>> I'm new in kernel development. Could you tell me or give me some
>> materials to read that why we need to align the size of IOCTL structures
>> to 64bit? I can understand if we're working in a 64bi
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Scott Moreau changed:
What|Removed |Added
Attachment #71005|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Priority: medium
Bug ID: 57888
Assignee: dri-devel@lists.freedesktop.org
Summary: Amnesia shader compiler errors on RV350
Severity: normal
Classification: Unclassified
OS: Li
On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Instead of just printing "status updated from 1 to 2", make those enum
> numbers immediately readable.
>
> Signed-off-by: Damien Lespiau
I like, stupid me can never remember the magic values. For the pat
On 03.12.2012, devendra.aaru wrote:
> Add more CC's
Thanks!
This is a real showstopper for me, it occurs in every session now.
Booting with "i915.i915_enable_rc6=0" doesn't help either..
On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
wrote:
> +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t size,
> +struct drm_tegra_bo **bop)
> +{
> + struct drm_tegra_gem_create args;
> + struct drm_tegra_bo *bo;
> + struct tegra_bo *pr
https://bugs.freedesktop.org/show_bug.cgi?id=37485
--- Comment #2 from Tomasz P. ---
(In reply to comment #1)
> Is this still an issue with current Mesa git?
I playing with supertuxcart today.The game is boring so I don't test all
tracks,but I cannot see any rendering errors with hyperz on. I ru
https://bugs.freedesktop.org/show_bug.cgi?id=36952
--- Comment #17 from Tomasz P. ---
I just instaled xscreensaver and run crackberg on rv350 / radeon 9600
agp.Normal memory usage nothing special.No warnings in logs. Animation works
without any artefacts or screen flashing.
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=51301
--- Comment #4 from Peter Hurley 2012-12-04
16:48:22 ---
Not sure why I picked kvm/nouveau for this OOM ;)
Could be any number of apps over a 3.5 period...
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
2012/12/5 Daniel Vetter
> On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae wrote:
> > Changelog v2:
> > fix page fault issue.
> > - defer to unreference old fb to avoid page fault issue.
> > So with this fixup, new fb would be updated to hardware
> > prior to old fb unreferencing. And it removes unneces
1 - 100 of 130 matches
Mail list logo
