Linux Media Controller development
 help / color / mirror / Atom feed
From: "Frantisek Rysanek" <Frantisek.Rysanek@post.cz>
To: linux-media@vger.kernel.org
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Subject: Re: Support for 2D engines/blitters in V4L2 and DRM
Date: Thu, 09 May 2019 11:16:30 +0200	[thread overview]
Message-ID: <5CD3EFEE.5732.6BF8A27D@Frantisek.Rysanek.post.cz> (raw)
In-Reply-To: <6ffb32e804a27557ca49216c4d8f117837c78f4e.camel@bootlin.com>

Dear gentlemen,

I've noticed your debate - the topic is something simple enough for 
me to superficially grasp and "blitting in the DRI/drmfb" is 
something I've been wondering about for a while.
Thanks for sharing your insight.

What actually prompted me to respond is this:
vaguely in the context of your debate, this is what Google has 
revealed to my casual query on the topic:

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Mesa-Blitter
-RIP

It's not a blow at the heart of the hypothetical "blitting API in 
DRI", but given the market share of Intel, it does look like a splash 
of cold water in the broader context, or does it?
If the "DRI blitting API" should go forward, could the Intel DRI 
driver in the kernel maybe take inspiration from MESA's approach?

I know I know - Intel may be strongish in the desktop and general x86 
market, but apart from the Nvidia vs. AMD wars, Linux actually runs 
on a number of non-x86 embedded SoCs that have a plethora of small 
proprietary GPU's, the CPU horsepower and RAM bandwidth may be scarce 
(though not as a rule), X11 is not mandatory and HW blitting may 
actually matter...

Frank Rysanek

  reply	other threads:[~2019-05-09  9:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17 18:10 Support for 2D engines/blitters in V4L2 and DRM Paul Kocialkowski
2019-04-18  8:18 ` Daniel Vetter
2019-04-18  8:54   ` Paul Kocialkowski
2019-04-18  9:09     ` Tomasz Figa
2019-04-18  9:13       ` Paul Kocialkowski
2019-04-18  9:21         ` Tomasz Figa
2019-04-19  0:30   ` Nicolas Dufresne
2019-04-19  4:27     ` Tomasz Figa
2019-04-19 15:31       ` Nicolas Dufresne
2019-04-22  4:02         ` Tomasz Figa
2019-04-19  8:38     ` Paul Kocialkowski
2019-04-24  8:31       ` Michel Dänzer
2019-04-24 12:01         ` Nicolas Dufresne
2019-04-24 14:39           ` Michel Dänzer
2019-04-24 14:41             ` Paul Kocialkowski
2019-04-24 15:06               ` Daniel Vetter
2019-04-24 15:44                 ` Nicolas Dufresne
2019-04-24 16:54                   ` Michel Dänzer
2019-04-24 17:43                     ` Nicolas Dufresne
2019-04-25 15:17                       ` Michel Dänzer
2019-04-24 12:19         ` Paul Kocialkowski
2019-04-24 17:10           ` Michel Dänzer
2019-05-06  8:28 ` Pekka Paalanen
2019-05-09  8:32   ` Paul Kocialkowski
2019-05-09  9:16     ` Frantisek Rysanek [this message]
2019-05-09 12:48       ` Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5CD3EFEE.5732.6BF8A27D@Frantisek.Rysanek.post.cz \
    --to=frantisek.rysanek@post.cz \
    --cc=linux-media@vger.kernel.org \
    --cc=paul.kocialkowski@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox