Re: [RFC] drm: add kernel-log renderer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

On Fri, Mar 7, 2014 at 10:58 PM, One Thousand Gnomes
<gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
>>  - The renderer supports *any* RGB target, from 8bit to 32bit with
>>    big-endian and little-endian support. The related pixel-renderer will
>>    probably never win a beauty-contest, but it works.. Again, who cares
>>    for debug-log rendering speed?
>
> Debug log writing performance is extremely important when you are using
> the log for debugging work rather than for panic display. I don't think
> that is a show stopper because having a logger makes sense and someone
> can write a better render engine if they care.

I don't do damage-based rendering (useless if you don't do
hw-scrolling), therefore you can easily configure the higher-level API
to render in a 50ms (or even 500ms) interval if anything changed. This
should be suitable for other use-cases and avoids hogging the CPU like
VTs do. Furthermore, you can just avoid rendering until something
useful happened that you *want* to see. Last but not least, when
something goes wrong, the panic-handler will always print the latest
log, so that should contain all useful information.
Anyhow, I need specific use-cases to comment on that.

> Supporting any target is also going to be useful but you do need to
> support non linear framebuffers. A GMA500 with something like an X
> display in use for example does not have a linear mapping of the
> framebuffer memory. I don't believe its exactly unique in this.

Should be fairly easy to do. But as long as you can atomically flip to
a linear FB, that's not needed as you can use a separate FB for the
render-log (which is also what we currently do for fbdev-fallbacks).
But imho most drivers allow you to easily map it linearly via the GTT,
so I haven't bothered supported tiled setups. If drivers need that,
they can tell me what formats exactly to support and I can add that.

> What I am more dubious about is tying it to DRM. Yes it uses DRM
> constants but it doesn't appear functionally to have a single tie to
> either DRM or even framebuffer.
>
> It's potentially useful in cases where neither framebuffer or DRM are
> compiled into the system.

Using the four-cc constants makes sense, imho. Apart from that,
drm_log.c will stay generic as it is now. There is nothing
DRM-specific in there. All the higher-level helpers are separate in
drm_log_helpers.c (which is not posted here). However, I've spent
enough time trying to get the attention of core maintainers for simple
fixes, I really don't want to waste my time pinging on feature-patches
every 5 days to get any attention. If someone outside of DRM wants to
use it, I'd be happy to discuss any code-sharing. Until then, I'd like
to keep it here as people are willing to take it through their tree.

Cheers
David
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux