Re: [Nouveau] [PATCH 1/2] drm/nouveau: add staging module option
On 21 May 2015 at 16:04, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs skeg...@gmail.com wrote:
On 21 May 2015 at 15:49, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs skeg...@gmail.com wrote:
On 20 May 2015 at 15:56, Alexandre Courbot acour...@nvidia.com wrote:
Add a module option allowing to enable staging/unstable APIs. This will
allow us to experiment freely with experimental APIs for a while before
setting them in stone.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drm/nouveau/nouveau_drm.c | 18 ++
drm/nouveau/uapi/drm/nouveau_drm.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 89049335b738..e4bd6ed51e73 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, disable (0), force enable
(1), optimus only default (-1
int nouveau_runtime_pm = -1;
module_param_named(runpm, nouveau_runtime_pm, int, 0400);
+MODULE_PARM_DESC(staging, enable staging APIs);
+int nouveau_staging = 0;
+module_param_named(staging, nouveau_staging, int, 0400);
+
static struct drm_driver driver_stub;
static struct drm_driver driver_pci;
static struct drm_driver driver_platform;
@@ -895,6 +899,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP,
nouveau_gem_ioctl_cpu_prep, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI,
nouveau_gem_ioctl_cpu_fini, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ /* Staging ioctls */
};
long
@@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
DRM_DEBUG_DRIVER(... runpm: %d\n, nouveau_runtime_pm);
DRM_DEBUG_DRIVER(... vram_pushbuf : %d\n, nouveau_vram_pushbuf);
DRM_DEBUG_DRIVER(... pstate : %d\n, nouveau_pstate);
+ DRM_DEBUG_DRIVER(... staging : %d\n, nouveau_staging);
}
static const struct dev_pm_ops nouveau_pm_ops = {
@@ -1088,6 +1094,18 @@ err_free:
static int __init
nouveau_drm_init(void)
{
+ /* Do not register staging ioctsl if option not specified */
+ if (!nouveau_staging) {
+ unsigned i;
+
+ /* This keeps us safe is no staging ioctls are defined */
+ i = min(driver_stub.num_ioctls,
DRM_NOUVEAU_STAGING_IOCTL);
+ while (!nouveau_ioctls[i - 1].func)
+ i--;
+
+ driver_stub.num_ioctls = i;
+ }
Hey Alex,
I've got no specific objection. But I'm curious as to why you took
this approach as opposed to just adding if (!nouveau_staging) return
-EINVAL; directly in the experimental ioctls?
Mainly because we will likely forget to add this check (or to remove
it) in some of the staging ioctls. The current solution doesn't
require us to think about that - and the less things to think about,
the better.
I think, in line with
what's been done in other places, having module options per-api is
perhaps a better choice too.
Do you mean that each experimental ioctl should have its own enable
option? I don't mind going that way if you think it is preferable. And
in that case my comment above is void.
That would be more preferable I think, and obvious as to what exactly
you're enabling.
But actually I wonder if having these experimental ioctls enabled as
compile options (either individually or as a whole) would not be
better. Some experimental ioctls may require code in staging (like the
PUSHBUF_2 ioctl that I would like to submit next), and I don't think
it is desirable to force extra code or kernel options (in this case,
CONFIG_STAGING) to Nouveau users who will not make use of them. I
remember that we concluded in favor or module options on IRC, but in
the light of this, wouldn't a config option be a less intrusive
choice?
Right, but the whole point of this is to encourage the ioctls to not
live there for too long, and progress to fully supported interfaces.
Definitely, but my concern is that doing this will make Nouveau depend
on STAGING for at least short periods of time. Do we really want this?
I admit to having slightly misread your last paragraph. For cases
such as thas, a config option that depends on STAGING *and* the kernel
parameter should be used.
What is pushbuf2 doing that requires staging btw? You've linked me to
patches previously, but I missed that.
Ben.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4] pmu/gk20a: PMU boot support
On 21 May 2015 at 16:03, Alexandre Courbot gnu...@gmail.com wrote:
On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs skeg...@gmail.com wrote:
On 12 May 2015 at 19:04, Alexandre Courbot gnu...@gmail.com wrote:
Hi Ben,
On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs skeg...@gmail.com wrote:
On 13 April 2015 at 20:42, Alexandre Courbot acour...@nvidia.com wrote:
Ben, I guess our main remaining concern with this patch is how it should
integrate wrt. the existing PMU code. Since it is designed to interact
with
the NVIDIA firmware, maybe we should use a different base code, or do you
think we can somehow share code and data structures?
Hey Alexandre,
Sorry for the delay in responding to this.
It is my turn to apologize - I was (well still am, technically :)) on
holidays and have just started unpiling my inbox...
My original thinking with transitioning to use NVIDIA's firmware was
that I'd modify our firmware interfaces to match yours, and share the
code. I haven't started on any of this yet due to not having any word
on how you guys will be shipping the images, etc. It would be nice to
have some communication on these things :)
Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware
will be required for GPUs to operate properly. This raises several
questions:
- Should the firmware be released under /lib/firmware/nouveau or
/lib/firmware/nvidia ? (this directory already exists for Tegra USB
firmware and makes more sense to me, since the firmware is not
Nouveau-specific)
I think /lib/firmware/nvidia makes sense here too.
- For GPCCS/FECS firmware, should we release the netlist pack file
or adopt the same format as Nouveau does? (1 file per firmware)
- Should we keep the current files names (e.g. nvxx_fuc[cd]), or
try to switch to more meaningful ones?
I'd actually prefer to have the entire netlists bundled, that gives us
updated reg/ctx production values too as you guys tweak/update them
for hw bugs (etc). They're also nicer in that you get a single bundle
of everything that's required for that chipset+engine.
Good for me - actually that's the solution I implemented first before
deciding to go à la Nouveau. ;) Some extra code will be needed, but
nothing crazy, and we will limit that feature to these chips for which
NVIDIA officially provides the firmware.
I don't have too much opinion on naming. The current model of
nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and
convenient to snprintf into a buffer :)
Since the firmware will be provided by us, shall we store it into
nvidia/chip/gpcfe.bin on linux-firmware?
Sounds fine.
- What about signature files that are required for secure boot?
As with above, if it's possible to ship them in a single file with the
ucode that it belongs to, that'd be ideal. It's not a huge deal
though.
So here we actually have several files - it is kind of a mess
actually. However I could probably merge them into a single netlist
file like we did for the GPC/FE CS code.
If that's possible, that'd be great.
- Knowing that NVIDIA's firmware ABI is a (very slowly) moving target,
it is worth to aim at ABI compatibility, or should we assume different
paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are
introduced in the way, how do we handle versioning?
For incompatible changes, I think appending a -VERSION to each
firmware blob is probably the simplest approach. The driver can
select the necessary codepath based on what it finds (probably trying
newer versions first, obviously).
I agree. Hopefully we won't have too much of this.
All these issues make me tend towards having a separate handling of
NVIDIA-released firmware (location, format, and ABI). It will also
make the firmware easier to release if conversions are not necessary
on the way out. What are your thoughts on this?
I'm not entirely set here, either way. I somewhat think that
initially I should adapt our interfaces to match, and a keep single
code path as long as we can. A lot of the changes so far have seemed
minor enough we could stick conditionals on firmware version, and if
fw changes come along that warrant a radical change in handling from
the host, we can abstract it away then.
But, I'm open to other suggestions :)
Right now my main concern is to get secure boot support in, and the
shortest path seems to be to not care about ABI compatibility between
Nouveau and NV firmwares (at least for PMU). Basically I am hoping
that you will agree to proceed this way in a first time. ^_^
If it's really that urgent, my suggestion is to submit the patches as
you did previously, keeping them confined to GK20A/GM20B, and I'll do
something nicer to support boards in general.
Frankly, I'd have had secure boot support in the driver already had
NVIDIA played things a little differently... Going forward, I'd like
to see NVIDIA not treating the Tegra parts of nouveau as a little
black box where anything
Re: [Nouveau] [PATCH v2] nouveau: add coherent BO attribute
On 21 May 2015 at 16:08, Alexandre Courbot acour...@nvidia.com wrote:
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectures for which coherency is not guaranteed by the bus.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Reviewed-by: Ben Skeggs bske...@redhat.com
---
Changes since v1:
None, just added Martin so he can merge the patch. R-b and A-b wanted. :)
include/drm/nouveau_drm.h | 1 +
nouveau/abi16.c | 3 +++
nouveau/nouveau.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index b18cad02419b..87aefc5e9d2f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
#define NOUVEAU_GEM_DOMAIN_VRAM (1 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 2)
#define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 3)
+#define NOUVEAU_GEM_DOMAIN_COHERENT (1 4)
#define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
#define NOUVEAU_GEM_TILE_16BPP 0x0001
diff --git a/nouveau/abi16.c b/nouveau/abi16.c
index 538f3a730dbe..4ca0bfbaf592 100644
--- a/nouveau/abi16.c
+++ b/nouveau/abi16.c
@@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
if (bo-flags NOUVEAU_BO_MAP)
info-domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;
+ if (bo-flags NOUVEAU_BO_COHERENT)
+ info-domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
+
if (!(bo-flags NOUVEAU_BO_CONTIG))
info-tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index a55e2b020778..4adda0e3594c 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -127,6 +127,7 @@ union nouveau_bo_config {
#define NOUVEAU_BO_MAP 0x8000
#define NOUVEAU_BO_CONTIG 0x4000
#define NOUVEAU_BO_NOSNOOP 0x2000
+#define NOUVEAU_BO_COHERENT 0x1000
struct nouveau_bo {
struct nouveau_device *device;
--
2.4.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4] pmu/gk20a: PMU boot support
On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs skeg...@gmail.com wrote:
On 12 May 2015 at 19:04, Alexandre Courbot gnu...@gmail.com wrote:
Hi Ben,
On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs skeg...@gmail.com wrote:
On 13 April 2015 at 20:42, Alexandre Courbot acour...@nvidia.com wrote:
Ben, I guess our main remaining concern with this patch is how it should
integrate wrt. the existing PMU code. Since it is designed to interact with
the NVIDIA firmware, maybe we should use a different base code, or do you
think we can somehow share code and data structures?
Hey Alexandre,
Sorry for the delay in responding to this.
It is my turn to apologize - I was (well still am, technically :)) on
holidays and have just started unpiling my inbox...
My original thinking with transitioning to use NVIDIA's firmware was
that I'd modify our firmware interfaces to match yours, and share the
code. I haven't started on any of this yet due to not having any word
on how you guys will be shipping the images, etc. It would be nice to
have some communication on these things :)
Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware
will be required for GPUs to operate properly. This raises several
questions:
- Should the firmware be released under /lib/firmware/nouveau or
/lib/firmware/nvidia ? (this directory already exists for Tegra USB
firmware and makes more sense to me, since the firmware is not
Nouveau-specific)
I think /lib/firmware/nvidia makes sense here too.
- For GPCCS/FECS firmware, should we release the netlist pack file
or adopt the same format as Nouveau does? (1 file per firmware)
- Should we keep the current files names (e.g. nvxx_fuc[cd]), or
try to switch to more meaningful ones?
I'd actually prefer to have the entire netlists bundled, that gives us
updated reg/ctx production values too as you guys tweak/update them
for hw bugs (etc). They're also nicer in that you get a single bundle
of everything that's required for that chipset+engine.
Good for me - actually that's the solution I implemented first before
deciding to go à la Nouveau. ;) Some extra code will be needed, but
nothing crazy, and we will limit that feature to these chips for which
NVIDIA officially provides the firmware.
I don't have too much opinion on naming. The current model of
nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and
convenient to snprintf into a buffer :)
Since the firmware will be provided by us, shall we store it into
nvidia/chip/gpcfe.bin on linux-firmware?
- What about signature files that are required for secure boot?
As with above, if it's possible to ship them in a single file with the
ucode that it belongs to, that'd be ideal. It's not a huge deal
though.
So here we actually have several files - it is kind of a mess
actually. However I could probably merge them into a single netlist
file like we did for the GPC/FE CS code.
- Knowing that NVIDIA's firmware ABI is a (very slowly) moving target,
it is worth to aim at ABI compatibility, or should we assume different
paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are
introduced in the way, how do we handle versioning?
For incompatible changes, I think appending a -VERSION to each
firmware blob is probably the simplest approach. The driver can
select the necessary codepath based on what it finds (probably trying
newer versions first, obviously).
I agree. Hopefully we won't have too much of this.
All these issues make me tend towards having a separate handling of
NVIDIA-released firmware (location, format, and ABI). It will also
make the firmware easier to release if conversions are not necessary
on the way out. What are your thoughts on this?
I'm not entirely set here, either way. I somewhat think that
initially I should adapt our interfaces to match, and a keep single
code path as long as we can. A lot of the changes so far have seemed
minor enough we could stick conditionals on firmware version, and if
fw changes come along that warrant a radical change in handling from
the host, we can abstract it away then.
But, I'm open to other suggestions :)
Right now my main concern is to get secure boot support in, and the
shortest path seems to be to not care about ABI compatibility between
Nouveau and NV firmwares (at least for PMU). Basically I am hoping
that you will agree to proceed this way in a first time. ^_^
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2] nouveau: add coherent BO attribute
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectures for which coherency is not guaranteed by the bus.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Changes since v1:
None, just added Martin so he can merge the patch. R-b and A-b wanted. :)
include/drm/nouveau_drm.h | 1 +
nouveau/abi16.c | 3 +++
nouveau/nouveau.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index b18cad02419b..87aefc5e9d2f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
#define NOUVEAU_GEM_DOMAIN_VRAM (1 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 2)
#define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 3)
+#define NOUVEAU_GEM_DOMAIN_COHERENT (1 4)
#define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
#define NOUVEAU_GEM_TILE_16BPP 0x0001
diff --git a/nouveau/abi16.c b/nouveau/abi16.c
index 538f3a730dbe..4ca0bfbaf592 100644
--- a/nouveau/abi16.c
+++ b/nouveau/abi16.c
@@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
if (bo-flags NOUVEAU_BO_MAP)
info-domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;
+ if (bo-flags NOUVEAU_BO_COHERENT)
+ info-domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
+
if (!(bo-flags NOUVEAU_BO_CONTIG))
info-tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index a55e2b020778..4adda0e3594c 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -127,6 +127,7 @@ union nouveau_bo_config {
#define NOUVEAU_BO_MAP 0x8000
#define NOUVEAU_BO_CONTIG 0x4000
#define NOUVEAU_BO_NOSNOOP 0x2000
+#define NOUVEAU_BO_COHERENT 0x1000
struct nouveau_bo {
struct nouveau_device *device;
--
2.4.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: add coherent BO attribute
On Wed, May 20, 2015 at 3:53 PM, Martin Peres martin.pe...@free.fr wrote: On 20/05/15 08:11, Alexandre Courbot wrote: On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst maar...@mblankhorst.nl wrote: Op 15-05-15 om 09:11 schreef Alexandre Courbot: Re-pinging Marteen on an email address that still exists :P On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot gnu...@gmail.com wrote: On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot acour...@nvidia.com wrote: On 03/14/2015 04:33 AM, Maarten Lankhorst wrote: Hey, Op 13-03-15 om 07:27 schreef Alexandre Courbot: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot acour...@nvidia.com I don't see a problem with this patch, but similar patches to intel to libdrm have been shot down when the changes weren't in an official kernel yet, so I think this should wait until the change is at least in drm-next. ;-) Sounds good. I will ping you again once the kernel change reaches -next. Hi Marteen, The kernel change required for this patch is now in -next. Do you think we can merge it now? I think it would be ok to merge now. Great - who could do this? :P I could do it. Please provide me with the patch with the necessary R-b and I can push it to our libdrm (and/or mesa). Thanks, I just sent a v2 with you included. I have yet to receive formal R-b and A-b for it though. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] drm/nouveau: add staging module option
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs skeg...@gmail.com wrote:
On 21 May 2015 at 15:49, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs skeg...@gmail.com wrote:
On 20 May 2015 at 15:56, Alexandre Courbot acour...@nvidia.com wrote:
Add a module option allowing to enable staging/unstable APIs. This will
allow us to experiment freely with experimental APIs for a while before
setting them in stone.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drm/nouveau/nouveau_drm.c | 18 ++
drm/nouveau/uapi/drm/nouveau_drm.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 89049335b738..e4bd6ed51e73 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, disable (0), force enable (1),
optimus only default (-1
int nouveau_runtime_pm = -1;
module_param_named(runpm, nouveau_runtime_pm, int, 0400);
+MODULE_PARM_DESC(staging, enable staging APIs);
+int nouveau_staging = 0;
+module_param_named(staging, nouveau_staging, int, 0400);
+
static struct drm_driver driver_stub;
static struct drm_driver driver_pci;
static struct drm_driver driver_platform;
@@ -895,6 +899,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP,
nouveau_gem_ioctl_cpu_prep, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI,
nouveau_gem_ioctl_cpu_fini, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+ /* Staging ioctls */
};
long
@@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
DRM_DEBUG_DRIVER(... runpm: %d\n, nouveau_runtime_pm);
DRM_DEBUG_DRIVER(... vram_pushbuf : %d\n, nouveau_vram_pushbuf);
DRM_DEBUG_DRIVER(... pstate : %d\n, nouveau_pstate);
+ DRM_DEBUG_DRIVER(... staging : %d\n, nouveau_staging);
}
static const struct dev_pm_ops nouveau_pm_ops = {
@@ -1088,6 +1094,18 @@ err_free:
static int __init
nouveau_drm_init(void)
{
+ /* Do not register staging ioctsl if option not specified */
+ if (!nouveau_staging) {
+ unsigned i;
+
+ /* This keeps us safe is no staging ioctls are defined */
+ i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
+ while (!nouveau_ioctls[i - 1].func)
+ i--;
+
+ driver_stub.num_ioctls = i;
+ }
Hey Alex,
I've got no specific objection. But I'm curious as to why you took
this approach as opposed to just adding if (!nouveau_staging) return
-EINVAL; directly in the experimental ioctls?
Mainly because we will likely forget to add this check (or to remove
it) in some of the staging ioctls. The current solution doesn't
require us to think about that - and the less things to think about,
the better.
I think, in line with
what's been done in other places, having module options per-api is
perhaps a better choice too.
Do you mean that each experimental ioctl should have its own enable
option? I don't mind going that way if you think it is preferable. And
in that case my comment above is void.
That would be more preferable I think, and obvious as to what exactly
you're enabling.
But actually I wonder if having these experimental ioctls enabled as
compile options (either individually or as a whole) would not be
better. Some experimental ioctls may require code in staging (like the
PUSHBUF_2 ioctl that I would like to submit next), and I don't think
it is desirable to force extra code or kernel options (in this case,
CONFIG_STAGING) to Nouveau users who will not make use of them. I
remember that we concluded in favor or module options on IRC, but in
the light of this, wouldn't a config option be a less intrusive
choice?
Right, but the whole point of this is to encourage the ioctls to not
live there for too long, and progress to fully supported interfaces.
Definitely, but my concern is that doing this will make Nouveau depend
on STAGING for at least short periods of time. Do we really want this?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4] pmu/gk20a: PMU boot support
On 21 May 2015 at 18:46, Ben Skeggs skeg...@gmail.com wrote:
On 21 May 2015 at 16:03, Alexandre Courbot gnu...@gmail.com wrote:
On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs skeg...@gmail.com wrote:
On 12 May 2015 at 19:04, Alexandre Courbot gnu...@gmail.com wrote:
Hi Ben,
On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs skeg...@gmail.com wrote:
On 13 April 2015 at 20:42, Alexandre Courbot acour...@nvidia.com wrote:
Ben, I guess our main remaining concern with this patch is how it should
integrate wrt. the existing PMU code. Since it is designed to interact
with
the NVIDIA firmware, maybe we should use a different base code, or do you
think we can somehow share code and data structures?
Hey Alexandre,
Sorry for the delay in responding to this.
It is my turn to apologize - I was (well still am, technically :)) on
holidays and have just started unpiling my inbox...
My original thinking with transitioning to use NVIDIA's firmware was
that I'd modify our firmware interfaces to match yours, and share the
code. I haven't started on any of this yet due to not having any word
on how you guys will be shipping the images, etc. It would be nice to
have some communication on these things :)
Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware
will be required for GPUs to operate properly. This raises several
questions:
- Should the firmware be released under /lib/firmware/nouveau or
/lib/firmware/nvidia ? (this directory already exists for Tegra USB
firmware and makes more sense to me, since the firmware is not
Nouveau-specific)
I think /lib/firmware/nvidia makes sense here too.
- For GPCCS/FECS firmware, should we release the netlist pack file
or adopt the same format as Nouveau does? (1 file per firmware)
- Should we keep the current files names (e.g. nvxx_fuc[cd]), or
try to switch to more meaningful ones?
I'd actually prefer to have the entire netlists bundled, that gives us
updated reg/ctx production values too as you guys tweak/update them
for hw bugs (etc). They're also nicer in that you get a single bundle
of everything that's required for that chipset+engine.
Good for me - actually that's the solution I implemented first before
deciding to go à la Nouveau. ;) Some extra code will be needed, but
nothing crazy, and we will limit that feature to these chips for which
NVIDIA officially provides the firmware.
I don't have too much opinion on naming. The current model of
nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and
convenient to snprintf into a buffer :)
Since the firmware will be provided by us, shall we store it into
nvidia/chip/gpcfe.bin on linux-firmware?
Sounds fine.
- What about signature files that are required for secure boot?
As with above, if it's possible to ship them in a single file with the
ucode that it belongs to, that'd be ideal. It's not a huge deal
though.
So here we actually have several files - it is kind of a mess
actually. However I could probably merge them into a single netlist
file like we did for the GPC/FE CS code.
If that's possible, that'd be great.
- Knowing that NVIDIA's firmware ABI is a (very slowly) moving target,
it is worth to aim at ABI compatibility, or should we assume different
paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are
introduced in the way, how do we handle versioning?
For incompatible changes, I think appending a -VERSION to each
firmware blob is probably the simplest approach. The driver can
select the necessary codepath based on what it finds (probably trying
newer versions first, obviously).
I agree. Hopefully we won't have too much of this.
All these issues make me tend towards having a separate handling of
NVIDIA-released firmware (location, format, and ABI). It will also
make the firmware easier to release if conversions are not necessary
on the way out. What are your thoughts on this?
I'm not entirely set here, either way. I somewhat think that
initially I should adapt our interfaces to match, and a keep single
code path as long as we can. A lot of the changes so far have seemed
minor enough we could stick conditionals on firmware version, and if
fw changes come along that warrant a radical change in handling from
the host, we can abstract it away then.
But, I'm open to other suggestions :)
Right now my main concern is to get secure boot support in, and the
shortest path seems to be to not care about ABI compatibility between
Nouveau and NV firmwares (at least for PMU). Basically I am hoping
that you will agree to proceed this way in a first time. ^_^
If it's really that urgent, my suggestion is to submit the patches as
you did previously, keeping them confined to GK20A/GM20B, and I'll do
something nicer to support boards in general.
Frankly, I'd have had secure boot support in the driver already had
NVIDIA played things a little differently... Going forward, I'd like
to see NVIDIA not
Re: [Nouveau] [PATCH v2] nouveau: add coherent BO attribute
On 21/05/2015 11:47, Ben Skeggs wrote: On 21 May 2015 at 16:08, Alexandre Courbot acour...@nvidia.com wrote: Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot acour...@nvidia.com Reviewed-by: Ben Skeggs bske...@redhat.com Pushed! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Handling GeForce GTX 850M GPU on Arch Linux
On 20 May 2015 at 17:11, cao...@mail2tor.com wrote: Ok thanks, I'll keep to it for now. Would you like me to (try to) fill a bug report report for that? By the way, if you come to work on that bug, I'll be glad to experiment your solution on my machine :) A bug report would be great. Could you also attach a mmiotrace[1] of the NVIDIA binary driver, and another log of nouveau failing with nouveau.debug=trace log_buf_len=1M in your kernel boot options. Thanks, Ben. [1] http://nouveau.freedesktop.org/wiki/MmioTrace/ Caocoa On 18.05.2015 01:46, Ilia Mirkin wrote: Your errors are most likely due to: [2.421428] nouveau [ PFB][:01:00.0] RAM size: 1975398418 MiB I'm guessing you don't *actually* have 1.9PB of VRAM. At least one other person with a GM108 was seeing a similar issue. You're getting a bunch of other failed reads, looks like we're somehow not bringing the card up properly. The most immediate fix is to just disable nouveau entirely -- boot with nouveau.modeset=0. Cheers, -ilia As the IGPs tend to steal system memory: [ 21.733864] nouveau [ PFB][:01:00.0] RAM type: stolen system memory [ 21.733883] nouveau [ PFB][:01:00.0] RAM size: 256 MiB [ 21.787222] nouveau [ DRM] VRAM: 256 MiB can we reverse the process in this case, and steal a few GB of VRAM for a system memory? I mean there are more than enough. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90569] [NV67] GUI freezes after startup of Ubuntu 15.04. on Aspire 7520p [BUG: unable to handle kernel paging request at f84c8000]
https://bugs.freedesktop.org/show_bug.cgi?id=90569 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Summary|GUI freezes after startup |[NV67] GUI freezes after |of Ubuntu 15.04. on Aspire |startup of Ubuntu 15.04. on |7520p [BUG: unable to |Aspire 7520p [BUG: unable |handle kernel paging|to handle kernel paging |request at f84c8000]|request at f84c8000] -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90569] New: GUI freezes after startup of Ubuntu 15.04. on Aspire 7520p [BUG: unable to handle kernel paging request at f84c8000]
https://bugs.freedesktop.org/show_bug.cgi?id=90569 Bug ID: 90569 Summary: GUI freezes after startup of Ubuntu 15.04. on Aspire 7520p [BUG: unable to handle kernel paging request at f84c8000] Product: xorg Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: je...@gmx.de QA Contact: xorg-t...@lists.x.org Created attachment 115959 -- https://bugs.freedesktop.org/attachment.cgi?id=115959action=edit System log file of 7 BUGs in nouveau Problem description: GUI freezes. No user interaction (mouse, keyboard) possible. Only hard shutdown possible. System specifications: -- - Operating System: Ubuntu 15.04. - Computer-Hardware: Acer Aspire 7520p - Graphic-Card: Nvidia 7000m Steps to reproduce: --- 1. Start Ubuntu and log in 2. wait or accelerate the freeze by 2.1. starting firefox 2.2. starting a terminal Why it looks like a nouveau bug? Well, I see something like the following in /var/log/systemlog each time, when the GUI freezes. (I compared the seconds of the clock with the log-entries and they match - always) Apr 29 22:16:06 h kernel: [ 78.633151] BUG: unable to handle kernel paging request at f84c8000 Apr 29 22:16:06 h kernel: [ 78.633265] IP: [f8fb6be9] nouveau_bo_wr32+0x29/0x60 [nouveau] Apr 29 22:16:06 h kernel: [ 78.633430] *pdpt = 01b79001 *pde = 34c88067 *pte = Apr 29 22:16:06 h kernel: [ 78.633546] Oops: 0002 [#1] SMP Apr 29 22:16:06 h kernel: [ 78.633596] Modules linked in: ctr ccm rfcomm bnep snd_hda_codec_realtek snd_hda_codec_generic arc4 acer_wmi sparse_keymap snd_hda_intel snd_hda_controller kvm_amd snd_hda_codec snd_hwdep kvm nouveau ath5k ath snd_pcm mxm_wmi ttm mac80211 joydev serio_raw edac_core cfg80211 drm_kms_helper snd_seq_midi k8temp edac_mce_amd snd_seq_midi_event drm r852 sm_common nand nand_ecc nand_bch i2c_algo_bit bch shpchp nand_ids snd_rawmidi mtd r592 memstick btusb snd_seq bluetooth snd_seq_device snd_timer snd ir_lirc_codec lirc_dev ir_xmp_decoder soundcore ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_rc6_mce ene_ir rc_core mac_hid wmi video i2c_nforce2 parport_pc ppdev lp parport autofs4 pata_acpi firewire_ohci sdhci_pci psmouse forcedeth sdhci ahci firewire_core libahci crc_itu_t pata_amd Apr 29 22:16:06 h kernel: [ 78.634843] CPU: 1 PID: 777 Comm: Xorg Not tainted 3.19.0-15-generic #15-Ubuntu Apr 29 22:16:06 h kernel: [ 78.634942] Hardware name: Acer Aspire 7520 /Fuquene, BIOS V1.30 12/31/2007 Apr 29 22:16:06 h kernel: [ 78.635055] task: edd7 ti: ec07e000 task.ti: ec07e000 Apr 29 22:16:06 h kernel: [ 78.635127] EIP: 0060:[f8fb6be9] EFLAGS: 00213246 CPU: 1 Apr 29 22:16:06 h kernel: [ 78.635246] EIP is at nouveau_bo_wr32+0x29/0x60 [nouveau] Apr 29 22:16:06 h kernel: [ 78.635317] EAX: c0164400 EBX: ECX: 00044130 EDX: f84c8000 Apr 29 22:16:06 h kernel: [ 78.635399] ESI: f84b8000 EDI: EBP: ec07fd94 ESP: ec07fd8c Apr 29 22:16:06 h kernel: [ 78.635481] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Apr 29 22:16:06 h kernel: [ 78.635552] CR0: 8005003b CR2: f84c8000 CR3: 32fa1000 CR4: 07f0 Apr 29 22:16:06 h kernel: [ 78.635633] Stack: Apr 29 22:16:06 h kernel: [ 78.635661] f4231044 c0168000 ec07fdfc f8fc398b 0001 a0ee6df4 ec161800 Apr 29 22:16:06 h kernel: [ 78.635783] 01b2 0020 f4c01d01 edd9cf80 Apr 29 22:16:06 h kernel: [ 78.635904] ee28 e94ce400 f22cd800 f4232000 c0168000 edd9cb40 ec161800 e784ac00 Apr 29 22:16:06 h kernel: [ 78.636025] Call Trace: Apr 29 22:16:06 h kernel: [ 78.636109] [f8fc398b] nouveau_crtc_page_flip+0x34b/0x780 [nouveau] Apr 29 22:16:06 h kernel: [ 78.636225] [f8a95328] drm_mode_page_flip_ioctl+0x198/0x300 [drm] Apr 29 22:16:06 h kernel: [ 78.636328] [f8a95190] ? drm_mode_gamma_get_ioctl+0xd0/0xd0 [drm] Apr 29 22:16:06 h kernel: [ 78.636425] [f8a861a5] drm_ioctl+0x1f5/0x560 [drm] Apr 29 22:16:06 h kernel: [ 78.636425] [c11bf66f] ? core_sys_select+0x18f/0x270 Apr 29 22:16:06 h kernel: [ 78.636425] [f8a95190] ? drm_mode_gamma_get_ioctl+0xd0/0xd0 [drm] Apr 29 22:16:06 h kernel: [ 78.636425] [c1348798] ? timerqueue_add+0x58/0xc0 Apr 29 22:16:06 h kernel: [ 78.636425] [c147b071] ? __pm_runtime_resume+0x51/0x70 Apr 29 22:16:06 h kernel: [ 78.636425] [f8faf7cb] nouveau_drm_ioctl+0x5b/0xb0 [nouveau] Apr 29 22:16:06 h kernel: [ 78.636425] [f8faf770] ? nouveau_pmops_thaw+0x20/0x20 [nouveau] Apr 29 22:16:06
Re: [Nouveau] Handling GeForce GTX 850M GPU on Arch Linux
OK, I'll do that when I'll have a bit more free time, but likely within the 10 next days. Shall I fill the report on this site[1] ? I've read this page[2], I'll try to comply to your needs :) Caocoa [1] https://bugs.freedesktop.org [2] https://wiki.freedesktop.org/nouveau/Bugs/ P.S.: I've previously sent this message only to the last replier instead of the mailing list, here I fix it. On 20 May 2015 at 17:11, cao...@mail2tor.com wrote: Ok thanks, I'll keep to it for now. Would you like me to (try to) fill a bug report report for that? By the way, if you come to work on that bug, I'll be glad to experiment your solution on my machine :) A bug report would be great. Could you also attach a mmiotrace[1] of the NVIDIA binary driver, and another log of nouveau failing with nouveau.debug=trace log_buf_len=1M in your kernel boot options. Thanks, Ben. [1] http://nouveau.freedesktop.org/wiki/MmioTrace/ Caocoa On 18.05.2015 01:46, Ilia Mirkin wrote: Your errors are most likely due to: [2.421428] nouveau [ PFB][:01:00.0] RAM size: 1975398418 MiB I'm guessing you don't *actually* have 1.9PB of VRAM. At least one other person with a GM108 was seeing a similar issue. You're getting a bunch of other failed reads, looks like we're somehow not bringing the card up properly. The most immediate fix is to just disable nouveau entirely -- boot with nouveau.modeset=0. Cheers, -ilia As the IGPs tend to steal system memory: [ 21.733864] nouveau [ PFB][:01:00.0] RAM type: stolen system memory [ 21.733883] nouveau [ PFB][:01:00.0] RAM size: 256 MiB [ 21.787222] nouveau [ DRM] VRAM: 256 MiB can we reverse the process in this case, and steal a few GB of VRAM for a system memory? I mean there are more than enough. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #1 from Detlev Casanova detlev.casan...@gmail.com --- Created attachment 115954 -- https://bugs.freedesktop.org/attachment.cgi?id=115954action=edit Nouveau error log - 2 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Handling GeForce GTX 850M GPU on Arch Linux
Your first reply did also sent it to the mailing list. :-) [1] is indeed the correct site to report the bug, with Product=xorg and Component=Driver/nouveau. Pierre On 21 May 2015, at 16:48, cao...@mail2tor.com wrote: OK, I'll do that when I'll have a bit more free time, but likely within the 10 next days. Shall I fill the report on this site[1] ? I've read this page[2], I'll try to comply to your needs :) Caocoa [1] https://bugs.freedesktop.org [2] https://wiki.freedesktop.org/nouveau/Bugs/ P.S.: I've previously sent this message only to the last replier instead of the mailing list, here I fix it. On 20 May 2015 at 17:11, cao...@mail2tor.com wrote: Ok thanks, I'll keep to it for now. Would you like me to (try to) fill a bug report report for that? By the way, if you come to work on that bug, I'll be glad to experiment your solution on my machine :) A bug report would be great. Could you also attach a mmiotrace[1] of the NVIDIA binary driver, and another log of nouveau failing with nouveau.debug=trace log_buf_len=1M in your kernel boot options. Thanks, Ben. [1] http://nouveau.freedesktop.org/wiki/MmioTrace/ Caocoa On 18.05.2015 01:46, Ilia Mirkin wrote: Your errors are most likely due to: [2.421428] nouveau [ PFB][:01:00.0] RAM size: 1975398418 MiB I'm guessing you don't *actually* have 1.9PB of VRAM. At least one other person with a GM108 was seeing a similar issue. You're getting a bunch of other failed reads, looks like we're somehow not bringing the card up properly. The most immediate fix is to just disable nouveau entirely -- boot with nouveau.modeset=0. Cheers, -ilia As the IGPs tend to steal system memory: [ 21.733864] nouveau [ PFB][:01:00.0] RAM type: stolen system memory [ 21.733883] nouveau [ PFB][:01:00.0] RAM size: 256 MiB [ 21.787222] nouveau [ DRM] VRAM: 256 MiB can we reverse the process in this case, and steal a few GB of VRAM for a system memory? I mean there are more than enough. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau smime.p7s Description: S/MIME cryptographic signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90567] New: Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 Bug ID: 90567 Summary: Display freeze when starting League of Legends (Wine) Product: xorg Version: 7.6 (2010.12) Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: detlev.casan...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 115953 -- https://bugs.freedesktop.org/attachment.cgi?id=115953action=edit Nouveau error log - 1 Up until recently, I was able to play League of Legends on Linux with Wine, using the open source driver nouveau. And that was with great performances. Since an upgrade of the game (I cannot go back to the old version though), everytime the game starts, The display freezes (sometimes after up to 5 seconds but it always does). The cursor is still moving but typing commands blindly doesn't seem to work. The network and SSH deamon being still running, I was able to collect some Kernel logs. I attach them. I also tried to go back to an older version of the Kernel in case the problem was in there but that did not help (So I can't bissect the kernel to find the possible bug) I am not sure if the game is doing something nasty or if there is a bug in the opensource driver. Logs show all kind of error messages I could find. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #2 from Detlev Casanova detlev.casan...@gmail.com --- Created attachment 115955 -- https://bugs.freedesktop.org/attachment.cgi?id=115955action=edit Nouveau error log - 3 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Fermi+ shader header docs
Hi Ilia, On Sat, May 02, 2015 at 12:34:21PM -0400, Ilia Mirkin wrote: Hi, As I'm looking to add some support to nouveau for features like atomic counters and images, I'm running into some confusion about what the first word of the shader header means. Here is the definition as we have it today: [...] However I know that these are somewhat wrong. I've seen shaders that use gmem accesses (i.e. mov r0, [r0]) that just have the LMEM enable bit set (and they use no lmem). And I've seen additional bits set, esp relating to images, but I haven't spent enough time looking at all the variations to make sense of it yet. For example, I think that Fermi and Kepler+ have different meanings for some of the bits. Those look pretty close :) I was hoping you could just release the docs for the shader headers, or at least the first word of the shader header. We've posted the specification for the full Shader Program Header to our GPU documentation site here: ftp://download.nvidia.com/open-gpu-doc/Shader-Program-Header/1/Shader-Program-Header.html I hope it helps clear things up. - Robert ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90569] [NV67] GUI freezes after startup of Ubuntu 15.04. on Aspire 7520p [BUG: unable to handle kernel paging request at f84c8000]
https://bugs.freedesktop.org/show_bug.cgi?id=90569 --- Comment #1 from Ilia Mirkin imir...@alum.mit.edu --- Curious observation: [ 78.633151] BUG: unable to handle kernel paging request at f84c8000 [ 78.633265] IP: [f8fb6be9] nouveau_bo_wr32+0x29/0x60 [nouveau] [ 78.633430] *pdpt = 01b79001 *pde = 34c88067 *pte = [ 50.751850] BUG: unable to handle kernel paging request at f84c8000 [ 50.751967] IP: [f8f51be9] nouveau_bo_wr32+0x29/0x60 [nouveau] [ 50.752139] *pdpt = 01b79001 *pde = 34c88067 *pte = [ 68.844824] BUG: unable to handle kernel paging request at f8598000 [ 68.845087] IP: [f8f17be9] nouveau_bo_wr32+0x29/0x60 [nouveau] [ 68.845475] *pdpt = 01b79001 *pde = 34c88067 *pte = [ 183.768120] BUG: unable to handle kernel paging request at f8498000 [ 183.768233] IP: [f8e91be9] nouveau_bo_wr32+0x29/0x60 [nouveau] [ 183.768402] *pdpt = 01b79001 *pde = 34c88067 *pte = [ 107.772418] BUG: unable to handle kernel paging request at f848d000 [ 107.772538] IP: [f8e4cbe9] nouveau_bo_wr32+0x29/0x60 [nouveau] [ 107.772718] *pdpt = 01b79001 *pde = 34c88067 *pte = The pdpt/pde/pte values are always the same. Perhaps that's just the unmapped page or something. Other observations: 32-bit kernel. One instance of a cal_space exhaustion, but it recovered apparently. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Fermi+ shader header docs
On Thu, May 21, 2015 at 10:05 AM, Robert Morell rmor...@nvidia.com wrote: Hi Ilia, On Sat, May 02, 2015 at 12:34:21PM -0400, Ilia Mirkin wrote: Hi, As I'm looking to add some support to nouveau for features like atomic counters and images, I'm running into some confusion about what the first word of the shader header means. Here is the definition as we have it today: [...] However I know that these are somewhat wrong. I've seen shaders that use gmem accesses (i.e. mov r0, [r0]) that just have the LMEM enable bit set (and they use no lmem). And I've seen additional bits set, esp relating to images, but I haven't spent enough time looking at all the variations to make sense of it yet. For example, I think that Fermi and Kepler+ have different meanings for some of the bits. Those look pretty close :) I was hoping you could just release the docs for the shader headers, or at least the first word of the shader header. We've posted the specification for the full Shader Program Header to our GPU documentation site here: ftp://download.nvidia.com/open-gpu-doc/Shader-Program-Header/1/Shader-Program-Header.html I hope it helps clear things up. Yep, just a few follow-up questions: - SPH Type 1 and type 2 appear to be flipped wrt the tables -- When PS is used, field SphType in CommonWord0 must be set to 1; similarly, when VTG is used, SphType in CommonWord0 must be set to 2. But the Table 1. SPH Type 1 Definition is clearly meant for VTG and table 2 is clearly meant for PS... - You skip over SassVersion -- what is that? - You have a funny note in there -- Triangles generated by the geometry shader always have all their edge flags set to TRUE -- that is the *only* reference to edge flags in the whole document. Right now we do some crazy thing to get edge flags right on fermi+ (and I think we just get them wrong on tesla). Is there a way to emit edge flags from vertex shader? - To be clear: DoesLoadOrStore -- *any* load/store? Even LDC? ALD? Thanks! -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #3 from Ilia Mirkin imir...@alum.mit.edu --- The first error messages are the most informative. Can you provide a full dmesg log from boot until some of those errors happen? Also, what version of mesa are you using? If not the latest, please try with the latest. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
