Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1538225 > unrolled thread

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 02:10 +0100
    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-12-08 09:10 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:30 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:50 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:20 +0100
    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 11:20 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 13:20 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 15:20 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 15:30 +0100
            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-12-08 15:40 +0100
              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 15:50 +0100
                Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 16:30 +0100
                  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:40 +0100
                    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 23:00 +0100
                      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:40 +0100
                        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:50 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100
                            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 14:40 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 22:20 +0100
                        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-09 13:40 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Lucas Stach <l.stach@pengutronix.de> - 2016-12-09 14:20 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 14:40 +0100
                            Re: [RFC PATCH 0/3] staging: remove fbdev drivers David Herrmann <dh.herrmann@gmail.com> - 2016-12-09 15:00 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 15:10 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 21:40 +0100
                  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:40 +0100
            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Jani Nikula <jani.nikula@linux.intel.com> - 2016-12-08 16:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 15:30 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 23:40 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Dave Airlie <airlied@gmail.com> - 2016-12-09 01:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-09 09:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1539322

Hi Ben,

On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> So it is possible, only reason vram dumb buffers look worse is that there's
>> only 3 and no one cares about them, vs about 20 and a very active community
>> of contributors (also for core drm improvements) for the other case.
>
> Well, we could move offb to drm while at it I suppose that would be another
> one (offb is the "dumb driver based on pre-programmed output by firmware).

That would indeed be a great example.

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

[toc] | [prev] | [next] | [standalone]

#1539332

Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boot some servers. And there's definitely lots of room for more
> > shared code for those, and also some better infrastructure and helpers to
> > share more cod and make them better.
> > 
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you. 
> 
> Do they work if the system/DMA memory has to be physically contiguous
> and at a fixed address ? The AST "ARM side" GPU is like that.

Yes, CMA is exactly the solution for that. It provides contiguous memory
that doesn't need to be removed from the normal Linux memory handling
and allows for the CMA region to be at specific places if needed. It's
just a matter of describing the constraints properly.

Regards,
Lucas

[toc] | [prev] | [next] | [standalone]

#1539355

On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boot some servers. And there's definitely lots of room for more
> > shared code for those, and also some better infrastructure and helpers to
> > share more cod and make them better.
> > 
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you. 
> 
> Do they work if the system/DMA memory has to be physically contiguous
> and at a fixed address ? The AST "ARM side" GPU is like that.

Yeah, if you wire up the dma_alloc_coherent to cma you'll get a contiguous
buffer pinned into place.

> > So it is possible, only reason vram dumb buffers look worse is that there's
> > only 3 and no one cares about them, vs about 20 and a very active community
> > of contributors (also for core drm improvements) for the other case.
> 
> Well, we could move offb to drm while at it I suppose that would be another
> one (offb is the "dumb driver based on pre-programmed output by firmware).

One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1539362

Hey

On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > So it is possible, only reason vram dumb buffers look worse is that there's
>> > only 3 and no one cares about them, vs about 20 and a very active community
>> > of contributors (also for core drm improvements) for the other case.
>>
>> Well, we could move offb to drm while at it I suppose that would be another
>> one (offb is the "dumb driver based on pre-programmed output by firmware).
>
> One of the still in-flight drm drivers is the simpledrm thing meant for
> all kinds of firmware drivers like efifb and similar things on arm for
> pre-programmed output set up by firmware. I.e. no modeset support and
> otherwise a lot of fake to make it work as drm driver, but the idea that
> it's good enough until your real drm driver takes over.

The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.

Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.

The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.

Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.

Thanks
David

[toc] | [prev] | [next] | [standalone]

#1539368

On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote:
> Hey
> 
> On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> > So it is possible, only reason vram dumb buffers look worse is that there's
> >> > only 3 and no one cares about them, vs about 20 and a very active community
> >> > of contributors (also for core drm improvements) for the other case.
> >>
> >> Well, we could move offb to drm while at it I suppose that would be another
> >> one (offb is the "dumb driver based on pre-programmed output by firmware).
> >
> > One of the still in-flight drm drivers is the simpledrm thing meant for
> > all kinds of firmware drivers like efifb and similar things on arm for
> > pre-programmed output set up by firmware. I.e. no modeset support and
> > otherwise a lot of fake to make it work as drm driver, but the idea that
> > it's good enough until your real drm driver takes over.
> 
> The x86 platform device fixups for SimpleDRM went in some weeks ago,
> so maybe I should resend the patches. The driver could easily do
> 'offb'-like devices as well. Trivial to add.
> 
> Anyway, Benjamin is right, we always do shadow buffering for trivial
> drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
> dirty-ioctl. Reason is that we cannot easily expose the real
> framebuffer in DRM via FB-objects. But I also never saw a use-case for
> it, since all trivial devices I worked with were only either used as
> fallback or nobody cared for performance.
> 
> The generic DRM API is designed for dynamic FB allocation. If your
> hardware does not allow you to change the scanout source, you will
> have a hard time trying to expose the static buffers via the dynamic
> FB-object API. Furthermore, all DRM user-space expects dynamic FB
> management to work, preferably without a ridiculously low memory
> limit. That's also why I never bothered changing the drivers.
> 
> Despite all of this I still see no reason why a driver could not
> expose the static, real frambuffers via private ioctls. You can get
> all your fancy acceleration that way. Then fix user-space to use this
> API. If enough drivers end up with something similar, move it into the
> core. Just like we always do in DRM.

Well, we don't need a private abi. If we dynamically remap the mmaps and
fixup fbdev to do the same then we could redirect frontbuffer rendering
for the currently displaying buffer to the static, real framebuffer. That
would fix the perf issues Ben is fearing I think.

And if we do some nice ttm helpers to hide this all to the level the cma
helpers are just plug-in-and-go then it'd be real nice I think. But thus
far no one has cared enough yet to make that happen.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1539649

On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote:
> Despite all of this I still see no reason why a driver could not
> expose the static, real frambuffers via private ioctls. You can get
> all your fancy acceleration that way. Then fix user-space to use this
> API. If enough drivers end up with something similar, move it into the
> core. Just like we always do in DRM.

I don't care so much about userspace in my specific use case, more
about fbcon, which I think can be solved without too many hoops.

As for FB objects, my thinking is we could just use
unmap_mapping_ranges() to effectively change the mapping under the hood
of the app so it alternatively maps a bit of fb or a bit of memory...

Cheers,
Ben.

[toc] | [prev] | [next] | [standalone]

#1539189

On Thu, Dec 08, 2016 at 04:21:34PM +0100, Daniel Vetter wrote:
> [back from my walk, the sunset here is stellar ;-)]
> 
> On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> > Hi Thomas,
> > 
> > On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> > > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> > >> > Wut. We have like 20+ small atomic drivers nowdays.
> > >>
> > >> That's fast! Only two weeks ago you said:
> > >>
> > >> | Bummer, they still haven't landed. But afaik there's at least 4 of
> > >> | them floating around in various places ...
> > >
> > > You're not talking about the same thing I believe.
> > >
> > > When Daniel says "small atomic drivers", he talks about the relatively
> > > small DRM drivers for SoC display controllers, such as the ones you can
> > > find in ARM SoCs.
> > >
> > > When you say "small driver", you're thinking about drivers for I2C or
> > > SPI connected displays.
> > 
> > No, I wasn't thinking about I2C or SPI connected displays, but about simple
> > dumb memory-mapped frame buffers, which is what fbdev was initially
> > developed for.
> 
> Yeah, small drivers like these we have piles now, things exploded a lot
> after atomic landed two years ago. And they seem to shrink with every
> release a bit more (since lots more drivers gives you lots more insight
> into what other refactorings would make sense). Those we have a big pile
> of, and nowadays (at least with developers expirienced with upstream, but
> not necessarily with drm) it takes but a few weeks from initial submission
> to getting them merged.
> 
> What we don't yet have a nice tidy example driver of is the even simpler
> "dumb framebuffer behind a slow bus with explicit/manual upload", for like
> small i2c/spi panels (and conceptually also usb, even though there bw and
> panel size are a bit scaled up). We've gained some really nice helpers for
> this this year, and there's 3 drivers in-flight to make use of it. But
> since that's right now just a hobbyist effort it's moving a bit slower
> (and I was mistaken a few weeks back where I assumed that one of them
> landed already).

Correction, MXSFB just landed, which is the first driver using the simple
display pipe helpers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1538599

On Thu, 08 Dec 2016, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> If you're this good at mainting gpu and display subsystems, maybe you
>> want to take over?
>
> No please ;-)

Now that is indeed the right answer, and the attitude we're looking for!
Being able to say "no", especially wrt fbdev drivers, is a must have
quality. You're hired! ;D

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1538571

Dear dri-devel folks,

My sincere apologies for hitting send on that mail. I got real mad and
angry and typed a mail I shouldn't have submitted - pouring oil into
flames for shit and giggles just doesn't help anyone, and it detracts from
moving things forward and improving the code and drivers and everything in
a friendly and constructive fashion. I want to be part of a great
community, this wasnt :(

/me out and off for a walk

Thanks, Daniel

On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> > On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> > >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> > >> > Since the fbdev framework is in maintenance mode and all new display drivers
> > >> > should be made with the DRM framework, remove the fbdev drivers from staging.
> > >> >
> > >> > Note: the patches are created with git format-patch -D, so they can't be
> > >> > applied. Only for review.
> > >>
> > >> I missed the discussion where this decision was made, I admit I am
> > >> unimpressed by it.
> > >>
> > >> DRM drivers don't strike me as suitable for small/slow cores with dumb
> > >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> > >> BMCs.
> > >
> > > We have a helper for simple drivers now, if you take into account the
> > > massive helper libraries for everything that comes along with drm I expect
> > > if even dumb panels behind slow spi buses drm is now the more suitable
> > > subsytem.
> > 
> > This has been going on your years:
> >   1. Fbdev is obsolete, everybody should use DRM instead!
> >   2. Can you please point me to a small sample driver for a dumb frame buffer?
> >   3. Several are being written, but none of them is upstream yet.
> >   4. Goto 1.
> 
> Wut. We have like 20+ small atomic drivers nowdays.
> 
> > >> With drmfb you basically have to shadow everything into memory & copy
> > >> over everything, and locks you out of simple 2D accel. For a simple text
> > >> console the result is orders of magnitude slower and memory hungry than
> > >> a simple fbdev.
> > >
> > > Not true, we have full fbdev emulation, and drivers can implement the 2d
> > > accel in there. And a bunch of them do. It's just that most teams decided
> > > that this is pointless waste of their time.j
> > >
> > >> At least that was the case last I looked at the DRM stuff with Dave,
> > >> maybe things have changed...
> > >>
> > >> Not everything has a powerful 3D GPU.
> > >
> > > That's correct, and drm can cope. And compared to fbdev there's a very
> > > active community who improves&refactors it every kernel release to make it
> > > even better. Since about 2 years (when atomic landed) we merge new drivers at
> > > a rate of 2-3 per kernel release, and those new drivers get ever simpler
> > > and smaller thanks to all this work.
> > 
> > You mean the kind of refactoring that causes severe merge conflicts between
> > drm-next and Linus' tree about every single day?
> > (sorry, couldn't resist ;-)
> 
> Yeah, for a subsystem that only consists of 10% of the overall kernel (by
> patch count) we do an extremly shitty job. Maybe we should just all slow
> down and stop merging support for new hw, and fuck Android and CrOS and
> the billions of devices that don't ship upstream, who cares about those
> folks.
> 
> If you're this good at mainting gpu and display subsystems, maybe you want
> to take over?
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1538932

On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
> > With drmfb you basically have to shadow everything into memory & copy
> > over everything, and locks you out of simple 2D accel. For a simple text
> > console the result is orders of magnitude slower and memory hungry than
> > a simple fbdev.
> 
> Not true, we have full fbdev emulation, and drivers can implement the 2d
> accel in there. And a bunch of them do. It's just that most teams decided
> that this is pointless waste of their time.j

Ok so my knowledge might be outdated here. I was complaining to Dave about
how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
buffered everything, and Dave made the point that you basically had to do
that for security reasons that I mostly forgot the details of.

It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
then cool. Can you point me to a drmfb driver that is a good (and not too
complex) example with simple 2d accel ? I'm thinking mostly of color
expansion, bitblt and solid fill for fbcon, the way I used to do it in
radeonfb for example.

> > At least that was the case last I looked at the DRM stuff with Dave,
> > maybe things have changed... 
> > 
> > Not everything has a powerful 3D GPU.
> 
> That's correct, and drm can cope. And compared to fbdev there's a very
> active community who improves&refactors it every kernel release to make it
> even better. Since about 2 years (when atomic landed) we merge new drivers at
> a rate of 2-3 per kernel release, and those new drivers get ever simpler
> and smaller thanks to all this work.

Yeah it's hard to follow from outside :-) As I said above, it would
help if you could point to a good modern example driver to use as
reference.

Thanks !

Cheers,
Ben.

[toc] | [prev] | [next] | [standalone]

#1538969

On 9 December 2016 at 07:28, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>> > With drmfb you basically have to shadow everything into memory & copy
>> > over everything, and locks you out of simple 2D accel. For a simple text
>> > console the result is orders of magnitude slower and memory hungry than
>> > a simple fbdev.
>>
>> Not true, we have full fbdev emulation, and drivers can implement the 2d
>> accel in there. And a bunch of them do. It's just that most teams decided
>> that this is pointless waste of their time.j
>
> Ok so my knowledge might be outdated here. I was complaining to Dave about
> how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
> buffered everything, and Dave made the point that you basically had to do
> that for security reasons that I mostly forgot the details of.
>
> It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
> then cool. Can you point me to a drmfb driver that is a good (and not too
> complex) example with simple 2d accel ? I'm thinking mostly of color
> expansion, bitblt and solid fill for fbcon, the way I used to do it in
> radeonfb for example.

What are people using fbcon for that needs acceleration, this is where I get
a bit lost.

It's a console, if you aren't sshing into the machine.

It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.

The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly. It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).

Dave.

[toc] | [prev] | [next] | [standalone]

#1539173

Hi Dave,

On Fri, Dec 9, 2016 at 1:08 AM, Dave Airlie <airlied@gmail.com> wrote:
> On 9 December 2016 at 07:28, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
>>> > With drmfb you basically have to shadow everything into memory & copy
>>> > over everything, and locks you out of simple 2D accel. For a simple text
>>> > console the result is orders of magnitude slower and memory hungry than
>>> > a simple fbdev.
>>>
>>> Not true, we have full fbdev emulation, and drivers can implement the 2d
>>> accel in there. And a bunch of them do. It's just that most teams decided
>>> that this is pointless waste of their time.j
>>
>> Ok so my knowledge might be outdated here. I was complaining to Dave about
>> how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
>> buffered everything, and Dave made the point that you basically had to do
>> that for security reasons that I mostly forgot the details of.
>>
>> It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
>> then cool. Can you point me to a drmfb driver that is a good (and not too
>> complex) example with simple 2d accel ? I'm thinking mostly of color
>> expansion, bitblt and solid fill for fbcon, the way I used to do it in
>> radeonfb for example.
>
> What are people using fbcon for that needs acceleration, this is where I get
> a bit lost.
>
> It's a console, if you aren't sshing into the machine.
>
> It's main purpose should just be for gathering oopses and you've a lot better
> chance of getting an oops if you don't have some sketchy gpu accel in the way.

Unless you're using the console as a text console, and don't run e.g. X on top.

> The acceleration that most of the 2D things provide isn't ever that
> great, and shadowing is a lot more effective if done properly. It's a feature
> that kernel ppl obsess over but I don't get a lot of real world feedback,
> (booting 9000 scsi nodes with debug on takes a long time was possibly
> something I heard once, and I think we resolved).

It all depends on the complex balance between GPU performance, CPU performance,
CPU-to-frame buffer bandwidth, and amount of available system RAM.

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

[toc] | [prev] | [next] | [standalone]

#1539301

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote:
> What are people using fbcon for that needs acceleration, this is where I get
> a bit lost.
> 
> It's a console, if you aren't sshing into the machine.
> 
> It's main purpose should just be for gathering oopses and you've a lot better
> chance of getting an oops if you don't have some sketchy gpu accel in the way.

There are other uses for systems running Linux than being a server or desktop :-)

> The acceleration that most of the 2D things provide isn't ever that
> great, and shadowing is a lot more effective if done properly.

Not with a 400Mhz ARM9 processor on a fairly high res display. In these
case basic old things like color expansion for font rendering, bit
blits and solid fills for scrolls work beautifully. Anyway I just
realized that the ARM side of the AST GPU doesn't have the accel bits
at all anyway, only the host side, so I'm back to just a dumb FB. I
still want to avoid the copies though.

>  It's a feature
> that kernel ppl obsess over but I don't get a lot of real world feedback,
> (booting 9000 scsi nodes with debug on takes a long time was possibly
> something I heard once, and I think we resolved).

Ben.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web