https://bugs.freedesktop.org/show_bug.cgi?id=31615
Summary: Some textures broken on r600g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Daniel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31613
Daniel changed:
What|Removed |Added
CC||di...@betriebsdirektor.de
--- Comment #1 from D
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Summary: Radeon/Compiz: 'failed to attach dri2 front buffer',
error case not handled
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
https://bugs.freedesktop.org/show_bug.cgi?id=31619
Summary: Desktop freezes quickly every now and then with dynpm
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my direct-gtt pat
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #1 from Ernst Sjöstrand 2010-11-14 09:07:37 PST
---
It also happens with the drm-next kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2010-11-10-maverick/
It does not happen with Ubuntu Mavericks default 2.6.35 ker
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #2 from Alex Deucher 2010-11-14 09:19:58 PST ---
This is due to the pm code holding a number of locks while waiting to update
the clocks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #11 from Maximiliano Castañón 2010-11-14
15:23:12 PST ---
Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=31475
I believe it's another project related to that problem, probably xrandr with
the resize screen...
--
Conf
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov
---
Compile tested.
drivers/gpu/drm/radeon/radeon_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 delet
Hi, Daniel,
My main concerns previously for embedding GEM objects as user-space
references for TTM has been twofold and implementation specific.
1) The locking has been using global mutexes where local spin- or RCU
locks have been more appropriate. It looks like this has finally been /
is fi
On 11/12/2010 06:36 PM, Daniel Vetter wrote:
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be do
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Summary: Some textures broken on r600g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Daniel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31613
Daniel changed:
What|Removed |Added
CC||direx at betriebsdirektor.de
--- Comment #1 fro
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Summary: Radeon/Compiz: 'failed to attach dri2 front buffer',
error case not handled
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
https://bugs.freedesktop.org/show_bug.cgi?id=31619
Summary: Desktop freezes quickly every now and then with dynpm
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson
wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek googlemail.com> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #1 from Ernst Sj?strand 2010-11-14 09:07:37
PST ---
It also happens with the drm-next kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2010-11-10-maverick/
It does not happen with Ubuntu Mavericks default 2.6.35 ker
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #2 from Alex Deucher 2010-11-14 09:19:58 PST
---
This is due to the pm code holding a number of locks while waiting to update
the clocks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek
wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #11 from Maximiliano Casta??n 2010-11-14
15:23:12 PST ---
Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=31475
I believe it's another project related to that problem, probably xrandr with
the resize screen...
--
Conf
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov
---
Compile tested.
drivers/gpu/drm/radeon/radeon_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 delet
50 matches
Mail list logo
