Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6357
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8348
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 19:05 ---
More
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8348
Summary: [MESA 6.5.1] PPracer causes r300 driver to assert
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=5376
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 18:32 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4799
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 17:51 ---
I'll
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4799
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 16:57 ---
I hop
On Mon, 2006-09-18 at 16:46 +0200, Thomas Hellström wrote:
> Unfortunately this leads to rather costly cache and TLB flushes.
> Particularly on SMP.
>
> I think Keith was referring to the drawbacks with buffers pinned in
> AGP or VRAM space.
What about a futex-like approach:
A shared are mapped
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4799
[EMAIL PROTECTED] changed:
What|Removed |Added
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
>
> Extending the memory manager would involve adding an ability to lock and
> unlock surfaces to VRAM/AGP addresses - this would require kernel
> interaction I guess. The driver would have to lock the surfaces then be
> free
> Actually, the TTM memory manager already does this,
> but also changes the caching policy of the linear kernel map.
The later is not portable unfortunately, and can have other serious
performance impacts.
Typically, the kernel linear map is mapped using larger page sizes, or
in some cases, ev
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8246
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 14:24 ---
wow o
Aapo Tahkola wrote:
> On Sun, 13 Aug 2006 02:17:40 +0200
> Rune Petersen <[EMAIL PROTECTED]> wrote:
>
>> Roland Scheidegger wrote:
>>> Rune Petersen wrote:
Roland Scheidegger wrote:
fragment.position input is not implemented yet. fglrx driver parses
it from VP to FP via a texcoord r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=5376
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 11:23 ---
Follo
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6357
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 09:28 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6357
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 08:44 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6357
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 08:18 ---
The p
Keith Whitwell wrote:
>Thomas Hellström wrote:
>
>
>>Keith Whitwell wrote:
>>
>>
>>>Thomas Hellstrom wrote:
>>>
>>>
>>>
linux-core/drmP.h | 13 +++-
linux-core/drm_bo.c | 31 ++-
linux-core/drm_fence.c | 128
+++--
Benjamin Herrenschmidt wrote:
Yes, this is really a different hardware model than we're used to
dealing with for DRI drivers, however it's not a problem for the most
part - if you don't need to take the lock, don't. But then you need
some other way of dealing with the other hacky st
Thomas Hellström wrote:
> Keith Whitwell wrote:
>> Thomas Hellstrom wrote:
>>
>>> linux-core/drmP.h | 13 +++-
>>> linux-core/drm_bo.c | 31 ++-
>>> linux-core/drm_fence.c | 128
>>> +++-
>>> linux-core/drm_lock.c |4 -
>
Keith Whitwell wrote:
Thomas Hellstrom wrote:
linux-core/drmP.h | 13 +++-
linux-core/drm_bo.c | 31 ++-
linux-core/drm_fence.c | 128 +++-
linux-core/drm_lock.c |4 -
Thomas,
Can you be more spec
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=5376
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 07:22 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=5376
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 06:52 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=5376
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 06:06 ---
Is th
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8273
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 05:48 ---
(In r
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8299
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 05:30 ---
Ok, a
I know the line that causing this.This code :if (m->m_flags & MUTEX_FLAGS_PRIVATE) PANIC("Recurse on a private mutex.");at file "/usr/src/lib/libpthread/thread/thr_mutex.c" line 1002 prevent the recursive to run.
I think I whould report it to freebsd instead here.Or may be the code a
>From: "Alex Deucher" <[EMAIL PROTECTED]>
>
>If you have any way of working with hardware vendors to get them to
>provide specs, or even better, open source driver code, it would be
>much appreciated.
The more you ask, the less likely you get them.
The driver code includes software algorithms whi
> Yes, this is really a different hardware model than we're used to
> dealing with for DRI drivers, however it's not a problem for the most
> part - if you don't need to take the lock, don't. But then you need
> some other way of dealing with the other hacky stuff we get away with by
>loc
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6357
--- Additional Comments From [EMAIL PROTECTED] 2006-09-18 01:50 ---
(In r
Dave Airlie wrote:
>> Obviously, we are interested in making use of the new DRM memory manager
>> on that hardware. Now if I understand how it works correctly, this new
>> memory manager allocates opaque handles which are not to be used as
>> offset in memory, because they are not. Therefore, a tra
30 matches
Mail list logo