[Nouveau] [Bug 49142] [NV4A] OpengGL content corruption when width >= 2048
https://bugs.freedesktop.org/show_bug.cgi?id=49142 Ben Skeggs changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 49142] [NV4A] OpengGL content corruption when width >= 2048
https://bugs.freedesktop.org/show_bug.cgi?id=49142 --- Comment #1 from Ben Skeggs 2012-04-26 16:28:42 PDT --- Thanks for the report, the issue should be fixed in mesa git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 49088] MapsGL labels doen't render properly on nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=49088 Karl Tomlinson changed: What|Removed |Added AssignedTo|nouveau@lists.freedesktop.o |mesa-dev@lists.freedesktop. |rg |org Component|Drivers/DRI/nouveau |Mesa core --- Comment #1 from Karl Tomlinson 2012-04-26 14:41:12 PDT --- I see the same issue with r600 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD JUNIPER OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions: but sw works as expected. OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x209) OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 suggesting the problem is in a more core component, possibly dri2-specific. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] [PATCH 2/2] drm/nouveau: implement precise vblank timestamping
Hi Maarten, Am Donnerstag, den 26.04.2012, 23:25 +0200 schrieb Maarten Maathuis: > It seems a bit strange to go in between a register and defines that > probably belong to that register. > Yes, you are right. Thanks for catching this. I will fix this up, but will wait for Ben's comments and/or other review feedback before spamming the list with just another version of this patch. -- Lucas > On Thu, Apr 26, 2012 at 12:26 AM, Lucas Stach wrote: > > #define NV_PCRTC_ENGINE_CTRL 0x00600860 > > +#define NV_PCRTC_STAT(i0) (0x00600868 + 0x2000*(i0)) > > # define NV_CRTC_FSEL_I2C (1 << 4) > > # define NV_CRTC_FSEL_OVERLAY (1 << 12) > > > ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] drm/nouveau: implement precise vblank timestamping
It seems a bit strange to go in between a register and defines that probably belong to that register. On Thu, Apr 26, 2012 at 12:26 AM, Lucas Stach wrote: > #define NV_PCRTC_ENGINE_CTRL 0x00600860 > +#define NV_PCRTC_STAT(i0) (0x00600868 + 0x2000*(i0)) > # define NV_CRTC_FSEL_I2C (1 << 4) > # define NV_CRTC_FSEL_OVERLAY (1 << 12) -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Question about NV18 and GBM library.
Am Mittwoch, den 25.04.2012, 12:34 -0300 schrieb gabriel muguerza: > 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? > Yep, you are right, your GPU is simply too old. GBM is only supported with the nouveau gallium drivers, which start with the nv30 generation. The nouveau_vieux driver for your card does not support GBM. -- Lucas ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Question about NV18 and GBM library.
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?
when I run the following code:
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
int fd;
struct gbm_device *gbm = NULL;
fd = open("/dev/dri/card0", O_RDWR | O_CLOEXEC);
if (fd < 0) {
perror("> open error /dev/dri/card0...");
exit(-1);
}
printf(". open /dev/dri/card0, fd = %d\n\n", fd);
gbm = gbm_create_device(fd);
if (!gbm) {
perror("\n> cannot create gbm device...");
fprintf(stderr, "> errno = %d\n", errno);
exit(-1);
}
exit(0);
}
I get:
. open /dev/dri/card0, fd = 3
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
> cannot create gbm device...: No such file or directory
> errno = 2
some details:
distro: Archlinux
kernel: 3.3.3
Mesa 8.0 from git: ./autogen.sh --prefix=/usr
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-dri-drivers=i915,i965,nouveau,radeon,r200 \
--with-gallium-drivers=r300,r600,nouveau,svga,swrast \
--with-egl-platforms=drm,x11 \
--enable-gallium-llvm \
--enable-gallium-egl \
--enable-shared-dricore \
--enable-shared-glapi \
--enable-egl \
--enable-gles1 \
--enable-gles2 \
--enable-openvg \
--enable-glx-tls \
--enable-xcb \
--enable-gbm \
--enable-dri \
--enable-xa \
--enable-gallium-gbm \
--enable-osmesa \
--enable-texture-float \
--enable-debug
libdrm 2.4.33 from git.
xf86-video-nouveau from git.
If necessary I will provide any other relevant information.
Thanks,
Gabriel Muguerza.
(English is not my native language, please excuse the typos.)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 4/4] drm/nouveau: gpu lockup recovery
On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> - CPU-only bo eviction
> - ignoring vm flush / fence timeouts
> - shortening waits
Okay. I've thought about this a bit for a couple of days and think I'll
be able to coherently share my thoughts on this issue now :)
Firstly, while I agree that we need to become more resilient to errors,
I don't think that following in the radeon/intel footsteps with
something (imo, hackish) like this is the right choice for us
necessarily.
The *vast* majority of "lockups" we have are as a result of us badly
mishandling exceptions reported to us by the GPU. There are a couple of
exceptions, however, they're very rare..
A very common example is where people gain DMA_PUSHERs for whatever
reason, and things go haywire eventually. To handle a DMA_PUSHER
sanely, generally you have to drop all pending commands for the channel
(set GET=PUT, etc) and continue on. However, this leaves us with fences
and semaphores unsignalled etc, causing issues further up the stack with
perfectly good channels hanging on attempting to sync with the crashed
channel etc.
The next most common example I can think of is nv4x hardware, getting a
LIMIT_COLOR/ZETA exception from PGRAPH, and then a hang. The solution
is simple, learn how to handle the exception, log it, and PGRAPH
survives.
I strongly believe that if we focused our efforts on dealing with what
the GPU reports to us a lot better, we'll find we really don't need such
"lockup recovery".
I am, however, considering pulling the vm flush timeout error
propagation and break-out-of-waits-on-signals that builds on it. As we
really do need to become better at having killable processes if things
go wrong :)
Ben.
>
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/Makefile |2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
> drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
> drivers/gpu/drm/nouveau/nouveau_drv.c | 56 ++-
> drivers/gpu/drm/nouveau/nouveau_drv.h | 45 -
> drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++-
> drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
> drivers/gpu/drm/nouveau/nouveau_object.c |6 +
> drivers/gpu/drm/nouveau/nouveau_reset.c| 148
>
> drivers/gpu/drm/nouveau/nouveau_state.c|6 +
> drivers/gpu/drm/nouveau/nv50_graph.c | 11 +-
> 12 files changed, 290 insertions(+), 15 deletions(-)
> create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c
>
> diff --git a/drivers/gpu/drm/nouveau/Makefile
> b/drivers/gpu/drm/nouveau/Makefile
> index 03860f5..77d0c33 100644
> --- a/drivers/gpu/drm/nouveau/Makefile
> +++ b/drivers/gpu/drm/nouveau/Makefile
> @@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o
> nouveau_mem.o \
> nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
> nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
> nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
> - nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
> + nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
>nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
>nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
> nv04_timer.o \
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5b0dc50..7de6cad 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
> bool intr,
> }
>
> /* Software copy if the card isn't up and running yet. */
> - if (!dev_priv->channel) {
> + if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev))
> {
> ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve,
> no_wait_gpu, new_mem);
> goto out;
> }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c
> b/drivers/gpu/drm/nouveau/nouveau_channel.c
> index 846afb0..c0fa5a7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_channel.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
> @@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void
> *data,
> init->fb_ctxdma_handle,
> init->tt_ctxdma_handle);
> if (ret)
> - return ret;
> + goto out;
> init->channel = chan->id;
>
> if (nouveau_vram_pushbuf == 0) {
> @@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void
> *data,
> if (ret ==
