Ville Syrjälä wrote: [...]
I want to bypass the drm to do accel from user space. Doing an ioctl() for each blit feels very expensive. Rather than do an ioctl() for each blit the drm could check the commands in the DMA buffer for bad stuff. But that doesn't feel very efficient either.
If an ioctl per blit is expensive, why don't you make an ioctl that accepts an arbitrarily long list of blits? You keep a sequre interface, and keeps performance up by handing over a lot of blits in one go.
If you don't care about the security I
People care about security. A server shoudn't be able to fall over just because someone plays quake on the console. And a home machine shouldn't be less stable either, that isn't necessary. You can have both performance and security.
think you should be allowed to bypass it to gain some speed.And you can gain quite a bit more by writing your high-performance
program for one particular card, one mode and one resolution. No interfaces at all, only hardware accesses. That gave us nice performance on the 1MHz machines of the
eighties. Nobody does it any more though.
And finally I find the current situation with multi-head cards quite bad. I'd like the ablitity for a user space app to open the whole card as one entity. That includes all CRTCs, outputs and the whole memory (minus whatever is in use by other stuff like DMA stuff and video capture). If the app doesn't want to handle such details it would just get whatever is used by the current VT.
That might be useful, but it is also useful to be able to deal with only one head at a time, so that another head may be used by another user. I currently do that, with the slight inconvenience that the xserver using one head also affect timings, resolution and blanking on the other.
Helge Hafting
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
