search for: nouveau_drm_screen_create

...n equal check - Fails with 'Kernel rejected pushbuf'. From this I made the assumption that the screen represents some gpu context and thus the object space that is addressable. Also what I gathered from the libdrm code. - Copying the fd hash table from the radeon_drm_winsys_create() into nouveau_drm_screen_create(). That fails to work because vl_screen_create() and dri2CreateScreen() both create seperate drm fds resulting in different entries in the hash table (that's not the same - see next point) - static screen singleton (ignoring subsequent drm fds) however nouveau_drm_screen_create is duplicated...

Hi, I have a geforce 4mx 440 agp 8x, and I'm trying to use the GBM library, (as jbarnes in: http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/ and David Hermann in KMSCON: https://github.com/dvdhrm/kmscon), without success. when I try to create a gbm_device, I get: (below the code.) nouveau_drm_screen_create: unknown chipset nv18 dri_init_screen_helper: failed to create pipe_screen loaded /usr/lib/gbm/pipe_nouveau.so nouveau_drm_screen_create: unknown chipset nv18 failed to load driver: nouveau My question is: Is this not supported by the driver?, It's a GBM problem? or am I doing something wrong...

...sys/nouveau/drm/nouveau_drm_winsys.c +++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c @@ -1,4 +1,5 @@ #include <sys/stat.h> +#include <unistd.h> #include "pipe/p_context.h" #include "pipe/p_state.h" #include "util/u_format.h" @@ -75,7 +76,14 @@ nouveau_drm_screen_create(int fd) return &screen->base; } - ret = nouveau_device_wrap(fd, 0, &dev); + /* Since the screen re-use is based on the device node and not the fd, + * create a copy of the fd to be owned by the device. Otherwise a + * scenario could occur where two screens are created, and the f...

...These must be set before any failure is possible, as the cleanup > + * paths assume they're responsible for deleting them. > + */ > + screen->drm = nouveau_drm(&dev->object); > + screen->device = dev; > + > /* > * this is initialized to 1 in nouveau_drm_screen_create after screen > * is fully constructed and added to the global screen list. > @@ -175,8 +181,6 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) > data, size, &screen->channel); > if (ret) > return ret...

...e cleanup >>> + * paths assume they're responsible for deleting them. >>> + */ >>> + screen->drm = nouveau_drm(&dev->object); >>> + screen->device = dev; >>> + >>> /* >>> * this is initialized to 1 in nouveau_drm_screen_create after screen >>> * is fully constructed and added to the global screen list. >>> @@ -175,8 +181,6 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) >>> data, size, &screen->channel); >>>...

...mesa_debug = atoi(nv_dbg); + /* These must be set before any failure is possible, as the cleanup + * paths assume they're responsible for deleting them. + */ + screen->drm = nouveau_drm(&dev->object); + screen->device = dev; + /* * this is initialized to 1 in nouveau_drm_screen_create after screen * is fully constructed and added to the global screen list. @@ -175,8 +181,6 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) data, size, &screen->channel); if (ret) return ret; - screen->drm = no...

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

...y failure is possible, as the cleanup >> + * paths assume they're responsible for deleting them. >> + */ >> + screen->drm = nouveau_drm(&dev->object); >> + screen->device = dev; >> + >> /* >> * this is initialized to 1 in nouveau_drm_screen_create after screen >> * is fully constructed and added to the global screen list. >> @@ -175,8 +181,6 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) >> data, size, &screen->channel); >> if (ret) >&g...

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

From: Ben Skeggs <bskeggs at redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b6680d0..965c6f7 100644 --- a/configure.ac +++ b/configure.ac @@ -72,8 +72,8 @@ LIBDRM_REQUIRED=2.4.60

...In mesa, it is possible to build the driver you want (nouveau_vieux, nv30, > nv50 or nvc0) so the feature is already there. Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 are all linked together in the nouveau driver, no way to split them out, largely because of the nouveau_drm_screen_create function.) > There is no point for the ddx. > > As for drm, I sure would use this feature as this would cut down compilation > time a lot when doing out of the tree builds. With the core arch, in theory, > it shouldn't be that hard if you want plan on using old cards only. Howev...

.../../libdrm-2.4.100/nouveau/nouveau.c:88) ==3018== by 0xC068286: nouveau_object_init (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:262) ==3018== by 0xC06A55C: nouveau_device_new (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:389) ==3018== by 0x5D5D0AD: nouveau_drm_screen_create (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:101) ==3018== by 0x5AD319A: pipe_nouveau_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/target-helpers/drm_helper.h:76) ==3018== by 0x5B7186C: pipe_loader_drm_create_...

...au_vieux, >>> nv30, >>> nv50 or nvc0) so the feature is already there. >>> >> Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 >> are all linked together in the nouveau driver, no way to split them >> out, largely because of the nouveau_drm_screen_create function.) >> > Hmm, as I need to specify which driver I want in configure, I thought > they were separated. My bad > > >> There is no point for the ddx. >>> >>> As for drm, I sure would use this feature as this would cut down >>> compilation >...

...4 deletions(-) diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c index ff017e4..c44424f 100644 --- a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c +++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c @@ -97,8 +97,6 @@ nouveau_drm_screen_create(int fd) if (ret) goto err; - drm->nvif = false; - ret = nouveau_device_new(&drm->client, NV_DEVICE, &(struct nv_device_v0) { .device = ~0ULL, diff --git a/src/mesa/drivers/dri/nouveau/nouveau_screen.c b/src/mesa/drivers/dri/nouveau/nouveau_screen.c index 1a74ae2.....

...4 insertions(+) diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c index c44424f..fa04c25 100644 --- a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c +++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c @@ -97,6 +97,8 @@ nouveau_drm_screen_create(int fd) if (ret) goto err; + drm->nvif = debug_get_bool_option("NOUVEAU_NVIF", false); + ret = nouveau_device_new(&drm->client, NV_DEVICE, &(struct nv_device_v0) { .device = ~0ULL, diff --git a/src/mesa/drivers/dri/nouveau/nouveau_screen.c b/src/mesa/dri...

...sh=0x13c0410, data=536952832) at ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:35 #1 0x00007fffee18b0b2 in BEGIN_NVC0 (push=0x13c0410, subc=2, mthd=0, size=1) at nvc0_winsys.h:112 #2 0x00007fffee18c0c1 in nvc0_screen_create (dev=0x15f8690) at nvc0_screen.c:496 #3 0x00007fffee0c4c3b in nouveau_drm_screen_create (fd=7) at nouveau_drm_winsys.c:46 #4 0x00007fffeb0a6943 in create_screen (fd=7) at pipe_nouveau.c:11 #5 0x00007fffec4e5fdb in pipe_loader_drm_create_screen (dev=0x1750130, library_paths=0x7fffecec0cf2 "/usr/lib64/gallium-pipe") at pipe_loader_drm.c:270 #6 0x00007fffec4e570e in pipe_loa...

...ssible to build the driver you want (nouveau_vieux, nv30, >> nv50 or nvc0) so the feature is already there. > Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 > are all linked together in the nouveau driver, no way to split them > out, largely because of the nouveau_drm_screen_create function.) Hmm, as I need to specify which driver I want in configure, I thought they were separated. My bad > >> There is no point for the ddx. >> >> As for drm, I sure would use this feature as this would cut down compilation >> time a lot when doing out of the tree bui...

...t; nv30, >>>> nv50 or nvc0) so the feature is already there. >>>> >>> Really? How do you compile only nv50? (Hint: you can't. nv30/nv50/nvc0 >>> are all linked together in the nouveau driver, no way to split them >>> out, largely because of the nouveau_drm_screen_create function.) >>> >> Hmm, as I need to specify which driver I want in configure, I thought >> they were separated. My bad >> >> >>> There is no point for the ddx. >>>> >>>> As for drm, I sure would use this feature as this would cut do...

https://bugs.freedesktop.org/show_bug.cgi?id=106410 Bug ID: 106410 Summary: Xorg server 1.19.6 crashes with nouveau or modsetting driver with Mesa 18.0.x while works fine with proprietary nvidia driver 390.42 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: other

On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >> Hi, my apologies if this is the wrong place to post this. >> I had the desire to turn on or off support for certain chipsets. >> Because i felt like the nouveau drivers are (relatively) quite large and >> depends on some kernel code