From: Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 0/5] nouveau: unified firmware loading functions
Date: Mon, 18 Jan 2016 16:26:27 +1000 [thread overview]
Message-ID: <569C8593.3040907@redhat.com> (raw)
In-Reply-To: <CAKb7Uvh4kyYo509BJ=nuS6_Z2TAm09v=DN4qyf=r_6-7h3m68w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]
On 01/18/2016 04:20 PM, Ilia Mirkin wrote:
> On Mon, Jan 18, 2016 at 1:15 AM, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Jan 18, 2016 at 3:11 PM, Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
>>> All the video decoding firmware was *pretty* standard... I suspect
>>> ~everyone used my extraction script and it's sitting in
>>> /lib/firmware/nouveau for everyone who uses VDPAU. There are packages
>>> in several distributions which grab the nvidia blob, my script, and
>>> run the extraction on the end user's computer to avoid licensing
>>> complications. Please support the existing locations.
>>
>> Ok, so there *are* some end-users (not developers) relying on these
>> external firmwares?
>>
>> In that case probably the best thing to do is to not use these new
>> functions for video - at least for chips that do not require signed
>> firmware. All I'd like to do is reduce the number of occurences of the
>> "build path - load firmware" logic.
>
> Yep. And FWIW there were users of pgraph firmware loading with the old
> paths too :( For some users, the blob pgraph fw is stable while
> nouveau one isn't. But hopefully not that many, I think VDPAU has a
> lot more. VDPAU is currently supported through Kepler.
I don't think it's worth supporting the soon-to-be-old gr ucode paths
going forward. Our implementation of using the binary driver gr
firmware is pretty broken anyway (outside of Tegra), and works by
accident mostly. I suspect most (if not all) of the issues with our
ucode have been ironed out now too, no?
There's probably a legitimate case for keeping support for the video
paths, especially since we don't know if/when/what-form nvidia will
distrubute them in.
Ben.
>
> -ilia
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
prev parent reply other threads:[~2016-01-18 6:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 6:07 [PATCH 0/5] nouveau: unified firmware loading functions Alexandre Courbot
[not found] ` <1453097233-11838-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-18 6:07 ` [PATCH 1/5] core: add firmware handling functions Alexandre Courbot
[not found] ` <1453097233-11838-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-21 11:41 ` Emil Velikov
[not found] ` <CACvgo51AqAvTH5D9AUmzZWPQu+DkWnuGgms3-L8iL8S_tJyiNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-25 2:11 ` Alexandre Courbot
[not found] ` <CAAVeFuK+FpokzjphGweewv3N5v08isgcuRbpkfbWoxEB2L7a_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-27 0:24 ` Emil Velikov
2016-01-18 6:07 ` [PATCH 2/5] gr/gf100: use the nvkm_firmware functions Alexandre Courbot
2016-01-18 6:07 ` [PATCH 3/5] falcon: " Alexandre Courbot
2016-01-18 6:07 ` [PATCH 4/5] xtensa: " Alexandre Courbot
2016-01-18 6:07 ` [PATCH 5/5] bios: " Alexandre Courbot
2016-01-18 6:11 ` [PATCH 0/5] nouveau: unified firmware loading functions Ilia Mirkin
[not found] ` <CAKb7UvjAk-HBmJuyrLewK49qo_27trCtXW+oFW7TQ74rjNHsPQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-18 6:15 ` Alexandre Courbot
[not found] ` <CAAVeFu+n5H5WQgwhkPZXUP53SrGAG=e7EWmtUdTo1bNhFCgZhg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-18 6:20 ` Ilia Mirkin
[not found] ` <CAKb7Uvh4kyYo509BJ=nuS6_Z2TAm09v=DN4qyf=r_6-7h3m68w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-18 6:26 ` Ben Skeggs [this message]
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=569C8593.3040907@redhat.com \
--to=bskeggs-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.