Re: [Nouveau] MediaWriter & Nouveau
[...] = "basic" render $ QSG_INFO=1 mediawriter Debug: QSG: basic render loop ((null):0, (null)) Debug: texture atlas dimensions: 1024x512 ((null):0, (null)) Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null)) Debug: Depth Buffer: 24 ((null):0, (null)) Debug: Stencil Buffer: 8 ((null):0, (null)) Debug: Samples:-1 ((null):0, (null)) Debug: GL_VENDOR: nouveau ((null):0, (null)) Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null)) Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null)) Debug: GL_EXTENSIONS: ... Debug: Max Texture Size: 8192 ((null):0, (null)) Debug: Debug context: false ((null):0, (null)) ... $ ps -C mediawriter -o cmd,%cpu CMD %CPU mediawriter 30.1 = "windows" render $ QSG_INFO=1 QSG_RENDER_LOOP=windows mediawriter Debug: windows render loop ((null):0, (null)) Debug: Using sg animation driver ((null):0, (null)) Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null)) Debug: texture atlas dimensions: 1024x512 ((null):0, (null)) Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null)) Debug: Depth Buffer: 24 ((null):0, (null)) Debug: Stencil Buffer: 8 ((null):0, (null)) Debug: Samples:-1 ((null):0, (null)) Debug: GL_VENDOR: nouveau ((null):0, (null)) Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null)) Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null)) Debug: GL_EXTENSIONS: ... Debug: Max Texture Size: 8192 ((null):0, (null)) Debug: Debug context: false ((null):0, (null)) ... $ ps -C mediawriter -o cmd,%cpu CMD %CPU mediawriter 41.2 = "threaded" render $ QSG_INFO=1 QSG_RENDER_LOOP=threaded mediawriter Debug: threaded render loop ((null):0, (null)) Debug: Using sg animation driver ((null):0, (null)) Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null)) Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null)) Debug: texture atlas dimensions: 1024x512 ((null):0, (null)) Debug: R/G/B/A Buffers:8 8 8 0 ((null):0, (null)) Debug: Depth Buffer: 24 ((null):0, (null)) Debug: Stencil Buffer: 8 ((null):0, (null)) Debug: Samples:-1 ((null):0, (null)) Debug: GL_VENDOR: nouveau ((null):0, (null)) Debug: GL_RENDERER:Gallium 0.4 on NV98 ((null):0, (null)) Debug: GL_VERSION: 3.0 Mesa 13.0.0-rc2 ((null):0, (null)) Debug: GL_EXTENSIONS: ... Debug: Max Texture Size: 8192 ((null):0, (null)) Debug: Debug context: false ((null):0, (null)) ... $ ps -C mediawriter -o cmd,%cpu CMD %CPU mediawriter 18.3 ... Debug: animation driver switched to timer mode ((null):0, (null)) Debug: animation driver switched to vsync mode ((null):0, (null)) Debug: Animation Driver: using vsync: 16.67 ms ((null):0, (null)) Debug: texture atlas dimensions: 1024x512 ((null):0, (null)) Segmentation fault (core dumped) QSGRenderThread[8636]: segfault at 8 ip 7f9138a4320f sp 7f911cd908f0 error 4 in libdrm_nouveau.so.2.0.0[7f9138a3f000+7000] = About $ rpm -q mediawriter mediawriter-4.0.3-2.fc26.x86_64 built without "threaded" render: $ grep sed mediawriter.spec -A2 sed -i /threaded/s/^/\\/\\// app/main.cpp %build $ rpm -q qt5-qtbase-devel qt5-qtdeclarative-devel qt5-qtbase-devel-5.7.0-9.fc26.x86_64 qt5-qtdeclarative-devel-5.7.0-2.fc25.x86_64 = Conclusion From the nouveau perspective, "threaded" render is "out of scope". Ref. Force threaded run loop for QML - Fixes high CPU load https://github.com/MartinBriza/MediaWriter/commit/63492f4 Qt Quick Scene Graph - Scene Graph and Rendering https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98577] New: Graphical issues with the game SOMA
https://bugs.freedesktop.org/show_bug.cgi?id=98577 Bug ID: 98577 Summary: Graphical issues with the game SOMA Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: ovarieg...@yahoo.com QA Contact: nouveau@lists.freedesktop.org Created attachment 127730 --> https://bugs.freedesktop.org/attachment.cgi?id=127730&action=edit Incorrectly rendered steam with GK110B In the proprietary game SOMA (GOG version) the steam (Hot air) will render incorrectly. Otherwise the game will run correctly with nouveau. Unfortunately llvmpipe will blackscreen when trying to replay the trace and it will occur with both DRI3 and DRI2. So I sent the trace to a friend using amd (R9 290) and he was not able to reproduce it. Here is the trace - http://ks392457.kimsufi.com/orbea/stuff/trace/Soma.bin.x86_64.trace.xz (Size: 652M) I am testing this with a GTX 780 Ti (GK110B). libdrm-2016.10.21_2d8c01f_master-x86_64-1_git mesa-2016.11.02_d2861d6_master-x86_64-1_git -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98577] Graphical issues with the game SOMA
https://bugs.freedesktop.org/show_bug.cgi?id=98577 --- Comment #1 from ovarieg...@yahoo.com --- Created attachment 127731 --> https://bugs.freedesktop.org/attachment.cgi?id=127731&action=edit Correctly rendered steam with amd (R9 290). -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98582] New: A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension
https://bugs.freedesktop.org/show_bug.cgi?id=98582 Bug ID: 98582 Summary: A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: hoboprim...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 127737 --> https://bugs.freedesktop.org/attachment.cgi?id=127737&action=edit dmesg I have a dual-graphics laptop, intel+nvidia. With the 'nouveau' module loaded, the laptop doesn't resume fully, with the screen staying blank. 'rmmod'-ing the nouveau driver, resuming works fine. This used to work in the past few years, the problem appeared with Fedora 25. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension
https://bugs.freedesktop.org/show_bug.cgi?id=98582 --- Comment #3 from hoboprim...@gmail.com --- Created attachment 127740 --> https://bugs.freedesktop.org/attachment.cgi?id=127740&action=edit lshw -c display -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension
https://bugs.freedesktop.org/show_bug.cgi?id=98582 --- Comment #1 from hoboprim...@gmail.com --- Created attachment 127738 --> https://bugs.freedesktop.org/attachment.cgi?id=127738&action=edit lspci -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension
https://bugs.freedesktop.org/show_bug.cgi?id=98582 --- Comment #2 from hoboprim...@gmail.com --- Created attachment 127739 --> https://bugs.freedesktop.org/attachment.cgi?id=127739&action=edit dmidecode -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] gr: fallback to legacy paths during firmware lookup
Hi Alex, On 2 November 2016 at 04:54, Alexandre Courbot wrote: > + /* see if this firmware has a legacy path */ > + if (!strcmp(fwname, "fecs_inst")) > + legacy_fwname = "fuc409c"; > + else if (!strcmp(fwname, "fecs_data")) > + legacy_fwname = "fuc409d"; > + else if (!strcmp(fwname, "gpccs_inst")) > + legacy_fwname = "fuc41ac"; > + else if (!strcmp(fwname, "gpccs_data")) > + legacy_fwname = "fuc41ad"; > + Just an idea: If one's going for this route (and not Ilia's suggestion) it's worth moving this in the legacy function. As-is things look really weird ? Thanks Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] gr: fallback to legacy paths during firmware lookup
On 11/02/2016 03:52 PM, Alexandre Courbot wrote:
> On 11/02/2016 02:07 PM, Ilia Mirkin wrote:
>> On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot
>> wrote:
>>> Look for firmware files using the legacy ("nouveau/nvxx_fuc") path
>>> if they cannot be found in the new, "official" path. User setups were
>>> broken by the switch, which is bad.
>>>
>>> There are only 4 firmware files we may want to look up that way, so
>>> hardcode them into the lookup function. All new firmware files should
>>> use the standard "nvidia//gr/" path.
>>>
>>> Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external
>>> firmwares")
>>> Signed-off-by: Alexandre Courbot
>>> ---
>>> drm/nouveau/nvkm/engine/gr/gf100.c | 56
>>> ++
>>> 1 file changed, 51 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c
>>> b/drm/nouveau/nvkm/engine/gr/gf100.c
>>> index 157919c788e6..9e65adbab21c 100644
>>> --- a/drm/nouveau/nvkm/engine/gr/gf100.c
>>> +++ b/drm/nouveau/nvkm/engine/gr/gf100.c
>>> @@ -1756,24 +1756,70 @@ gf100_gr_ = {
>>> };
>>>
>>> int
>>> +gf100_gr_ctor_fw_legacy(struct gf100_gr *gr, const char *fwname,
>>> + struct gf100_gr_fuc *fuc)
>>> +{
>>> + struct nvkm_subdev *subdev = &gr->base.engine.subdev;
>>> + struct nvkm_device *device = subdev->device;
>>> + const struct firmware *fw;
>>> + char f[32];
>>> + int ret;
>>> +
>>> + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset,
>>> fwname);
>>> + ret = request_firmware(&fw, f, device->dev);
>>> + if (ret) {
>>> + snprintf(f, sizeof(f), "nouveau/%s", fwname);
>>> + ret = request_firmware(&fw, f, device->dev);
>>> + if (ret) {
>>> + nvkm_error(subdev, "failed to load %s\n", fwname);
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + fuc->size = fw->size;
>>> + fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
>>> + release_firmware(fw);
>>> + return (fuc->data != NULL) ? 0 : -ENOMEM;
>>> +}
>>> +
>>> +int
>>> gf100_gr_ctor_fw(struct gf100_gr *gr, const char *fwname,
>>> struct gf100_gr_fuc *fuc)
>>> {
>>> struct nvkm_subdev *subdev = &gr->base.engine.subdev;
>>> struct nvkm_device *device = subdev->device;
>>> + const char *legacy_fwname = NULL;
>>> const struct firmware *fw;
>>> int ret;
>>>
>>> ret = nvkm_firmware_get(device, fwname, &fw);
>>> - if (ret) {
>>> + /* firmware found, success! */
>>> + if (!ret) {
>>> + fuc->size = fw->size;
>>> + fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
>>> + nvkm_firmware_put(fw);
>>> + return (fuc->data != NULL) ? 0 : -ENOMEM;
>>> + }
>>> +
>>> + /* see if this firmware has a legacy path */
>>> + if (!strcmp(fwname, "fecs_inst"))
>>> + legacy_fwname = "fuc409c";
>>> + else if (!strcmp(fwname, "fecs_data"))
>>> + legacy_fwname = "fuc409d";
>>> + else if (!strcmp(fwname, "gpccs_inst"))
>>> + legacy_fwname = "fuc41ac";
>>> + else if (!strcmp(fwname, "gpccs_data"))
>>> + legacy_fwname = "fuc41ad";
>>
>> As I mentioned on IRC, I find this strcmp thing a little jarring. It
>> should be pretty easy to just pass the legacy fwname into
>> gf100_gr_ctor_fw directly - there are only a handful of callers, and
>> most would just pass NULL in as the legacy fwname - only the ones in
>> gf100.c would pass the "old" names in.
>
> Yeah, that was the original approach actually. I switched to this for
> the following reasons:
>
> - We don't want to encourage using this legacy path, hence hiding it
> from callers
> - There are only 4 possible legacy files - it's ugly but still
> manageable and contained in a single function
I agree.
>
> Of course, if the general consensus is that this is too ugly, it would
> be trivial to turn it the way you suggested, so I don't feel too
> strongly for one approach over the other.
As it is a legacy path, I'm more for hiding it away in ctor_legacy() as
Emil suggests.
Ben.
signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] gr: fallback to legacy paths during firmware lookup
On 11/04/2016 07:29 AM, Ben Skeggs wrote:
> * PGP Signed by an unknown key
>
> On 11/02/2016 03:52 PM, Alexandre Courbot wrote:
>> On 11/02/2016 02:07 PM, Ilia Mirkin wrote:
>>> On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot
>>> wrote:
Look for firmware files using the legacy ("nouveau/nvxx_fuc") path
if they cannot be found in the new, "official" path. User setups were
broken by the switch, which is bad.
There are only 4 firmware files we may want to look up that way, so
hardcode them into the lookup function. All new firmware files should
use the standard "nvidia//gr/" path.
Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external
firmwares")
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/gf100.c | 56
++
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c
b/drm/nouveau/nvkm/engine/gr/gf100.c
index 157919c788e6..9e65adbab21c 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1756,24 +1756,70 @@ gf100_gr_ = {
};
int
+gf100_gr_ctor_fw_legacy(struct gf100_gr *gr, const char *fwname,
+ struct gf100_gr_fuc *fuc)
+{
+ struct nvkm_subdev *subdev = &gr->base.engine.subdev;
+ struct nvkm_device *device = subdev->device;
+ const struct firmware *fw;
+ char f[32];
+ int ret;
+
+ snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset,
fwname);
+ ret = request_firmware(&fw, f, device->dev);
+ if (ret) {
+ snprintf(f, sizeof(f), "nouveau/%s", fwname);
+ ret = request_firmware(&fw, f, device->dev);
+ if (ret) {
+ nvkm_error(subdev, "failed to load %s\n", fwname);
+ return ret;
+ }
+ }
+
+ fuc->size = fw->size;
+ fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
+ release_firmware(fw);
+ return (fuc->data != NULL) ? 0 : -ENOMEM;
+}
+
+int
gf100_gr_ctor_fw(struct gf100_gr *gr, const char *fwname,
struct gf100_gr_fuc *fuc)
{
struct nvkm_subdev *subdev = &gr->base.engine.subdev;
struct nvkm_device *device = subdev->device;
+ const char *legacy_fwname = NULL;
const struct firmware *fw;
int ret;
ret = nvkm_firmware_get(device, fwname, &fw);
- if (ret) {
+ /* firmware found, success! */
+ if (!ret) {
+ fuc->size = fw->size;
+ fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
+ nvkm_firmware_put(fw);
+ return (fuc->data != NULL) ? 0 : -ENOMEM;
+ }
+
+ /* see if this firmware has a legacy path */
+ if (!strcmp(fwname, "fecs_inst"))
+ legacy_fwname = "fuc409c";
+ else if (!strcmp(fwname, "fecs_data"))
+ legacy_fwname = "fuc409d";
+ else if (!strcmp(fwname, "gpccs_inst"))
+ legacy_fwname = "fuc41ac";
+ else if (!strcmp(fwname, "gpccs_data"))
+ legacy_fwname = "fuc41ad";
>>>
>>> As I mentioned on IRC, I find this strcmp thing a little jarring. It
>>> should be pretty easy to just pass the legacy fwname into
>>> gf100_gr_ctor_fw directly - there are only a handful of callers, and
>>> most would just pass NULL in as the legacy fwname - only the ones in
>>> gf100.c would pass the "old" names in.
>>
>> Yeah, that was the original approach actually. I switched to this for
>> the following reasons:
>>
>> - We don't want to encourage using this legacy path, hence hiding it
>> from callers
>> - There are only 4 possible legacy files - it's ugly but still
>> manageable and contained in a single function
> I agree.
>
>>
>> Of course, if the general consensus is that this is too ugly, it would
>> be trivial to turn it the way you suggested, so I don't feel too
>> strongly for one approach over the other.
> As it is a legacy path, I'm more for hiding it away in ctor_legacy() as
> Emil suggests.
Makes sense - will respin later today.
Thanks!
Alex.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
