Re: dri client framebuffer access..
On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: Do we need to restrict the size of the maps we allow the DRI clients to acess in the FB area? Yes - SiS has a 64K command queue in the frame buffer for example --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri client framebuffer access..
On 9/26/05, Alan Cox [EMAIL PROTECTED] wrote: On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: Do we need to restrict the size of the maps we allow the DRI clients to acess in the FB area? Yes - SiS has a 64K command queue in the frame buffer for example Savage has a command overflow buffer in vram as well. Alex --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
dri client framebuffer access..
I was talking to Ben on IRC about this and I realised I wasn't really sure about this.. At the moment we allow the DRI client full r/w access to the framebuffer if I'm not mistaken (for software fallbacks and the like).. If I put the PCIE GART table into fb memory (which I've no choice in), the user can mess it up and potentially in my mind cause us to read data from anywhere in system RAM... Do we need to restrict the size of the maps we allow the DRI clients to acess in the FB area? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri client framebuffer access..
On Mon, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: I was talking to Ben on IRC about this and I realised I wasn't really sure about this.. At the moment we allow the DRI client full r/w access to the framebuffer if I'm not mistaken (for software fallbacks and the like).. If I put the PCIE GART table into fb memory (which I've no choice in), the user can mess it up and potentially in my mind cause us to read data from anywhere in system RAM... Do we need to restrict the size of the maps we allow the DRI clients to acess in the FB area? That would be good. FWIW, it's done that way in fglrx. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and framebuffer
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
Re: DRI and framebuffer
Felix Kühling wrote:
Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54:
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.
Quite CPU expensive, isn't it?
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.
Who exactly does map the memory? The Xserver or the DRM library? If it's
the Xserver, how can it know where all the different buffers are?
tom
---
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
Re: DRI and framebuffer
Am So, den 19.12.2004 schrieb Tomas Carnecky um 15:32:
Felix Kühling wrote:
Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54:
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.
Quite CPU expensive, isn't it?
More GPU expensive. Because it's the GPU that does all the real work.
;-)
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.
Who exactly does map the memory? The Xserver or the DRM library? If it's
the Xserver, how can it know where all the different buffers are?
I'm not sure I understand the question. I'll rephrase the above and hope
it clears up any misunderstandings. The Xserver creates the maps using
the drm_addmap ioctl. It knows the physical location of the video memory
from the the PCI resource lists (you may want to take a look at the PCI
scan in your Xorg.0.log for details). As for AGP memory, it only needs
to pass offsets in the AGP aperture. Shared memory areas (only the Sarea
in most/all drivers) are allocated at free physical addresses. They
don't even need to be physically contiguous.
These drm maps are mapped by the 3D driver into the direct rendering
application's address space using the drm_map ioctl.
The DRM library is only a set of wrapper functions to the underlying
OS-dependent ioctl-mechanism for calling DRM functions.
tom
--
| 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
Re: DRI and framebuffer
Felix Kühling wrote: Am So, den 19.12.2004 schrieb Tomas Carnecky um 15:32: Who exactly does map the memory? The Xserver or the DRM library? If it's the Xserver, how can it know where all the different buffers are? I'm not sure I understand the question. I'll rephrase the above and hope it clears up any misunderstandings. The Xserver creates the maps using the drm_addmap ioctl. It knows the physical location of the video memory from the the PCI resource lists (you may want to take a look at the PCI scan in your Xorg.0.log for details). As for AGP memory, it only needs to pass offsets in the AGP aperture. Shared memory areas (only the Sarea in most/all drivers) are allocated at free physical addresses. They don't even need to be physically contiguous. These drm maps are mapped by the 3D driver into the direct rendering application's address space using the drm_map ioctl. So.. the Xserver creates the maps, and the 3D driver maps them into the application's address space? Because the maps are identified using 'handles', the Xserver has to pass the handles to the 3D driver, right? And does the Xserver map the whole video memory (everything it sees in the PCI resource list) or just what it needs? There is the DRI kernel module for each card/chip, the PCI scaning could be done in this kernel module. tom --- 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
Re: DRI and framebuffer
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)?
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.
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).
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.
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?
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;
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)?
thanks
tom
---
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
DRI and framebuffer
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)? 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. 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). thanks tom --- 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
[Dri-devel] Framebuffer DRI
Hello! Will using the matrox framebuffer cause me problems trying to use DRI? I have: X410 Matrox G450 Have tried everything and still can't get any OpenGL-apps to run. (The apps are linked to the correct libGL, libGLU; DRI is enabled according to the X-log and Glxinfo). Gears hangs the machine. OpenGL-screensavers hangs the machine. Tuxracer is so slow it hurts (less than 1 fps). Could it be the framebuffer that causes the problems? Would it help to just recompile the kernel w/o fb or do I need to recompile X as well? Regards, Fredrik Hegardt ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
