On 22.10.24 10:38, Maxime Ripard wrote:
Hi,
I'm still interested in merging a carve-out driver[1], since it seems to be
in every vendor BSP and got asked again last week.
I remember from our discussion that for new heap types to be merged, we
needed a kernel use-case. Looking back, I'm not ent
n after this change, that
option will only show up if the user already enabled virtio in the config.
This change didn't cause any changes in the .config after menuconfig run,
so we should be completely safe here.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/gpu/drm/vir
eicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Hi folks,
I'm currently thinking about adding an hw-accelerated bitblt operation.
The idea goes like this:
* we add some bitblt ioctl which copies rects between bo's.
(it also handles memory layouts, pixfmt conversion, etc)
* the driver can decide to let the GPU or IPU do that, if available
*
On 02.08.2016 16:04, Daniel Vetter wrote:
> If you mean "add a generic hw-accelerated bitblt operation": This is not
> hw drm works. The generic kms stuff is about display only, with just very
> basic (hence "dumb") buffer allocation support in a generic way.
Well, if it already does buffer alloc
On 03.08.2016 01:12, Rob Clark wrote:
Hi,
>> Well, if it already does buffer allocation and mapping (which might
>> also involve copying around phyisical buffers), why not also add
>> copy-between-buffers ?
>
> except "dumb" buffers exist *only* for CPU rendered content, you
> cannot assume that
On 03.08.2016 05:47, Dave Airlie wrote:
> Because no hw is the same once you go beyond that.
hmm, it doesn't seem to be so extremly different, that we cant
at least abstract some common aspects.
> Video memory size means what? VRAM, GPU accessible system RAM,
> amount of CPU visible VRAM?
Actua
On 03.08.2016 11:24, Marek Szyprowski wrote:
Hi,
> I'm working now on something similar, but more generic. There is
> already a framework for picture processing (converting, scaling,
> blitting, rotating) in Exynos DRM.
In DRM, not v4l ? Hmm, interesting.
On mx5/mx6 we've got an IPU, which is a
On 03.08.2016 13:47, Daniel Vetter wrote:
> Because for optimal performance you _must_ supply the commands to the
> kernel in an as close to the format/layout used by the hardware as
> possible. That means no shared command submission of any kind. And the
> other reason is that cache transfers and
On 04.08.2016 09:50, Daniel Vetter wrote:
Hi,
> One problem with 2d blitters is that there's no common userspace
> interface, but many: Xrender, hwc, old X drawing api, various attempts by
> khronos to standardize something, cairo, ...
We're talking about userland APIs, not kernel->userland int
Hi folks,
when putting pixels into an DRM framebuffer, should I do that in
bursts/blocks instead of byte-per-byte ? (eg. explicitly using
aligned 32bit ops).
--mtx
On 05.08.2016 01:16, Enrico Weigelt, metux IT consult wrote:
Seems I've been on a completely wrong path - what I'm looking
for is dma-buf. So my idea now goes like this:
* add a new 'virtual GPU' as render node.
* the basic operations are:
-> create a virtual dumb f
On 05.08.2016 10:15, Daniel Vetter wrote:
Hi,
> There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> render into a shadow buffer and copy over in bursts, otherwise you
> can assume that the memory is fully cpu cached and fast with random
> access.
h!
nekrad at orion:~/src/lin
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/video/fbdev/Kconfig | 288 +++---
drivers/video/fbdev/mmp/Kconfig | 6 +-
drivers/video/fbdev/omap/Kconfig | 20 +-
drivers/video/fbdev/omap2/omapfb/Kconfig
gpu registers (more precisely
waiting for some changing), that's causing the soft lockup. (maybe too
big timeout ?)
Oh! By the way, the network card r8169 are work wonderful!
Didn't you say (above) that it does not work ?
Or is it just an immediate fail and later comes back ?
--mtx
, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
s: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ion:
when using it w/ gst for video playback, can be directly pass buffers
between VPU, IPU and FB (or let them directly write into shared
buffers), so CPU doesn't need to act on each frame for each step
in the decoding pipeline ?
Playing an 800x400 mp4 still produces about 70..75%.
cu
--
Enrico
river
> > (or the gpus itself) might talk to ipu and vpu ?
>
> Not that I am aware of.
Well, you perhaps can imagine - I dont trust these guys ...
--mtx
ps: greetings from Bene ... you won't guess where I met him
last weekend ;-)
--
Enrico Weigelt, metux IT consult
+49-
?
By the way: do you have any idea whether the proprietary driver
(or the gpus itself) might talk to ipu and vpu ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kan
-media list for review?
>
> No. That's all old stuff and has developed quite a lot since then. We'll
> post new series here on the lists when they are ready for mainline.
Great :)
Do you have them on some public repo, so I can give 'em a try ?
--mtx
--
Enrico Weigelt,
ty new to this area): how to GEM objects and
dma-bufs relate to each other ? Is it possible to directly exchange
buffers between GPUs, VPUs, IPUs, FBs, etc ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wi
gt; initialized in parallel.
Unfortunately, I've missed that ... could you please resend you patches?
Boot time reduction is one of the topics on my 2do in several weeks.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg
ails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
24 matches
Mail list logo
