search for: pushbuff

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(),

...0x7fffff is not the maximum possible push buffer size submitted for IB-mode DMA transfers, nor is it the maximum legal DMA transfer size (it is three bytes too large according to our reverse-engineering docs). 2) nouveau_gem_ioctl_pushbuf() 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<&...

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 remain...

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 fur...

...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, the current allocator tends to return memory that has just been freed, resulting in the buffer actually been reused. Thus Mesa will overwrite the vertices before the GPU has used them. This results in all kinds of ar...

...a000 nouveau_noop_te[2413]] | [ 110.101423] nouveau 17000000.gpu: fifo: channel 1: killed | [ 110.106827] nouveau 17000000.gpu: fifo: runlist 0: scheduled for recovery | Submitted pushbuffer. | [ 110.113867] nouveau 17000000.gpu: nouveau_noop_te[2413]: channel 1 killed! | [ 125.084858] nouveau 17000000.gpu: nouveau_noop_te[2413]: failed to idle channel 1 [nouveau_noop_te[2413]] I haven't managed to tr...

...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?...

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

...lers; uint64_t states; + int push = 0, reloc = 0; if (nv30->pctx_id != screen->cur_pctx) { for (i = 0; i < NV30_STATE_MAX; i++) { @@ -53,6 +54,31 @@ nv30_state_emit(struct nv30_context *nv30) screen->cur_pctx = nv30->pctx_id; } + /* Find out if we have enough space in pushbuffer. */ + for (i = 0, states = state->dirty; states; i++) { + if (!(states & (1ULL << i))) + continue; + if (state->hw[i]) + so_get_push_reloc(nv30->screen->state[i], &push, &reloc); + } + + so_get_push_reloc_markers(state->hw[NV30_STATE_FB], &push, &rel...

...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 > >> >> ca...

...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

...gt;                                        | > [  110.101423] nouveau 17000000.gpu: fifo: channel 1: killed >                                        | > [  110.106827] nouveau 17000000.gpu: fifo: runlist 0: scheduled for > recovery                                    | > Submitted pushbuffer.                                        | > [  110.113867] nouveau 17000000.gpu: nouveau_noop_te[2413]: channel 1 > killed!                                   | > [  125.084858] nouveau 17000000.gpu: nouveau_noop_te[2413]: failed to > idle channel 1 [nouveau_noop_te[2413]] > >...

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 system is somehow more prone to reusing memory or GART mappings, so they don't see that? If no, then how are things supposed...

...s issue can have a starting document to read. Cheers, Albert. > Kernel allows you to create the relevant object, but other than that there's > no support. You can indeed run your gpu code under nouveau if you're happy > with writing it in nv50 machine code and submitting via the pushbuffer > interface. Also our current memory managment is totally unfit for GPGPU > applications and will need to be redone before there's any hope of seeing CUDA > or OpenCL support in nouveau. > > Also, if you have any more questions and don't hate IRC, you can come to > #nouv...

...; --- 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 to push the pushbuffer and what variable is causing the segfault. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130713/101c2659/attachment.html&gt...

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" over the FIFO for nv50 AFAICS the second and third one have no effect when ported to nv50. I'm highly suspecting that "push mode" or actually the type of buffers used will be...