search for: pushbuffers

Fixes GART leak (as accounted by nouveau_drm.gem.gart_available). Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Running glxinfo in a loop is enough to trigger it - after several thousand runs (depending on GART size), X server crashes and does not come back in a correct state (corruptions and crashes). With this patch applied, it's possible again to do full piglit

Hi all, I am a Nouveau user on FC12 with GeForce 9500GT. I have read the Nouveau wiki documents, and they imply that there are ways to set GPU to send interrupts to CPU, when we want to be notified for something, e.g., when DMA transfer or GPU operation is completed. By default, when I run an OpenGL demo application from Gallium3D, the driver gets no interrupts from GPU in nouveau_irq_handler(),

...f() still implicitly treats bit 23 of the pushbuffer buffer[].length field as NOUVEAU_GEM_PUSHBUF_NO_PREFETCH, despite previous commits moving the flag out of the length field for lower levels as this is an nv50-hardware-specific arrangement. It also conflicts with point 1 above as pushbuffers can be equal to or greater than 1<<23 in practice. (Does the ioctl code in question have reason to set or expose no_prefetch?) 3) Bits 0 and 1 of the length field are passed through and placed into the IB entry, but they don't signify length in the DMA request. Bit 0...

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not both cur and remaining. The goal is to make the *_RING macros faster and make the

On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote: > > There's some minimal state that needs to be mapped into GPU address space. > > One thing that comes to mind are pushbuffers, which are needed to submit > > stuff to any engine. > I guess you can probably use the start of the kernel's address space > carveout for these kind of mappings actually? It's not like userspace > can ever have virtual addresses there? Yeah. I'm looking into it furthe...

It seems that Noveau is assuming that once the FIFO pointer is past a command, that command has finished executing, and all the buffers it used are no longer needed. However, this seems to be false at least on G71. In particular, the card may not have even finished reading the input vertex buffers when the pushbuffer "fence" triggers. While Mesa does not reuse the buffer object itself,

Hello everyone, it seems that GP10B support has regressed recently. With linux-next, I need to modify device/base.c to set .mmu = gp10b_mmu_new for GP10B (makes sense - I guess this was left as gf100_mmu_new as a typo) to probe. After that, running a trivial testcase (running a NOP method in 3D class) fails with [ 110.084649] nouveau 17000000.gpu: fifo: read fault at 0000011000 engine 06

...for graphics. You > > just init the engine and get out of the way. > > But... you need to map memory to set up the engine. Not a lot, but > it's gotta go *somewhere*. There's some minimal state that needs to be mapped into GPU address space. One thing that comes to mind are pushbuffers, which are needed to submit stuff to any engine.

Hi. There's not much to say here, just replacing the screen_init stateobj with direct pushbuffer emission. We don't need to store all the usless state from init, and the constant buffer relocations which currently don't work if the addresses change (because the method CB_DEF_SET isn't among them (not an address)) become effective. Thoughts, ack / nack ? Thanks, Christoph

...e: > On 8 July 2015 at 10:31, Andrew Chew <achew at nvidia.com> wrote: > > On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote: > >> > There's some minimal state that needs to be mapped into GPU address space. > >> > One thing that comes to mind are pushbuffers, which are needed to submit > >> > stuff to any engine. > >> I guess you can probably use the start of the kernel's address space > >> carveout for these kind of mappings actually? It's not like userspace > >> can ever have virtual addresses there? &g...

http://bugs.freedesktop.org/show_bug.cgi?id=25806 Summary: NV40 vertex corruption (kernel BO deletion too early?) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org

- NV30 and NV40 need testing. - I'll take better naming suggestions for so_get_push_reloc(). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 49 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++- src/gallium/drivers/nv30/nv30_state_emit.c | 26 ++++++++++++ src/gallium/drivers/nv40/nv40_state_emit.c | 30 ++++++++++++++

...0:31, Andrew Chew <achew at nvidia.com> wrote: > >> > On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote: > >> >> > There's some minimal state that needs to be mapped into GPU address space. > >> >> > One thing that comes to mind are pushbuffers, which are needed to submit > >> >> > stuff to any engine. > >> >> I guess you can probably use the start of the kernel's address space > >> >> carveout for these kind of mappings actually? It's not like userspace > >> >> can e...

...t all the scenes ended up being corrupted - in particular, when two consecutive scenes used the same model, the second instance would be uncorrupted. Forcing the caching to TTM_PL_FLAG_UNCACHED led to the same result. What is interesting is that while data like vertices and textures got corrupted, pushbuffers and shader programs seem to be just fine, as I could not see any runtime error. I don't really understand what kind of caching behavior could lead to that. If anyone has any idea, I'd love to hear. Thanks, Alex.

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

Bisection status report: The latest commit I have gotten to work is 10842ba074e9 drm/nouveau: remove unused nouveau_fence_work() i.e. the first bad commit is d7722134b825 drm/nouveau: switch over to new memory and vmm interfaces Even with the first one some patches/hacks are needed: - in mmu/gp10b.c, in the constructor we need to select the GM200 path - the GP100 path seems to not to work

created, written, drawn and then recreated upon reuse (which seems correct behavior). It seems, in other words, that the kernel is not keeping an extra reference to buffers which are currently referenced by an in-flight pushbuffer, and unreferencing them only once the GPU finished drawing. Is the kernel already supposed to do so? If yes, something is broken. If things work for others, maybe my

Hi all, Has anything changed since this email that will make OpenCL support in nouveau easier? I would like to compile some information about the different steps needed to have OpenCL support for Nouveau (and the ATI open-source drivers for that matters) so that people interested in this issue can have a starting document to read. Cheers, Albert. > Kernel allows you to create the relevant

https://bugs.freedesktop.org/show_bug.cgi?id=66809 --- Comment #6 from Roy <r.spliet at student.tudelft.nl> --- Eric: Could you install the debugging symbols (or, if you compiled it yourself, recompile with "-g" in your CFLAGS) for nouveau_dri and libdrm_nouveau please and reproduce your crash, regenerating this backtrace? I think it would be useful to see which function is trying

Hello Christoph, I was looking at bug 64323[1] over the weekend as to why this case works under nvc0+ hardware and does not under nv50. Here are some of the things I've noticed: * nvc0 uses immediate(s) for VERTEX_BEGIN_GL/VERTEX_END_GL * nvc0 is more consistent for doing pushbuffer space checks * nvc0 uses dirty tracking in set_index_buffer() * nvc0 uses "VERTEX_DATA push mode"