framebuffer general questions

framebuffer general questions

[René Kolařík]

Hi

i am trying to customize framebuffer drivers and i have some questions...

Please can you give me an advice? 

1) If I define my own imageblit function, how do I call it? Or is it called automatically?

2) I have gpu connected via pci to cpu. I did mmap and have framebuffer mapped in for example "uchar * data". I have loop and iterating through some pixel data and do data[i] = pixel[i]. Does this lead to transmitting via PCI in style - transmit byte ... end ... transmit byte ... end ... etc?

3)what is the difference bethween mmap framebuffer and write to mapped pointer and calling write() to descriptor previously obtained by open()?

these are the main questions in my mind. Thank you for your time i would be glad for any informations.

Rene

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: framebuffer general questions

[Ondrej Zajicek]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

On Fri, Nov 13, 2009 at 03:11:48PM +0100, René Kolařík wrote:
> Hi
> 
> i am trying to customize framebuffer drivers and i have some questions...
> 
> Please can you give me an advice? 
> 
> 1) If I define my own imageblit function, how do I call it? Or is it called automatically?

It is called automatically (if it is registered in fb_ops structure)
from kernel console. It is not possible to call it from userspace.

> 2) I have gpu connected via pci to cpu. I did mmap and have
> framebuffer mapped in for example "uchar * data". I have loop and
> iterating through some pixel data and do data[i] = pixel[i]. Does this
> lead to transmitting via PCI in style - transmit byte ... end ...
> transmit byte ... end ... etc?

Probably yes, perhaps there is some write combining according to MTRR
registers.

> 3)what is the difference bethween mmap framebuffer and write to mapped
> pointer and calling write() to descriptor previously obtained by open()?

The first variant is much faster - video RAM is directly mapped to userspace 
address space, therefore there is no kernel interaction during writes (in
usual fbdev drivers).

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: framebuffer general questions

[René Kolařík]

Thanks for your answer, but it implied some other questions :-)

You said, that accelerated functions are called from console - so programs wich are drawing directly to FB (like QT embedded in my case) have no profit from them? Or do they?

What is actually the best technique of using FB (for achieving the best performance) - should i malloc a piece of RAM, draw to it and then memmove it to FB mapped address as a whole frame or draw directly to FB? Or it doesnt matter?

When i greped through drivers sources i was expecting that accelerated drivers will use mmap only for registers and that the imageblit function would be implemented as some DMA fetching from system memory. But i was wrong, there are still mmaps to video memory. So i want to ask, if that idea is completely wrong and why drivers of GPUs use mmap to video mem, when they have DMA controller.

Thank you for your time.

Rene

>  ------------ Pùvodní zpráva ------------
>  Od: Ondrej Zajicek <santiago@crfreenet.org>
>  Pøedmìt: Re: [Linux-fbdev-devel] framebuffer general questions
>  Datum: 13.11.2009 21:06:52
>  ----------------------------------------
>  On Fri, Nov 13, 2009 at 03:11:48PM +0100, René Kolaøík wrote:
>  > Hi
>  > 
>  > i am trying to customize framebuffer drivers and i have some questions...
>  > 
>  > Please can you give me an advice? 
>  > 
>  > 1) If I define my own imageblit function, how do I call it? Or is it called
>  automatically?
>  
>  It is called automatically (if it is registered in fb_ops structure)
>  from kernel console. It is not possible to call it from userspace.
>  
>  > 2) I have gpu connected via pci to cpu. I did mmap and have
>  > framebuffer mapped in for example "uchar * data". I have loop and
>  > iterating through some pixel data and do data[i] = pixel[i]. Does this
>  > lead to transmitting via PCI in style - transmit byte ... end ...
>  > transmit byte ... end ... etc?
>  
>  Probably yes, perhaps there is some write combining according to MTRR
>  registers.
>  
>  > 3)what is the difference bethween mmap framebuffer and write to mapped
>  > pointer and calling write() to descriptor previously obtained by open()?
>  
>  The first variant is much faster - video RAM is directly mapped to userspace 
>  address space, therefore there is no kernel interaction during writes (in
>  usual fbdev drivers).
>  
>  -- 
>  Elen sila lumenn' omentielvo
>  
>  Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
>  OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
>  "To err is human -- to blame it on a computer is even more so."
>  
>  
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: framebuffer general questions

[Ondrej Zajicek]

[-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --]

On Mon, Nov 16, 2009 at 12:28:06AM +0100, René Kolařík wrote:
> Thanks for your answer, but it implied some other questions :-)
> 

> You said, that accelerated functions are called from console - so
> programs wich are drawing directly to FB (like QT embedded in my case)
> have no profit from them? Or do they?

They have no profit from them.

> What is actually the best technique of using FB (for achieving the
> best performance) - should i malloc a piece of RAM, draw to it and then
> memmove it to FB mapped address as a whole frame or draw directly to FB?
> Or it doesnt matter?

Depends on hardware and style of drawing. Dedicated graphics cards have
slower write (compared to main memory speed) and very slow read, so you
really don't want to do alpha-blending directly on mmaped framebuffer.

> When i greped through drivers sources i was expecting that accelerated
> drivers will use mmap only for registers and that the imageblit function
> would be implemented as some DMA fetching from system memory. But i was
> wrong, there are still mmaps to video memory. So i want to ask, if that
> idea is completely wrong and why drivers of GPUs use mmap to video mem,
> when they have DMA controller.

You mean fbdev drivers? FBdev API is designed to just allow mmap
framebuffer to userspace. It is not a good way to use modern GPU with
DMA transfers. Perhaps you could use DRI for that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel