On Mon, 2008-08-04 at 05:13 +0100, Dave Airlie wrote:
> Well it can now, we just need to fix the X server :)
Yeah, I just discovered that today. Weird that the kernel was fixed
between the last time I looked and now though; NR_OPEN had been 1024 for
many years prior.
However, it's not just fixin
>
> 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
Keith Packard wrote:
>
>
>> The other approach is to use one address space per device.
>>
>
> This would require constructing an entirely artificial linear space for
> my objects. You then have to track this per-device linear address for
> each object and pass that into the mmap call. And,
On Sun, 2008-08-03 at 08:07 +0100, Dave Airlie wrote:
> Isn't that also what you are trying to do with GEM though.. match GPU
> objects to the file interface.
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 us
On Sun, 2008-08-03 at 10:53 +0200, Thomas Hellström wrote:
> With the current GEM implementation, the address space is per buffer
> object, and if this were done
> correctly you'd duplicate the shmemfs filesystem to make a drmfs
> filesystem where you have complete control over creation and mmap
Keith Packard wrote:
>
>> and that's why TTM
>> needs to manage a fake linear address space for the drm fd.
>>
>
> 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 no
>
> 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
On Sat, 2008-08-02 at 17:01 +0200, Thomas Hellström wrote:
> The description would be a little easier to follow if you didn't use the
> term "map" both for
> mmap-ing and AGP binding.
Yeah, using unique terms for each map is a good idea.
> Anyway, the above would probably work but for Intel UMA
Zhao, Chunfeng wrote:
> Hi Keith,
> Do we have a time line to merge DRM modesetting_GEM branch to upstream
> main line branch?
>
> Thanks!
>
> Chunfeng
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Keith
> Packard
> Sent: Thursday, July 31, 2008 9
On Fri, 2008-08-01 at 14:34 -0400, Kristian Høgsberg wrote:
> Are you saying that you're not planning to make the mmap ioctl a real
> mmap syscall when/if that's feasible or that it's okay to add
> intel-gem specific bits to the mmap arguments? I recall Thomas asking
> for a flags argument to the
On Fri, 2008-08-01 at 20:33 +0200, Jakob Bornecrantz wrote:
> If you want a none generic ioctl for that function go ahead, but IHMO
> it should then be some sort of flag field on the request. Fiddling
> with bits on the address feels a bit icky at best.
Yeah, it is a bit icky. The thing is that w
On Fri, Aug 1, 2008 at 2:13 PM, Keith Packard <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-08-01 at 18:48 +0200, Jakob Bornecrantz wrote:
>
>> The basic fault here is that you have added a driver specific flag to a
>> generic
>> ioctl/syscall. Which the last time I checked we didn't want. For example
On Fri, Aug 1, 2008 at 8:13 PM, Keith Packard <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-08-01 at 18:48 +0200, Jakob Bornecrantz wrote:
>
>> The basic fault here is that you have added a driver specific flag to a
>> generic
>> ioctl/syscall. Which the last time I checked we didn't want. For example
On Fri, 2008-08-01 at 10:45 -0700, Zhao, Chunfeng wrote:
> Hi Keith,
> Do we have a time line to merge DRM modesetting_GEM branch to upstream
> main line branch?
Eric has posted the GEM patches to lkml for review; there are external
kernel changes which are necessary for GEM to work; I think that
On Fri, 2008-08-01 at 18:48 +0200, Jakob Bornecrantz wrote:
> The basic fault here is that you have added a driver specific flag to a
> generic
> ioctl/syscall. Which the last time I checked we didn't want. For example on
> PCIE Radeon there is no GTT to map, so bit 31 makes no sense there.
The
Hi Keith,
Do we have a time line to merge DRM modesetting_GEM branch to upstream
main line branch?
Thanks!
Chunfeng
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Keith
Packard
Sent: Thursday, July 31, 2008 9:18 PM
To: dri-devel
Cc: [EMAIL PROTECTED]
Su
On Fri, Aug 1, 2008 at 6:17 AM, Keith Packard <[EMAIL PROTECTED]> wrote:
> Ok, we clearly need to deal with mapping subsets of the graphics
> aperture, both for discrete graphics cards and for 2D on tiled surfaces.
> Plus, there are reasons for using WC object mappings which is easily
> done throug
17 matches
Mail list logo
