On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds <[email protected]> wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <[email protected]> wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
>
> I'm certainly ok with this. which way should it go in? The users are:
>
> - drivers/tty/vt/vt.c (Greg KH, "tty layer")
>
> - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
>
> and it might make sense to have *some* indication of how much worse
> this makes fbcon performance in particular..
For devices that have no hardware scrolling it used to be double digit
percentages difference between 32 and 64bit when reading from the fb
because the reads are not posted and the latency killed you. Writes - not
so big a deal - but the bridge should combine them anyway. I imagine
16bit read would be unprintably bad.
Is it reads or writes that kill the card ?
Also note that switching to lots of small writes may break the 3Dfx
driver for the early 3Dfx PCI cards - they are really quite touchy about
how they are fed.
Unfortunately fbcon still matters for dumb EFI framebuffer fallbacks.
vgacon it doesn't matter (if it was too slow you could make vgacon as
fast as you want by only updating the off screen characters once per
vertical blank). fbcon that is a bit harder as you are allowed to
scribble on the display as well. You can't even check open/mmapped as you
can open, scribble and close.
Alan
On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
<[email protected]> wrote:
> On Thu, 29 Jan 2015 15:40:33 -0800
> Linus Torvalds <[email protected]> wrote:
>
>> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <[email protected]> wrote:
>> >
>> > Linus, this came up a while back I finally got some confirmation
>> > that it fixes those servers.
>>
>> I'm certainly ok with this. which way should it go in? The users are:
>>
>> - drivers/tty/vt/vt.c (Greg KH, "tty layer")
>>
>> - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
>>
>> and it might make sense to have *some* indication of how much worse
>> this makes fbcon performance in particular..
>
> For devices that have no hardware scrolling it used to be double digit
> percentages difference between 32 and 64bit when reading from the fb
> because the reads are not posted and the latency killed you. Writes - not
> so big a deal - but the bridge should combine them anyway. I imagine
> 16bit read would be unprintably bad.
Fbcon uses scr_mem{cpy,move}w() for the VT buffer (characters + attributes)
only, not for the frame buffer data.
So the performance degradation should be minimal.
However, as this affects real VGA on x86 only, perhaps it can be fixed
in arch/x86/include/asm/vga.h instead of include/linux/vt_buffer.h, so
platforms not having VGA are not affected? We have these VT_BUF_*
and scr_*() abstractions for a reason...
If I'm not mistaken, that would be as simple as adding
#define VT_BUF_HAVE_RW.
#define scr_writew(val, addr) (*(addr) = (val))
#define scr_readw(addr) (*(addr))
to arch/x86/include/asm/vga.h.
If someone wants to put one of the "bad" VGA cards in a non-x86 PCI slot,
perhaps a few more architecture-specific asm/vga.h have to be updated:
$ git grep -w VT_BUF_HAVE_RW -- arch
arch/alpha/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/mips/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/powerpc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/sparc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/tile/include/asm/vga.h:#define VT_BUF_HAVE_RW
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
> If I'm not mistaken, that would be as simple as adding
>
> #define VT_BUF_HAVE_RW.
> #define scr_writew(val, addr) (*(addr) = (val))
> #define scr_readw(addr) (*(addr))
>
> to arch/x86/include/asm/vga.h.
and stick an
#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
#endif
around that and its sorted as an option everyone can leave off but the
afflicted.
Alan
On 5 February 2015 at 11:35, One Thousand Gnomes
<[email protected]> wrote:
>> If I'm not mistaken, that would be as simple as adding
>>
>> #define VT_BUF_HAVE_RW.
>> #define scr_writew(val, addr) (*(addr) = (val))
>> #define scr_readw(addr) (*(addr))
>>
>> to arch/x86/include/asm/vga.h.
>
> and stick an
>
> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>
> #endif
>
> around that and its sorted as an option everyone can leave off but the
> afflicted.
Well, given all the distros will enable that, might as well be #if
!defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <[email protected]> wrote:
> On 5 February 2015 at 11:35, One Thousand Gnomes
> <[email protected]> wrote:
>>> If I'm not mistaken, that would be as simple as adding
>>>
>>> #define VT_BUF_HAVE_RW.
>>> #define scr_writew(val, addr) (*(addr) = (val))
>>> #define scr_readw(addr) (*(addr))
>>>
>>> to arch/x86/include/asm/vga.h.
>>
>> and stick an
>>
>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>
>> #endif
>>
>> around that and its sorted as an option everyone can leave off but the
>> afflicted.
>
> Well, given all the distros will enable that, might as well be #if
> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
All distros on 1 out of 29 architectures?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On 9 February 2015 at 10:49, Geert Uytterhoeven <[email protected]> wrote:
> On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <[email protected]> wrote:
>> On 5 February 2015 at 11:35, One Thousand Gnomes
>> <[email protected]> wrote:
>>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>>
>>> #endif
>>>
>>> around that and its sorted as an option everyone can leave off but the
>>> afflicted.
>>
>> Well, given all the distros will enable that, might as well be #if
>> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
>
> All distros on 1 out of 29 architectures?
It's a fairly popular architecture.
On Mon, 9 Feb 2015 11:00:55 +0000
Daniel Stone <[email protected]> wrote:
> On 9 February 2015 at 10:49, Geert Uytterhoeven <[email protected]> wrote:
> > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <[email protected]> wrote:
> >> On 5 February 2015 at 11:35, One Thousand Gnomes
> >> <[email protected]> wrote:
> >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
> >>>
> >>> #endif
> >>>
> >>> around that and its sorted as an option everyone can leave off but the
> >>> afflicted.
> >>
> >> Well, given all the distros will enable that, might as well be #if
> >> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
> >
> > All distros on 1 out of 29 architectures?
>
> It's a fairly popular architecture.
I imagine most distros wouldn't enable it even on x86. It's an incredibly
obscure setup from the evidence of how long it took to get reported.
Most distributions don't support non PAE processors and other far more
common things 8)
Alan