Should I use FBINFO_VIRTFB?

Should I use FBINFO_VIRTFB?

[Timur Tabi]

I'm cleaning up my fbdev driver, and I just noticed FBINFO_VIRTFB:

#define FBINFO_VIRTFB		0x0004 /* FB is System RAM, not device. */

I am currently not setting this flag, but I am allocating my framebuffer in system ram via dma_alloc_coherent().  I don't see any good documentation for this flag, but I suspect I should be enabling it.  What exactly does this flag do?

I'd also like some explanation for these two macros, which appear to be related:

#define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
#define FBINFO_READS_FAST	0x0080 /* soft-copy faster than rendering */

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Should I use FBINFO_VIRTFB?

[Konrad Rzeszutek Wilk]

On Thu, Dec 15, 2011 at 02:50:47PM -0600, Timur Tabi wrote:
> I'm cleaning up my fbdev driver, and I just noticed FBINFO_VIRTFB:
> 
> #define FBINFO_VIRTFB		0x0004 /* FB is System RAM, not device. */
> 
> I am currently not setting this flag, but I am allocating my framebuffer in system ram via dma_alloc_coherent().  I don't see any good documentation for this flag, but I suspect I should be enabling it.  What exactly does this flag do?

It basically inhibits from using VM_IO which should not be set on
System RAM. In your case you are using System RAM, so please do set it.

> 
> I'd also like some explanation for these two macros, which appear to be related:
> 
> #define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
> #define FBINFO_READS_FAST	0x0080 /* soft-copy faster than rendering */

Not really. They have a different function, but you are better of looking in the code
to see how they are used.
> 
> -- 
> Timur Tabi
> Linux kernel developer at Freescale
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Should I use FBINFO_VIRTFB?

[Timur Tabi]

Konrad Rzeszutek Wilk wrote:
>> > #define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
>> > #define FBINFO_READS_FAST	0x0080 /* soft-copy faster than rendering */

> Not really. They have a different function, but you are better of looking in the code
> to see how they are used.

Well, I tried that, which is why I said, "I don't see any good documentation."  FBINFO_PARTIAL_PAN_OK appears to be only used in one place:

case SCROLL_PAN_REDRAW:
	if ((p->yscroll + count <	     2 * (p->vrows - vc->vc_rows))
	    && ((!scroll_partial && (b - t = vc->vc_rows))
		|| (scroll_partial
		    && (b - t - count >
			3 * vc->vc_rows >> 2)))) {
		if (t > 0)
			fbcon_redraw_move(vc, p, 0, t, count);
		ypan_up_redraw(vc, t, count);
		if (vc->vc_rows - b > 0)
			fbcon_redraw_move(vc, p, b,
				  vc->vc_rows - b, b);
	} else
		fbcon_redraw_move(vc, p, t + count, b - t - count, t);
	fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
break;

I can't parse this, and I can't figure out if my driver is better off with or without FBINFO_PARTIAL_PAN_OK.

I have the same problem with FBINFO_READS_FAST.  

So I really would like someone explain these macros to me.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Should I use FBINFO_VIRTFB?

[Geert Uytterhoeven]

On Thu, Dec 15, 2011 at 23:10, Timur Tabi <timur@freescale.com> wrote:
> Konrad Rzeszutek Wilk wrote:
>>> > #define FBINFO_PARTIAL_PAN_OK      0x0040 /* otw use pan only for double-buffering */
>>> > #define FBINFO_READS_FAST  0x0080 /* soft-copy faster than rendering */
>
>> Not really. They have a different function, but you are better of looking in the code
>> to see how they are used.

> I can't parse this, and I can't figure out if my driver is better off with or without FBINFO_PARTIAL_PAN_OK.

This depends on which of these two is fastest for scrolling the console:
  - panning the virtual screen and redrawing the missing part: set
FBINFO_PARTIAL_PAN_OK
  - copying or redrawing the screen: don't set FBINFO_PARTIAL_PAN_OK

> I have the same problem with FBINFO_READS_FAST.

You should set this flag if reading from frame buffer memory is a fast
operation.
On many graphics devices, reading from frame buffer memory is much slower
than writing. As you use system RAM, you probably want to set it.

If this flag is set, scrolling is implemented by copying memory around.
If not set, scrolling is implemented by redrawing the whole screen.

A simple way to find the optimal settings of both flags (all 4 combinations) is
running "clear; time cat big_text_file" and comparing the timing results

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Should I use FBINFO_VIRTFB?

[Timur Tabi]

Geert Uytterhoeven wrote:

> This depends on which of these two is fastest for scrolling the console:
>   - panning the virtual screen and redrawing the missing part: set
> FBINFO_PARTIAL_PAN_OK
>   - copying or redrawing the screen: don't set FBINFO_PARTIAL_PAN_OK

I'm a little confused about panning support in my driver (which I didn't write -- I'm just cleaning it up).  There is .fb_pan_display function, but it only gets called early in the boot process, and only with xoffset=0 and yoffset=0.  After that, it never seems to get called again.  Under what circumstances is panning really used?

> 
>> I have the same problem with FBINFO_READS_FAST.
> 
> You should set this flag if reading from frame buffer memory is a fast
> operation.
> On many graphics devices, reading from frame buffer memory is much slower
> than writing. As you use system RAM, you probably want to set it.

I see a lot of drivers that set FBINFO_VIRTFB but don't set FBINFO_READS_FAST.  Why?  

> If this flag is set, scrolling is implemented by copying memory around.
> If not set, scrolling is implemented by redrawing the whole screen.
> 
> A simple way to find the optimal settings of both flags (all 4 combinations) is
> running "clear; time cat big_text_file" and comparing the timing results

That's the funny thing -- I've been trying various combinations of FBINFO_VIRTFB, FBINFO_PARTIAL_PAN_OK, and FBINFO_READS_FAST, and I always get the same timing result.  It seems to have no affect on performance.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Should I use FBINFO_VIRTFB?

[Geert Uytterhoeven]

On Fri, Dec 16, 2011 at 19:18, Timur Tabi <timur@freescale.com> wrote:
> Geert Uytterhoeven wrote:
>> This depends on which of these two is fastest for scrolling the console:
>>   - panning the virtual screen and redrawing the missing part: set
>> FBINFO_PARTIAL_PAN_OK
>>   - copying or redrawing the screen: don't set FBINFO_PARTIAL_PAN_OK
>
> I'm a little confused about panning support in my driver (which I didn't write -- I'm just cleaning it up).  There is .fb_pan_display function, but it only gets called early in the boot process, and only with xoffset=0 and yoffset=0.  After that, it never seems to get called again.  Under what circumstances is panning really used?

Is yres_virtual larger than yres? Is the font size a multiple of ypanstep?
If not, panning is disabled.

>>> I have the same problem with FBINFO_READS_FAST.
>>
>> You should set this flag if reading from frame buffer memory is a fast
>> operation.
>> On many graphics devices, reading from frame buffer memory is much slower
>> than writing. As you use system RAM, you probably want to set it.
>
> I see a lot of drivers that set FBINFO_VIRTFB but don't set FBINFO_READS_FAST.  Why?
>
>> If this flag is set, scrolling is implemented by copying memory around.
>> If not set, scrolling is implemented by redrawing the whole screen.
>>
>> A simple way to find the optimal settings of both flags (all 4 combinations) is
>> running "clear; time cat big_text_file" and comparing the timing results
>
> That's the funny thing -- I've been trying various combinations of FBINFO_VIRTFB, FBINFO_PARTIAL_PAN_OK, and FBINFO_READS_FAST, and I always get the same timing result.  It seems to have no affect on performance.

If panning is disabled, FBINFO_PARTIAL_PAN_OK doesn't do anything.
For FBINFO_READS_FAST, I can imagine that with a fast CPU and a good
writeback cache, redrawing the screen is as fast as copying data around.

It just means your hardware is well balanced ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Should I use FBINFO_VIRTFB?

[Timur Tabi]

Geert Uytterhoeven wrote:
>> > I'm a little confused about panning support in my driver (which I didn't write -- I'm just cleaning it up).  There is .fb_pan_display function, but it only gets called early in the boot process, and only with xoffset=0 and yoffset=0.  After that, it never seems to get called again.  Under what circumstances is panning really used?

> Is yres_virtual larger than yres? Is the font size a multiple of ypanstep?
> If not, panning is disabled.

I can't seem to get partial panning to "activate", no matter what I do.  I set 'flags' to FBINFO_DEFAULT | FBINFO_VIRTFB | FBINFO_PARTIAL_PAN_OK | FBINFO_READS_FAST.  I have a 1280x1024 monitor.  I set the virtual_size to 1280,1280 via sysfs.  Then I set panning to "0,100", and I see the screen scroll.  I tried sending a bunch of output to /dev/tty1, but no matter what I do, none of the SCROLL_PAN_REDRAW or SCROLL_PAN_MOVE case statements in fbcon_scroll() get executed.

At this point, should I just FBINFO_VIRTFB | FBINFO_PARTIAL_PAN_OK | FBINFO_READS_FAST and not worry about whether it really makes a difference?

-- 
Timur Tabi
Linux kernel developer at Freescale