Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54:
> Tomas Carnecky wrote:
> > Hi,
> >
> > 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.
> >
>
> 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
> usually is xxxMakeCurrent, xxxCreateContext, xxxDestroyContext, but no
> xxxCreateFramebuffer. It seems that the framebuffer is allocated
> somewhere else, not in the dri code.
In the Xserver (see above).
>
> 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.
>
> It seems to me that the framebuffer is allocated from the main meory,
> not from the videocard memory.
>
> Ok, I think I've found it: linux-code/drm_bufs.c::drm_addmap (or
> DRM_IOCTL_ADD_MAP).
>
> 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.
>
> How can the userspace know which offset is free? Or is it possible to
> map two overlapping areas? In drm_bufs.c::drm_addmap is:
> case _DRM_AGP:
> if (drm_core_has_AGP(dev)) {
> map->offset += dev->agp->base;
> map->mtrr = dev->agp->agp_mtrr; /* for getmap */
> }
>
> It just returns the offset plus the start of the agp memory, but no
> checks for overlapping maps, so is it possible to do the following?
> drm_addmap(type = _DRM_AGP, offset = 0, size = 100)
> drm_addmap(type = _DRM_AGP, offset = 10, size = 90)
>
> Does the agp memory have some size restrictions? Or can I map any size?
> drm_addmap(type = _DRM_AGP, offset = 0, size = MAX_INT)?
Dunno about overlapping maps. But size and offset are probably limited
to the AGP aperture size.
>
>
> thanks
> tom
>
Regards,
Felix
--
| Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
