Holger Waechtler wrote:
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few working functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
* mode setting
* memory management
* bitblt
Everything else is best done as device-specific with the true API belonging in user-space.
Comments ?
Just to say that bitblt covers a lot of ground; ie. there's lots of varieties of blits with quite a few parameters - are you talking about just a simple copy within a single framebuffer, or can source and destination have different pitches? what about different pixel formats? what about fill-blits? etc.
And secondly, that an ioctl per blit probably isn't a useful interface if you're trying to do a lot of small blits, like I guess drawing text. So if you wanted this to be maximally useful, some way of saying 'do these n blits' would make sense.
And what about cards with no 2d engine?
A command buffer interface (either mmap()'d buffers or buffers copied using standardized ioctls) with a common command set might be a general approach working on all architectures -- not all card drivers would need to implement all command opcodes, a capability ioctl can return a bitfield of supported opcodes.
Maybe we could use the X11 protocol....
*g*
:) no -- I was thinking about something more leightweight: for everything data-intensive like blits, texture uploads or array rendering calls you just pass the array pointers which then get validated before getting converted to physical addresses and written into the i/o registers of the DMA engine.
For 2D operations you should be able to encode almost all operations into a few bytes, you need only a few opcodes, most take 1...4 arguments, usually bytes or shorts.
don't know whether it makes sense to create command opcodes for all possible commands -- probably it suffices to design a command set that contains the commonly used 2D operations only.
Maybe it also makes sense to require command packets being aligned to say -- 16- or 32-byte boundaries, this simplifies parsing and might improve cache performance.
The following 2D rendering commands come to my mind being useful/required by a console or simple 2D UI:
/* fill a rectangle using the specified FG color */
FillRect(dst:short[4], color:byte[4]) /* set up a pointer in host memory as source for next blits */
/* the passed array addresses need only get to verified once */
SetBlitHostSrc(array:ptr*, width:int, heigth:int, pixfmt:enum) /* use the specified framebuffer surface as source */
SetBlitFBSrc(surface_id:int) /* actually execute the blits */
Blit/StretchBlit(dst:short[4], src:short[4]) /* render lines using the specified color */
DrawLines(array:ptr*, len:int) /* really required? */ /* only for double buffered framebuffer surfaces */
SwapBuffers() /* sync */
Flush()/Wait()This command set should be sufficient for common tasks like implementing window stacks, text rendering (even antialiased since the alpha component can get properly handled by blit commands) and UI rendering.
:) or is this idea too heretical?
Holger
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
