https://bugs.freedesktop.org/show_bug.cgi?id=54341
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=54341
--- Comment #1 from Marco 2012-09-01 21:45:41 UTC ---
Sorry, my mistake!
I wrote something wrong in the .drirc file leading to the crash.
Removing .drirc makes glxgears (and all othe GL applications) start fine.
Sorry for the noise.
--
On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky wrote:
> On 2012-09-01 11:28, Arjan van de Ven wrote:
>>
>> On 9/1/2012 11:26 AM, Ben Widawsky wrote:
>>>
>>> On 2012-08-30 04:26, Daniel Vetter wrote:
We've had and still have too many issues where the gpu turbot doesn't
quite to what
On Sat, 01 Sep 2012 11:35:13 -0700, Ben Widawsky wrote:
> I have no problem with Daniel's patch. It's just a matter of cutting
> through some scheduler BS of "when the GPU wants to change frequency"
> vs. "when we actually change the GPU frequency." I think *both* are
> interesting.
We
On 2012-09-01 20:06, Arjan van de Ven wrote:
> On 9/1/2012 8:05 PM, Ben Widawsky wrote:
>> , from a single trace event you should know the current frequency
>> and the previous frequency.
> but if you're doing a heavy game or whatever... you may stay at the
> highest all the time,
> and I get no
On 9/1/2012 8:05 PM, Ben Widawsky wrote:
> , from a single trace event you should know the current frequency and the
> previous frequency.
but if you're doing a heavy game or whatever... you may stay at the highest all
the time,
and I get no information...
same for getting stuck or being always
On 2012-09-01 19:44, Arjan van de Ven wrote:
> On 9/1/2012 6:36 PM, Ben Widawsky wrote:
>
>> It depends on what you're trying to measure. I think this patch is
>> quite useful but I think I'll make you defend your patch now since
>> you're the maintainer and you took
>> your own patch and you're
On 9/1/2012 6:36 PM, Ben Widawsky wrote:
> It depends on what you're trying to measure. I think this patch is quite
> useful but I think I'll make you defend your patch now since you're the
> maintainer and you took
> your own patch and you're shooting down my idea. So please tell me what
>
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sat, Sep 1, 2012 at 5:58 PM, Rob Clark wrote:
> yeah, nuclear-pageflip would be associated only w/ a single crtc.
> Actually I was kinda assuming atomic-modeset was too.. ie. moving a
> plane from one crtc to another would be two ioctls, one to remove it
> from first crtc, one to add to the
On 2012-09-01 12:14, Daniel Vetter wrote:
> On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky
> wrote:
>> On 2012-09-01 11:28, Arjan van de Ven wrote:
>>>
>>> On 9/1/2012 11:26 AM, Ben Widawsky wrote:
On 2012-08-30 04:26, Daniel Vetter wrote:
>
> We've had and still have too many
On 2012-09-01 12:22, Chris Wilson wrote:
> On Sat, 01 Sep 2012 11:35:13 -0700, Ben Widawsky
> wrote:
>> I have no problem with Daniel's patch. It's just a matter of cutting
>> through some scheduler BS of "when the GPU wants to change
>> frequency"
>> vs. "when we actually change the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=34874
--- Comment #1 from Andreas Boll 2012-09-01
16:21:55 UTC ---
--enable-shared-glapi is now enabled by default.
Is this still an issue with current mesa git master or mesa git 9.0 branch?
--
Configure bugmail:
On Fri, Aug 31, 2012 at 09:34:17AM +0200, Paul Rolland wrote:
> Hello,
>
> I've just found this error in my logs. It occured once so far, but I never
> got it before with 3.5.0, so I'm reporting it.
>
> [drm] capturing error event; look for more information
> in /debug/dri/0/i915_error_state
>
On Thu, Aug 30, 2012 at 10:34:23AM -0700, Aaron Plattner wrote:
> 4. There's no mechanism for double buffering the output sink
>
> RandR allocates one pixmap on the output source screen and sets up tracking so
> the source driver can copy the screen into the shared pixmap.
> However, the sink
On Fri, Aug 31, 2012 at 05:47:13PM -0500, Rob Clark wrote:
> On Wed, Jun 27, 2012 at 5:24 AM, wrote:
> > From: Ville Syrj?l?
> >
> > First draft.
> >
> > The ioctl simply takes a list of object IDs and property IDs and their
> > values. For setting values to blob properties, the property value
On Sat, Sep 1, 2012 at 11:56 AM, Daniel Vetter wrote:
> On Sat, Sep 1, 2012 at 5:58 PM, Rob Clark wrote:
>> yeah, nuclear-pageflip would be associated only w/ a single crtc.
>> Actually I was kinda assuming atomic-modeset was too.. ie. moving a
>> plane from one crtc to another would be two
> object interface, so that Optimus-based laptops can use our driver to drive
> the
> discrete GPU and display on the integrated GPU. The good news is that I've
> got
> a proof of concept working.
Don't suppose you'll be interested in adding the other method at some
point as well? since saving
https://bugs.freedesktop.org/show_bug.cgi?id=54347
--- Comment #1 from Alex Deucher 2012-09-01 12:58:09 UTC
---
vdpau is handled by the vdpau state tracker in mesa.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=54347
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=42974
Marcin Slusarz changed:
What|Removed |Added
CC||marcin.slusarz at gmail.com
---
On 2012-09-01 11:28, Arjan van de Ven wrote:
> On 9/1/2012 11:26 AM, Ben Widawsky wrote:
>> On 2012-08-30 04:26, Daniel Vetter wrote:
>>> We've had and still have too many issues where the gpu turbot
>>> doesn't
>>> quite to what it's supposed to do (or what we want it to do).
>>>
>>> Adding a
On 9/1/2012 11:26 AM, Ben Widawsky wrote:
> On 2012-08-30 04:26, Daniel Vetter wrote:
>> We've had and still have too many issues where the gpu turbot doesn't
>> quite to what it's supposed to do (or what we want it to do).
>>
>> Adding a tracepoint to track when the desired gpu frequence changes
On 2012-08-30 04:26, Daniel Vetter wrote:
> We've had and still have too many issues where the gpu turbot doesn't
> quite to what it's supposed to do (or what we want it to do).
>
> Adding a tracepoint to track when the desired gpu frequence changes
> should help a lot in characterizing and
On Sat, Sep 1, 2012 at 6:12 AM, Daniel Vetter wrote:
> On Fri, Aug 31, 2012 at 05:47:13PM -0500, Rob Clark wrote:
>> On Wed, Jun 27, 2012 at 5:24 AM, wrote:
>> > From: Ville Syrj?l?
>> >
>> > First draft.
>> >
>> > The ioctl simply takes a list of object IDs and property IDs and their
>> >
https://bugs.freedesktop.org/show_bug.cgi?id=39222
--- Comment #15 from Andreas Boll 2012-09-01
08:43:08 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > The xtended timing interface that mplayer2 uses
> > (vdp_presentation_queue_get_time) is currently not implemented.
> >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=53490
Joeri Capens changed:
What|Removed |Added
Attachment #65574|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=53490
--- Comment #12 from Joeri Capens 2012-09-01 00:56:43 UTC
---
Bit 8 of tile_config (CHANSIZE?) needs to be 1 to make the bumpmap corruption
disappear on my system.
Before 416a2bd274566a6f607a271f524b2dc0b84d9106 this used to be calculated from
https://bugs.freedesktop.org/show_bug.cgi?id=54341
Bug #: 54341
Summary: Glxgears crash with latest git (9.0)
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=39222
--- Comment #15 from Andreas Boll andreas.boll@gmail.com 2012-09-01
08:43:08 UTC ---
(In reply to comment #14)
(In reply to comment #13)
The xtended timing interface that mplayer2 uses
(vdp_presentation_queue_get_time) is currently not
Fixes the following checkpatch warnings:
WARNING: sizeof *res should be sizeof(*res)
WARNING: sizeof res-regul_bulk[0] should be sizeof(res-regul_bulk[0])
WARNING: sizeof *res should be sizeof(*res)
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c |
Fixes the following checkpatch warnings:
WARNING: sizeof filter_y_horiz_tap8 should be sizeof(filter_y_horiz_tap8)
WARNING: sizeof filter_y_vert_tap4 should be sizeof(filter_y_vert_tap4)
WARNING: sizeof filter_cr_horiz_tap4 should be sizeof(filter_cr_horiz_tap4)
Signed-off-by: Sachin Kamat
On Fri, Aug 31, 2012 at 05:47:13PM -0500, Rob Clark wrote:
On Wed, Jun 27, 2012 at 5:24 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
First draft.
The ioctl simply takes a list of object IDs and property IDs and their
values. For setting
On Thu, Aug 30, 2012 at 10:34:23AM -0700, Aaron Plattner wrote:
4. There's no mechanism for double buffering the output sink
RandR allocates one pixmap on the output source screen and sets up tracking so
the source driver can copy the screen into the shared pixmap.
However, the sink driver
On Fri, Aug 31, 2012 at 09:34:17AM +0200, Paul Rolland wrote:
Hello,
I've just found this error in my logs. It occured once so far, but I never
got it before with 3.5.0, so I'm reporting it.
[drm] capturing error event; look for more information
in /debug/dri/0/i915_error_state
i915:
https://bugzilla.kernel.org/show_bug.cgi?id=42974
Marcin Slusarz marcin.slus...@gmail.com changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=54347
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=54347
--- Comment #1 from Alex Deucher ag...@yahoo.com 2012-09-01 12:58:09 UTC ---
vdpau is handled by the vdpau state tracker in mesa.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
On Sat, Sep 1, 2012 at 6:12 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Aug 31, 2012 at 05:47:13PM -0500, Rob Clark wrote:
On Wed, Jun 27, 2012 at 5:24 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
First draft.
The ioctl simply takes a
https://bugs.freedesktop.org/show_bug.cgi?id=34874
--- Comment #1 from Andreas Boll andreas.boll@gmail.com 2012-09-01
16:21:55 UTC ---
--enable-shared-glapi is now enabled by default.
Is this still an issue with current mesa git master or mesa git 9.0 branch?
--
Configure bugmail:
On Sat, Sep 1, 2012 at 5:58 PM, Rob Clark robdcl...@gmail.com wrote:
yeah, nuclear-pageflip would be associated only w/ a single crtc.
Actually I was kinda assuming atomic-modeset was too.. ie. moving a
plane from one crtc to another would be two ioctls, one to remove it
from first crtc, one
On Sat, Sep 1, 2012 at 11:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Sep 1, 2012 at 5:58 PM, Rob Clark robdcl...@gmail.com wrote:
yeah, nuclear-pageflip would be associated only w/ a single crtc.
Actually I was kinda assuming atomic-modeset was too.. ie. moving a
plane from one crtc
On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky b...@bwidawsk.net wrote:
On 2012-09-01 11:28, Arjan van de Ven wrote:
On 9/1/2012 11:26 AM, Ben Widawsky wrote:
On 2012-08-30 04:26, Daniel Vetter wrote:
We've had and still have too many issues where the gpu turbot doesn't
quite to what it's
On Sat, 01 Sep 2012 11:35:13 -0700, Ben Widawsky b...@bwidawsk.net wrote:
I have no problem with Daniel's patch. It's just a matter of cutting
through some scheduler BS of when the GPU wants to change frequency
vs. when we actually change the GPU frequency. I think *both* are
interesting.
https://bugs.freedesktop.org/show_bug.cgi?id=54341
Matt Turner matts...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 9/1/2012 11:26 AM, Ben Widawsky wrote:
On 2012-08-30 04:26, Daniel Vetter wrote:
We've had and still have too many issues where the gpu turbot doesn't
quite to what it's supposed to do (or what we want it to do).
Adding a tracepoint to track when the desired gpu frequence changes
should
On 2012-09-01 12:22, Chris Wilson wrote:
On Sat, 01 Sep 2012 11:35:13 -0700, Ben Widawsky b...@bwidawsk.net
wrote:
I have no problem with Daniel's patch. It's just a matter of cutting
through some scheduler BS of when the GPU wants to change
frequency
vs. when we actually change the GPU
On 2012-09-01 12:14, Daniel Vetter wrote:
On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky b...@bwidawsk.net
wrote:
On 2012-09-01 11:28, Arjan van de Ven wrote:
On 9/1/2012 11:26 AM, Ben Widawsky wrote:
On 2012-08-30 04:26, Daniel Vetter wrote:
We've had and still have too many issues where
On 2012-09-01 19:44, Arjan van de Ven wrote:
On 9/1/2012 6:36 PM, Ben Widawsky wrote:
It depends on what you're trying to measure. I think this patch is
quite useful but I think I'll make you defend your patch now since
you're the maintainer and you took
your own patch and you're shooting
49 matches
Mail list logo
