> > > > Sep 6 10:24:31 poppero1 kernel: [ 186.138774] [drm:radeon_cp_start]
> > > > *ERROR* radeon_cp_start called without lock held, held 0 owner
> > > > f726bc80 f68f6840
> > > > Sep 6 10:24:31 poppero1 kernel: [ 186.138968] [drm:radeon_cp_idle]
> > > > *ERROR* radeon_cp_idle called with
2008/9/4 Jesse Barnes <[EMAIL PROTECTED]>:
> On Wednesday, September 03, 2008 6:11 am Stefano Avallone wrote:
>> On Wednesday 03 September 2008 13:36:21 Maksym Veremeyenko wrote:
>> > Jesse Barnes написав(ла):
>> > [...]
>> >
>> > >> I am very interesting in getting drmWaitVBlank works on 945GME...
On Tue, Aug 26, 2008 at 9:04 PM, roel kluin <[EMAIL PROTECTED]> wrote:
> In drivers/char/drm/drm_sysfs.c:187, function drm_sysfs_device_add():
>
> for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
>err = device_create_file(&minor->kdev, &device_attrs[i]);
>if (err)
>g
On Thu, Aug 28, 2008 at 9:32 PM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
>>
>> On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Dave,
>>>
>>> This process l
On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Dave,
>
> This process looks ok to me,
> but I think some clarifications are needed:
>
> Dave Airlie wrote:
>>
>> Okay I've put some thoughts up at:
>> http://dri.freedeskt
v is the problem. But 2.6.25 was fine with it. Then I tried the
> 2.6.27 kernels in koji.fedoraproject.org. They had the same problem.
>
> I saw that the thing in common between the 2.6.26 and the 2.6.27 is
> that Dave Airlie added drm-patches and fixes in the fedora kernels.
> Wi
On Wed, Aug 27, 2008 at 11:45 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Aug 2008 18:02:24 +1000
> "Dave Airlie" <[EMAIL PROTECTED]> wrote:
>
>> 4. added clean flag for buffers that get migrated to VRAM immediately.
>>- with pixmaps w
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
>> Okay I've put some thoughts up at:
>> http://dri.freedesktop.org/wiki/DRMProcess
>>
>> and I've pasted it in below t
On Wed, Aug 27, 2008 at 11:35 AM, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 06:20:43PM -0700, Dave Airlie wrote:
>> linux-core/radeon_encoders.c | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below this for discussion.
some other points:
a) People are pushing for a process change, we will have something
change, however this isn't a who shouts loudest competition, so more
than likely yo
On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Jesse Barnes wrote:
>> The DRM design includes ioctls to allow a userland driver to tell the kernel
>> driver when to register its interrupt handler and on what IRQ. This is a
>> really bad idea for several reasons, and
Hi Thomas,
I've made some changes you might be interested in on the
modesetting-gem branch of the main repo.
1. removed all the TTM interfaces and ioctls from the kernel API.
2. removed drm_bo_lock.c (we need to discuss what we want that for)
3. built a radeon GEM interface on top of the TTM inte
> >
> > Your reply now serves as place to point people at when they ask why Red
> > Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
> > with that.
>
> 6 months sounds too long, there's at least one merge window in such a
> time-frame.
Not every distro rebases their k
/gpu/drm/radeon/radeon_cp.c | 38 +++
drivers/gpu/drm/radeon/radeon_drv.h | 19 ++--
6 files changed, 225 insertions(+), 86 deletions(-)
commit 3e5fc80a404a24c858468030b63555cccfb3e79c
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Sun Aug 24 17:02:26 2008 +1000
drm: don't set
> Quite frankly, I'm not going to take this.
>
> None of what you describe sounds like regressions, and this is just TOO
> F*CKING LATE to take big changes like this, to a fragile subsystem that
> has historically easily introduced new regressions.
>
> Can you please make a branch with ONLY RE
_SIS=y is not a legal configuration.
Reported-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 8ba0be53102f8d8509ee2958d15142bdd2fd433f
Author: Dave Airlie <[EMAIL PROTECTE
On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 9, 2008 at 7:28 PM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>> On Wed, Aug 6, 2008 at 2:23 AM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
>>> On Tue, Aug 5, 2008 at
> >
> > Then this, the thing is to keep it building you need compat code, code
> > that can't go into Linus tree, so we end up with a tree that isn't like
> > Linus tree, and we still have to patch manage transitions so we don't save
> > anything doing this over what we have now.
>
> I was thinki
>
> Yes, with a 1-1 mapping between GPU objects and file objects. You can
> use the normal read/write/mmap API on them. The reason we aren't using
> fds now is just that the kernel cannot handle this many fds per process.
Well it can now, we just need to fix the X server :)
>
> I want to map t
>
> Managing a fake linear address space just to match some existing
> arbitrary API requirements is insane. Creating the right interface for
> my UMA environment is my goal. I'm not sure precisely what that API
> should be, but at least this one is obviously wrong.
Isn't that also what you are t
> >
> > Personally, I only use the existing DRM repo on old kernels because that's
> > how
> > it's structured. It's actually more work for me to download & build a
> > recent
> > kernel, then update & build the DRM drivers against it that it is to simply
> > update the DRM drivers and build aga
>
> Well, if the overhead of merging upstream is a concern, then how about
> not worrying about bc at all and let people who want to back port deal
> with it? Oh, and what about just keeping the drm drivers in a linux
> kernel tree? That'll make upstream merging even easier yet...
The less cra
> > 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 no
> > 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 n
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]&
> 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
> remo
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 expe
> 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 o
> 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
>
rs/gpu/drm/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
> >
> > 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.
>
>
lude}/drm/drm_memory_debug.h (100%)
rename {drivers/char => include}/drm/drm_os_linux.h (100%)
rename {drivers/char => include}/drm/drm_pciids.h (100%)
rename {drivers/char => include}/drm/drm_sarea.h (100%)
rename {drivers/char => include}/drm/drm_sman.h (100%)
rename {drivers/char =
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 behavio
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.. b
>
> 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 ad
ar.gz
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 real
> 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
aga
gt;> This enforces us to use the drm ioctl types so read/write works
> >> correctly and not believe
> >> what userspace tells us.
> >>
> >> It does this hopefully without breaking the drm api.
> >>
> >> Fixes bug from thread:
oops fixed in the ioctl handler, fixed the oops but had 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: Fr
12:56 2008 +1000
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 J
>
> 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.
I
> *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
i91
>
> 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 no
> 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.
> 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.
-
>
> 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 t
>
> 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 Me
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 -W
>
> 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)
> 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
> [drm:rade
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,
>>
>&g
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,
>>
>&g
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.
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdi
> 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.
-
>
> 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
>
>
> 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 per
>
> 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 sup
>
> 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
> neve
>
> 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
> > 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
> 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, s
>
> 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.
--
>
> >
> > 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.
> >
>
> 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 wo
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 wonderi
> | 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
]>
Date: Wed May 7 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 +1
> 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.
> 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 t
>
> 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
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 buffer
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:
> > >
> > >
least until we have more useful
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 <[EMAI
via_dma.c | 59 +++---
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_
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 a
> >
> 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 in
> 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 curre
> >
> > 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.
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 going
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 re
> 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 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 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 check
> 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 messag
=
[ INFO: possible recursive locking detected ]
2.6.24-0.123.rc6.fc9 #1
-
haoyu Chen <[EMAIL PROTECTED]>
Date: Wed Feb 20 10:12:39 2008 +1000
drm/sis: add pciid for SiS 662/671 chipset
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit f9e9716a67fbea4594749bf1022fdfd0b96099db
Author: Mirko <[EMAIL PROTECTED]>
Date: Wed Feb 20 10:07
>
> 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 o
/ 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
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
s/char/drm/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
> On Wed, Jan 09, 2008 at 03:37:50AM +0000, 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
> 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
prov
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 (it
> 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) m
>
> 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, VA
601 - 700 of 1512 matches
Mail list logo
