From: Felix <fx...@gm...> - 2004-12-19 14:15:28
|
Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54: > Tomas Carnecky wrote: > > Hi, > >=20 > > Can I control a graphics card _completely_ with DRI? I mean > > allocate the framebuffer, switch between modes etc. Or do I > > need some kind of helper code that does these things (like > > fbdev or the Xserver)? Mode setting and memory management are currently not implemented in the DRM. (There are two drivers, sis and via, that have their own memory management, but I don't know if this includes the frame buffer.) These things are usually handled by the Xserver. > > I'm particulary interested in allocating memory for the > > framebuffer via DRI, I think there is an ioctl for that, but > > I'm not sure. No there isn't, because DRM doesn't have any memory manager ATM. > > And is it possible to allocate offscreen memory with DRI? > > So I could render into it, read the pixels out of it and > > put them into an image (for example). The Xserver usually allocates a big chunk of memory as texture memory. If you can make your 3D engine render to texture memory in a reasonable way that might fit your needs. Current drivers only support rendering to front and back-buffers. They (and the depth buffer) are allocated statically at Xserver startup with the virtual screen resolution. The 3D driver and DRM must make sure that overlapping 3D windows don't scribble on top of each other. This is ensured using clipping rectangles. Most (all?) supported hardware doesn't support multiple clipping rectangles in hardware, so the driver iterates over them and draws all primitives once in each clipping rectangle. > >=20 >=20 > I've checked out the cvs drm and mesa tree and did a bit of browsing.. > In the mesa tree under src/mesa/drivers/dri/*/xxx_context.c, there=20 > usually is xxxMakeCurrent, xxxCreateContext, xxxDestroyContext, but no=20 > xxxCreateFramebuffer. It seems that the framebuffer is allocated=20 > somewhere else, not in the dri code. In the Xserver (see above). >=20 > Then I found this nice file in the drm tree: linux-core/drm_drawable.c > But it's almost empty, only two noop functions. What are they for? > Are they used somewhere? Is DRM_IOCTL_ADD_DRAW used? I'm not aware it is being used ATM. Maybe it's a historical artifact. >=20 > It seems to me that the framebuffer is allocated from the main meory,=20 > not from the videocard memory. >=20 > Ok, I think I've found it: linux-code/drm_bufs.c::drm_addmap (or=20 > DRM_IOCTL_ADD_MAP). >=20 > typedef struct drm_map { > unsigned long offset; /**< Requested physical address (0 for SAREA)*/ > unsigned long size; /**< Requested physical size (bytes) */ > drm_map_type_t type; /**< Type of memory to map */ > drm_map_flags_t flags; /**< Flags */ > void *handle; /**< User-space: "Handle" to pass to mmap() */ > /**< Kernel-space: kernel-virtual address */ > int mtrr; /**< MTRR slot used */ > /* Private data */ > } drm_map_t; DRM maps are created by the Xserver (2D driver) in order to make certain address ranges available to DRM clients (3D driver). This way front/back/depth buffers, DMA buffers, texture regions, sometimes MMIO regions and the shared memory area that contains the global DRM lock are handled. DRM clients can map these into their address space using the drm_map ioctl. >=20 > How can the userspace know which offset is free? Or is it possible to=20 > map two overlapping areas? In drm_bufs.c::drm_addmap is: > case _DRM_AGP: > if (drm_core_has_AGP(dev)) { > map->offset +=3D dev->agp->base; > map->mtrr =3D dev->agp->agp_mtrr; /* for getmap */ > } >=20 > It just returns the offset plus the start of the agp memory, but no=20 > checks for overlapping maps, so is it possible to do the following? > drm_addmap(type =3D _DRM_AGP, offset =3D 0, size =3D 100) > drm_addmap(type =3D _DRM_AGP, offset =3D 10, size =3D 90) >=20 > Does the agp memory have some size restrictions? Or can I map any size? > drm_addmap(type =3D _DRM_AGP, offset =3D 0, size =3D MAX_INT)? Dunno about overlapping maps. But size and offset are probably limited to the AGP aperture size. >=20 >=20 > thanks > tom >=20 Regards, Felix --=20 | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |