What do you think?
We try to keep #ifdef's out of the code and in drm_compat.h instead.
Something like
#if linuxversion = 2.6.27
#define drm_on_each_cpu(handler, data, wait) ...
#else
...
#endif
and then just user drm_on_each_cpu in the code.
I'd prefer not to do that
Wow, there are a lot ifdefs in the code.
Exactly what I was thinking when I saw the patch. ;) But I was too lazy to
think for a solution. Thanks for doing that for me. :)
Here comes the result.
Thanks for looking at this, but I dislike both of these ideas, I'll just
move the old nopfn
On Tue, Jul 29, 2008 at 5:31 PM, Andrew Morton
[EMAIL PROTECTED] wrote:
On Mon, 28 Jul 2008 22:32:45 +0200 Thomas Hellstr__m [EMAIL PROTECTED]
wrote:
Dave Airlie wrote:
On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby [EMAIL PROTECTED] wrote:
drm_lock_take(); and drm_lock_free(); are called
On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby [EMAIL PROTECTED] wrote:
drm_lock_take(); and drm_lock_free(); are called from
drm_locked_tasklet_func(); which disables interrupts when grabbing its
spinlock.
Don't allow these locking functions to re-enable interrupts when
the tasklet expects
I've started to see hangs with X on an ATI RS690 with a 2.6.26 kernel.
The symptoms are that load average goes up, X stops accepting keypresses
or mouse clicks, but the cursor still moves around the screen in
response to the mouse being moved. I can't switch to a VT but can ssh in
remotely
/radeon/radeon_cp.c |2 +-
include/drm/drmP.h |1 +
3 files changed, 7 insertions(+), 1 deletions(-)
commit 242e3df80b8d25ed681c278512df0993725f25dd
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Jul 15 15:48:05 2008 +1000
drm/radeon: fixup issue with radeon and PAT
Hi David,
it affects stable (2.6.26) too?
yes I've already sent a patch to stable maintainers.
Dave.
On 7/15/08, Dave Airlie [EMAIL PROTECTED] wrote:
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm
After seeing that i830_drm.h was just added as a userspace header
I wondered whether there's really a non-empty intersection of
kernel = 2.6.27 users and users of such an ancient X.
I doubt it, and therefore suggest this patch to remove the driver.
NAK I'm generally against removing old
Please pull the 'drm-reorg' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-reorg
This contains a moving around of a lot of the DRM into a more Linux like
tree and makes it a lot nicer going forward for merging new features.
Does this tree
c0e09200dc0813972442e550a5905a132768e56c
Author: Dave Airlie [EMAIL PROTECTED]
Date: Thu May 29 10:09:59 2008 +1000
drm: reorganise drm tree to be more future proof.
With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach
On Fri, Jul 11, 2008 at 1:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote:
Simon Thum escreveu:
But all this in the kernel is an impedance mismatch to me. What could it
buy us we don't have today?
Improve heavy-load behavior -- no
You may consider this offtopic, but I wondering
about status of graphical development.
Yes.
And lastly, just for a thought, maybe it is better to do one thing at
time, for example stabilize kernel modesetting, put it in kernel, then
release gem driver and stabilize it, and then add
So I've got a problem with the aperture space check if the cliprect mode
changes and blits flush the relocs and aperture spaces.
However in trying to fix, I've noticed we never set the
batch-cliprect_mode anywhere I can see except to IGNORE_CLIPRECTS in
intel_batchbuffer.h.
I'm going wtf..
SHA1: 007903c738df3bc2a3cdab0289635baa95a2ed7a libdrm-2.3.1.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.3.1.tar.bz2
MD5: 620fe7dd02c3236c3e9881a3a238173d libdrm-2.3.1.tar.bz2
SHA1: 775dc69fcabb324552b0b9fe3a67eceb324be194 libdrm-2.3.1.tar.bz2
I'd include a real changelog but really..
Dave
Is anyone working on cleaning up the drm code so that it works with
the latest -mm sources. I sure would like to use r500 drm with an -mm
kernel.
The upstream drm already contains r500 support so the -mm kernel should
have anything you need, you shouldn't need to build out-of-tree drm
what userspace tells us.
It does this hopefully without breaking the drm api.
Fixes bug from thread: BUG: unable to handle kernel NULL pointer
dereference (drm_getunique)
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
Reported-by: Sitsofe Wheeler
drm/i915: add support for Intel series 4 chipsets.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 21efa2bac91b8d12064617c5a35492ec982544eb
Author: Dave Airlie [EMAIL PROTECTED]
Date: Thu Jun 19 13:01:58 2008 +1000
drm/radeon
a side effect
on some driver ioctls. Looks like I have to audit the driver ioctls by
hand.
So I've pushed the fix for that as well.
commit 858a3685bcf3ac199128e4aa85eaae2fb9d191b5
Author: Dave Airlie [EMAIL PROTECTED]
Date: Fri Jun 20 15:42:38 2008 +1000
drm: only trust core drm ioctls
*GEARS* (Should be GPU bound)
i915tex (TTM):1035fps @ 70% CPU
GEM, no buffer reuse: 863fps @ 95% CPU
GEM, buffer reuse: 1000fps @ 80% CPU
Unichrome CX700 1009fps @ 70% CPU
So just to try and do some testing off my own, I can't get TTM code from
However so far I can't get glxgears on TTM to not flicker as do all my
other apps. Am I missing something?
Granted my gears numbers are better with TTM, but the flicker does leave
me to think something broke.
Ah keithp pointed out single buffered rendering due to visual failure.
It
Each of the following changes individually fixes the problem:
1) Do not overwrite the same region of the framebuffer in every iteration;
instead, use a different framebuffer region for every iteration.
2) Add a sleep(1) before glReadPixels.
3) Add a sleep(1) after glReadPixels.
4)
Hmm, the radeon_cp_idle() should purge the destination cache (and wait
for it too, including checking the DC_BUSY bit).
At least the r200 driver has a comment in r200SpanRenderStart (including
a dodgy workaround) which sure looks like the same issue to me.
We may purge the cache but not
Dave,
Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted
the --enable-ttm-api flag in mesa now ??
I think it will have to not have DRI2 by default unless Kristian does
the decoupling from the mm interface.
Dave.
Hi Brian,
It seems like people are mostly concerned about gallium stability
right now. How stable wioll the interfaces be in the future ? Maybe if
you could tell us, that'd help others jump in.
Even when it might make it to master, is it planned to land in master..
I would assume Mesa
Gallium might ultimately wind up in its own repository as a stand-alone
project. Afterall, Gallium drivers could be used by APIs other than OpenGL.
The question is mainly from a distro point of view what do we need to ship
a gallium driver. The current method would mean we need a Mesa
Oops I thought I'd pushed it, but my repos were messed up..
I've pushed my current tree now..
Dave.
On Wed, 2008-06-04 at 09:50 +0800, Wu, Nian wrote:
Hi, Jesse:
When compiled intel driver branch intel-kernelmode, it failed with
error info:
gcc -DHAVE_CONFIG_H -I. -I.. -Wall
I can easily trigger an endless stream of the following three lines
[drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held,
held 0 owner eb0908c0 eb0908c0
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner eb0908c0 eb0908c0
Backtrace:
0: X(xf86SigHandler+0x80) [0x80d29f0]
1: [0xb7f54400]
2: /usr/lib/xorg/modules/input//evdev_drv.so [0xb7aab90e]
3: X [0x80d2b87]
4: X [0x80b6065]
5: [0xb7f54400]
6: X(Dispatch+0x81) [0x808d5d1]
7: X(main+0x485) [0x8074bb5]
8: /lib/libc.so.6(__libc_start_main+0xdc)
On Thu, May 29, 2008 at 9:02 PM, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2008-05-29 at 10:46 +1000, Dave Airlie wrote:
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it lives under char.
b) everything in one directory.
c) header
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it lives under char.
b) everything in one directory.
c) header files in one directory.
d) no header files exposed to userspace.
On Thu, May 29, 2008 at 2:23 PM, Sam Ravnborg [EMAIL PROTECTED] wrote:
On Thu, May 29, 2008 at 10:46:22AM +1000, Dave Airlie wrote:
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it lives under char.
b) everything in one directory.
c
So possibilities are:
- batchbuffer starvation -- has
- over-throttling in swapbuffers -- I think we used to let it get
two frames ahead - has this changed?
I would suspect this broke somehow at some point..
Dave.
For radeon the plan was to return error from superioctl as during
superioctl and validation i do know if there is enough gart/vram to do
the things. Then i think it's up to upper level to properly handle such
failure from superioctl
You really want to work this out in advance, at
1) The ideal thing would be for the card contents to be quickly copied
to backing-store and suspend is done.
However, this requires pinning as much physical pages as there is VRAM.
2) The other approach is to have a backing object of some sort, either a
list of swap-entries or perhaps a
Spliting the cmd before they get submited is the way to go, likely we can
ask the kernel for estimate of available memory and so userspace can stop
building cmd stream but this isn't easy. Well anyway this would be a
userspace problem. Anyway we still will have to fail in superioctl if
for
I honestly don't see a problem with having multiple memory managers. We
have different hardware with different functionality and different
performance characteristics. The probability of one memory manager
fitting everywhere is nil. Quite frankly, the fact that it has take
this long to
All the good that's done us and our users. After more than *5 years* of
various memory manager efforts we can't support basic OpenGL 1.0 (yes,
1.0) functionality in a performant manner (i.e., glCopyTexImage and
friends). We have to get over this it has to be perfect or it will
never get
Dave,
Could you list what fixes / changes you think are needed to get TTM into
the mainline kernel?
2 main reasons:
1) I feel there hasn't been enough open driver coverage to prove it. So
far we have done an Intel IGD, we have a lot of code that isn't required
for these devices, so
1) I feel there hasn't been enough open driver coverage to prove it. So far
we have done an Intel IGD, we have a lot of code that isn't required for
these devices, so the question of how much code exists purely to support
poulsbo closed source userspace there is and why we need to live
Hi guys,
So compiz calls glGenerateMipmapEXT to generate mipmaps for some icons on
its switcher, this fails with a NULL src data ptr when running under
TTM+DRI2, my initial feeling is that we don't have the miptrees mapped and
from looking the texture data ptr is set to NULL.
I'm just
So compiz calls glGenerateMipmapEXT to generate mipmaps for some icons on
its switcher, this fails with a NULL src data ptr when running under
TTM+DRI2, my initial feeling is that we don't have the miptrees mapped and
from looking the texture data ptr is set to NULL.
I'm just
So compiz calls glGenerateMipmapEXT to generate mipmaps for some icons on
its switcher, this fails with a NULL src data ptr when running under
TTM+DRI2, my initial feeling is that we don't have the miptrees mapped and
from looking the texture data ptr is set to NULL.
I'm just
On the gallium-0.1 branch I added a device driver hook for
GenerateMipmap. I think you could cherry-pick that into master. I
don't recall if it was one or two commits.
Thanks Brian,
I've pulled them over, fixed up swrast and checked my patch in for the
intel drivers.
Dave.
| Please pull the 'drm-patches' branch from
| ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
I just realized that the XGI DRM never got pushed upstream. Could that
happen? The DDX for that card is going out in X.org 7.4, and it
*requires* its DRM to
12:27:53 2008 +1000
drm/i915: save and restore dsparb and d_state registers.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit a59e122a67b88925944d3bbf33d15229cf0fc3de
Author: Jesse Barnes [EMAIL PROTECTED]
Date: Wed May 7 12:25:46 2008 +1000
drm/i915: fix off by one in VGA
On Fri, 2 May 2008 10:36:33 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=10592
Summary: [old regression] performance drop for glx after vblank
patch
Product: Drivers
Version: 2.5
Hi Eric,
others: This may be a larger problem (I'd be interested in how TTM solves
this also).
So I've hit a problem with the fake bufmgr and the size of the objects
referenced by a batchbuffer being bigger than the current aperture. So
when we have a batchbuffer and we are
At least for TTM this is part of a larger problem where you can hit
problems both when the pinned page quota is hit, and when
you can't fit an object in the aperture.
The other problem is the one you mention. Since we're dealing with
multiple clients and only evict one buffer at a time
Hi Eric,
others: This may be a larger problem (I'd be interested in how TTM solves
this also).
So I've hit a problem with the fake bufmgr and the size of the objects
referenced by a batchbuffer being bigger than the current aperture. So
when we have a batchbuffer and we are emitting a number
I'm just wondering if rather than specify all the CACHED and MAPPABLE and
SHAREABLE flags we make the BO interface in terms of CPU and GPU
operations..
So we define
CPU_READ - cpu needs to read from this buffer
CPU_WRITE - cpu need to write to the buffer
CPU_POOL - cpu wants to use the
On Wed, Apr 2, 2008 at 4:08 PM, Xiang, Haihao [EMAIL PROTECTED] wrote:
On Tue, 2008-04-01 at 20:50 +0800, Kristian Høgsberg wrote:
On Tue, Apr 1, 2008 at 5:25 AM, Jin, Gordon [EMAIL PROTECTED]
wrote:
Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM:
Hi,
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Luck, Tony [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit
+++---
drivers/char/drm/via_dmablit.c |2 +-
9 files changed, 110 insertions(+), 96 deletions(-)
commit b05c23851ab820b1957cd2f322eaa1ac44c196bd
Author: Dave Airlie [EMAIL PROTECTED]
Date: Mon Mar 17 10:24:24 2008 +1000
drm/ati_pcigart: fix the PCIGART to use drm_pci to allocate GART table
Yes, I think so. One reason to lock is to make sure the GTT page table
is really repopulated after a resume, but that can be handled in the DRM
driver resume function, and we could perhaps
change the user-space lock_mm() to ignore kernel_bos.
It defintely should all be handled
Hi Thomas,
Okay I've come across a problem in the kernel memory validaton that
I'm not sure how to solve,
The sequence of events is something like..
a) allocate frontbuffer MEM_LOCAL.
b) setstatus into MEM_VRAM | MEM_TT
c) emit a relocation in a batchbuffer to its BO for only MEM_TT
(possibly
this adds something to say the kernel initialised the memory region not
the userspace. and blocks userspace from deallocating kernel areas
Dave,
I guess this commit is a fix for the fact that the X server will try to
evict fb scanout buffers when leaving VT. We've
So, over to the somewhat different problem I was referring to, namely
potential buffer eviction on vt switch where the X server run
drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer
doesn't really notice as long as the BOs sit in VRAM...
Yes I get around this
apologies for top posting, but Thomas's email appears to be breaking
alpine (html or something encoding)
The big area where we win with CACHED_MAPPED is pixmaps for 2D operations.
a) we can't know in advance if we should allocate pixmaps as cached or
uncached.
b) we can't know if we are
On Fri, Feb 29, 2008 at 1:36 AM, Alex Deucher [EMAIL PROTECTED] wrote:
On Thu, Feb 28, 2008 at 1:53 AM, Dave Airlie [EMAIL PROTECTED] wrote:
So just to let people know where kernel modesetting is getting to and
what I'm up to with it..
So I really want to ship something in Fedora 9
Please don't let any api freezing depend on fedora core, at least give
external parties time to play with it once it's reasonably stable,
this will undoubtely reveal limitations. It should be in mainline drm
well before api freezing it.
It's not called Fedora core any more :), but I
On Fri, Feb 29, 2008 at 8:26 AM, Maarten Maathuis [EMAIL PROTECTED] wrote:
On 2/28/08, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, February 28, 2008 11:33 am Dave Airlie wrote:
the current API abstracts connectors from outputs, so in reality it
is encoders with connector
So just to let people know where kernel modesetting is getting to and
what I'm up to with it..
So I really want to ship something in Fedora 9 with kernel modesetting
in it, whether this is a default or a special boot option for the user
I won't decide for a while.
But with this in mind I've
=
[ INFO: possible recursive locking detected ]
2.6.24-0.123.rc6.fc9 #1
-
Dave,
We've seen this on occasions before but never been able to track it
down, so if you
have a reliable way to reproduce it would be super.
When drm_bo_mem_space() is called for a buffer, that buffer should no
longer be on the lru lists,
but it is obvious from the error message it's
Any idea if we can wrap legacy DRI users in a separate 'rendering
context' so that you can run old and new X servers/DRI clients in
different sessions? I'm thinking the exclusive nature will make some
application compatibility
harder (app 'Q' runs only on old DRI, app 'R'
runs only on new
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching, GPGPU apps,
different users on a per head one a single card..
http://dri.freedesktop.org/wiki/DRMRedesign
has a nice picture and some notes.. either comment direct on the
/ airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
On Wed, 13 Feb 2008, Dave Airlie wrote:
So I've been thinking about this stuff a lot lately wrt to getting the
DRM into a state that enables fast-user-switching, GPGPU apps,
different users on a per head one a single card
/via_video.c |4 +-
61 files changed, 2291 insertions(+), 770 deletions(-)
commit 3d5e2c13b13468f5eb2ac9323690af7e17f195fe
Author: Dave Airlie [EMAIL PROTECTED]
Date: Thu Feb 7 15:01:05 2008 +1000
drm: add initial r500 drm support
This adds CP support for the r500 series of chips
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
NAK
I've started looking at this already in the drm git tree, I'm going to
provide
On Wed, Jan 09, 2008 at 03:37:50AM +, Dave Airlie wrote:
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
NAK
The DRM has never been able to support multiple X servers for DRI that
could be chvt'ed between (fast-user-switching...)
This is my first attempt at a patch to provide this support. With it and a
slightly hacked up intel driver I can run two servers with gears on each
and chvt between them
Benefits:
1) simplified kernel API
2) reduced user-kernel data transfer (no relocations)
3) eliminate user-kernel relocation reformatting
4) eliminate buffer objects for relocations
5) eliminate buffer object mapping to kernel
Costs:
1) more user mode code
2) might never
I'm trying to figure out how context switches acutally work... the DRI
lock is overloaded as context switcher, and there is code in the
kernel to call out to a chipset specific context switch routine when
the DRI lock is taken... but only ffb uses it... So I'm guessing the
way context
What are the prospects of the DRM TTM changes making it into 2.6.24? I
noticed that Andrew has them [1] in his mm tree... any chance of that
getting pushed into Linus' tree for 2.6.24?
No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm
for the 2.6.23 cycle as we
NAK...
I already fixed this, we have a driver mapping.. otherwise we leak
mappings if userspace dies..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
On Tue, 13 Nov 2007, Jesse Barnes wrote:
Since the
dri causes some XPRESS cards to hang.
I think we pretty much need mmio-trace from the fglrx kernel module, and
probably a valgrind-mmt-extend-extend trace of X starting up..
http://dri.freedesktop.org/wiki/ReverseEngineering
Dave.
in i915_user_irq_off there code to switch the interrupt off is commented
out...
Can we get that cleaned up or commented on? pushing code like that
upstream isn't a good plan..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI,
Hi all,
These patches are the first set of patches containing the core components
of the DRI memory manger from Tungsten Graphics.
At least one patch is too big for the list, and I spent a lot of time
getting the separation even to this level...
the patches are here:
I think its about time we merged this code, it is in an area of the
kernel wholly self-contained and mostly maintained by me, and adds a
feature that allows userspace graphics to leverage features of graphics
cards that only the binary vendors have done up until now.
And I mean to -mm
OK. We're using this functionality in Poulsbo, so we should probably
sort this out to avoid breaking things.
Okay I'll try and fix it back up tomorrow..
I've attached my first attempt at fixing this up but it messes up by the
time the flags hit the ttm binding
On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave,
When starting out with TTM i did look a little at AGP caching issues and
there was an issue with cached memory and speculative pre-fetching that
may affect the mapped-cached memory,
and that we need to know about but perhaps
On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave Airlie wrote:
On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave,
When starting out with TTM i did look a little at AGP caching issues and
there was an issue with cached memory and speculative pre-fetching that
may
Okay I've landed the drm and Mesa patches fot un-snooped cached mappings
in the trees, the DDX code to use TTM for EXA is in the intel-batchbuffer
branch of the intel repo..
This should resolve the gears slowdowns etc that were seen recently..
I've got a bit more testing to do, but I feel
Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent
memory, that is cache coherent also while visible to the GPU. There are HW
implementations out there (Poulsbo at least) where this option actually seems
to work, althought it's considerably slower for things like
OK. We're using this functionality in Poulsbo, so we should probably
sort this out to avoid breaking things.
Okay I'll try and fix it back up tomorrow..
Yes, Eric seems to have the same opinion. I'm not quite sure I understand the
reasoning behind it.
Is it the added complexity or
,
Dave.From b9dcf514d0f1f61dc482cac622ffd2d79d500bf8 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 15:14:03 +1000
Subject: [PATCH] agp: add chipset flushing support to AGP interface
This bumps the AGP interface to 0.103.
Certain Intel chipsets contains a global
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
right? Can we be sure that a single flush is sufficient? Is there any
window between when we flush and when we start accessing memory with
the device that we could get into more caching trouble?
Not that I can
Hi,
So currently the TTM interface allows the user specify a cacheable
allocation, and on Intel hardware this gets conflated with using the intel
snooped memory type in the GART. This is bad as the intel snooped memory
type comes with its own set of special rules and sucks for lots of things.
http://people.freedesktop.org/~airlied/intel_batchbuffer_test_code.patch
is a patch to blit the contents of the batchbuffer to another memory
space, and compare them before submitting the batchbuffer for the hardware
to consume..
so on my 965, starting X using a batchbuffer allocated
is a patch to blit the contents of the batchbuffer to another memory
space, and compare them before submitting the batchbuffer for the hardware
to consume..
so on my 965, starting X using a batchbuffer allocated non-cached in TT
space, I get to see this:
index: 0 : src
There is also the following (i don't think it was mentioned before
in this thread):
card with 8Mo of ram (who the hell have such hw ? :))
I've got 40 of them :(
All of our desktops have integrated Intel ( i845g ) chips, and the BIOS
has the option of stealing either 1MB or 8MB of
DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin
interface. We can perhaps rename it to drmBOSetStatus or something more
suitable.
This will get rid of the user-space unfenced list access (which I
believe was the main motivation behind the set pin interface?) while
On 10/14/07, Németh Márton [EMAIL PROTECTED] wrote:
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh
via invalid device ids removal
0x1106, 0x7204 is unknown and thus is not an IGP/GPU.
0x1106, 0x3304 is K8M800 hostbridge, not an IGP/GPU.
None of them are in drm git tree.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED
Since Poulsbo is CMA, to avoid the SMP ipi issue, it should be possible
to enclose the whole reloc fixup within a spinlock and use
kmap_atomic which should be faster than kmap.
Since within a spinlock, also preemption is disabled we can guarantee
that a batchbuffer write followed by a
So in an attempt to avoid flushes on remap etc, I've attempt to avoid
doing anymore than 1 cache flush per batchbuffer..
http://people.freedesktop.org/~airlied/i915-hack-cacheflush.txt
I allocate the batchbuffers CACHED and then flush the cache for those
pages post relocating..
I need to
[updated patch attached]
Hmm, yes. Although that has been bumped recently it could be changed to
dynamic, though, but as Dave says,
we need to impose some kind of limit to avoid DOS.
Poulsbo is still using a buffer list from user-space, and there's an
internal kernel array that imposes this
Dave,
As mentioned previously to Eric, I think we should keep the single
buffer validate interface with the exception that the hint
DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin
interface. We can perhaps rename it to drmBOSetStatus or something more
suitable.
This
Dave,
I like the idea of moving over to clflush, but I still think we
shouldn't use TT drmBOs for batch buffers and buffers with similar use.
(i915tex uses a sub-allocator for batch buffers, which avoids the cache
flushes completely during normal rendering).
I think something similar
On Monday, October 8, 2007 10:13 am Keith Whitwell wrote:
Neither 42 nor 256 are very good - the number needs to be dynamic.
Think about situations where an app has eg. one glyph per texture and
is doing font rendering... Or any reasonably complex game might use
256 textures in a frame.
601 - 700 of 1423 matches
Mail list logo
