<html><head></head><body>No, it is not my opinion. It is what was agreed collectively. Unlike your opinion, which engages only you.<br><br>I am very fed up with people misconstruing earlier decisions as my opinion. You can not have it both ways.<br><br><div class="gmail_quote">Le 9 août 2019 12:57:53 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-08-09 10:16, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi,<br><br>The MMAL plugins are unmaintained. By definition, if the implementation that actually sees users and updates is another one, then ours is unmaintained.<br><br>And the point is that I don't want to change the core for a misdesigned plugin. I have not seen any technically valid justification for adding yet another way to allocate pictures, nor how this would work.<br><br>You cannot expect software decoders and filters to allocate pictures from decoder device or video context. That's complete denial of everything that was agreed upon, and reintroduces a whole lot of problems that push was supposed to fix.<br></blockquote><br>That's your opinion and I don't share it. We made some design choices <br>but until they were implemented we had no idea if all use cases were <br>covered. And it turns out not all use cases are covered. With MMAL (be <br>it the old module or the new module) the design we have is not good <br>enough. We are forcing copies where they didn't exist before.<br><br>And what I propose is still push design. It's still the decoder that <br>creates a video context and pushes it forward. It just may not be aware <br>it's using it at all.<br><br>And as I experienced with this idea, for D3D11 it would make perfect <br>sense to allow the decoder device be the creator of video context. They <br>are highly related and one doesn't really exist without the other.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le 9 août 2019 08:50:43 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 2019-08-08 18:27, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Le torstaina 8. elokuuta 2019, 15.29.30 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Any opinion ?<br></blockquote>I don't see why we should mess the architecture for a<br></blockquote>hardware-specific<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">implementation-specific unmaintained module.<br></blockquote> It's not unmaintained, I was planning to revive it to make sure that<br> the<br> default player on Raspberry Pi remains VLC when we release 4.0. It<br> seems<br> there's a different implementation so I'll adapt that one.<br><br> One reason for that is to make sure our new push architecture is sound<br> and can adapt to many use cases. Supporting SoC architectures should<br> still be possible with the new architecture. Allocating all buffers<br> once<br> in the display was making this easy and efficient (in terms of copy,<br> not<br> memory usage). We should aim for the same level of efficiency.<br><br> Also let me remind you the VLC motto: "VLC plays everything and runs<br> everywhere".<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Even when the GPU uses the same RAM as the CPU, it typically uses<br></blockquote>different<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">pixel format, tile format and/or memory coherency protocol, or it<br></blockquote>might simply<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> not have a suitable IOMMU. As such, VLC cannot render directly in it.<br><br> And if it could, then by definition, it implies that the decoder and<br></blockquote>filters can<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">allocate and *reference* picture buffers as they see fit, regardless<br></blockquote>of the<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">hardware. Which means the software on CPU side is doing the<br></blockquote>allocation. If so,<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">then there are no good technical reasons why push cannot work -<br></blockquote>misdesigning<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">the display plugin is not a good reason.<br></blockquote> I haven't proposed any design change to the display plugin, other than<br> already discussed. What I proposed is a way to allocate CPU pictures<br>from the GPU. My current solution involves creating a video context <br> optionally when the decoder doesn't provide one.<br><br> It could even be used on desktop. For example on Intel platform it's<br> possible to do it without much performance penalty. I used to do it in<br> D3D11 until I realized it sucked for separate GPU memory. But I had no<br> way to know exactly the impact of the switch because the code was quite<br><br> different. Now it might be possible to tell. I have a feeling on Intel<br> it may actually be better to decode in "GPU" buffers directly. The<br> driver can take shortcuts that we can't. It may do the copy more<br> efficiently if it needs one (or maybe it doesn't need one). It can do<br> the copy asynchronously (as every command sent to a<br> ID3D11DeviceContext)<br> as long as it's ready when it needs to be displayed.<hr> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>