If ttm_bo_move_memcpy was instructed to move a non-populated ttm to
io memory, it would first populate the ttm, then move the data and then
destroy the ttm. That's stupid. However, some drivers might have relied on
this to clear io memory from old stuff. So instead of a NOP, which would
be the most
Otherwise we risk that the 2nd part of the line ends up on a line of
it's own, which means a kernel dmesg line without a log level. This
then upsets the dmesg checker in piglit.
Only really happens in some of the truly nasty igt testcases which
race cache dropping (through debugfs) with other gem
desktop.org/archives/dri-devel/attachments/20131117/a8c1f829/attachment.pgp>
On 11/17/2013 06:43 PM, Keith Packard wrote:
> Emil Velikov writes:
>
>> On 18/11/13 01:08, Keith Packard wrote:
>>> libudev doesn't have a stable API/ABI, and if the application wants to use
>>> one
>>> version, we'd best not load another into libGL.
>>>
>>> Signed-off-by: Keith Packard
>>> --
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/3fe455c4/attachment.html>
iving 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/20131117/4b2b2991/attachment.html>
olean/bool?
Sure, but I was too lazy to figure out which kind of bool belongs in
that part of mesa...
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not avai
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
Sorry for the patch spam; I hadn't rebased in a while and there was a
configure.ac conflict. Here's a version which should apply cleanly
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/ab1b3665/attachment.html>
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
configure.ac | 5 +--
src/glx/dri3_common.c | 106 +++---
2 files changed, 94 ins
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/20324cbd/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/e4538726/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/0d878ebb/attachment.html>
problem, if you play local content and for example
resample audio.
--
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/20131117/89210f17/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/64e4810d/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/4b150a03/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131117/d5e99bc8/attachment.html>
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/20131117/75d73f6a/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/f6596936/attachment.html>
ocation is okay (according to the comment in
radeon_gtt_location it should be placed before or after VRAM) In PCI
mode it ends at 0x97FF and VRAM starts directly after at
0x9800. In AGP mode GTT and VRAM are completely unrelated.
Other than that it looks like the alignm
20 matches
Mail list logo
