search for: vbo

Hi Ilia, you were straight to the point for me in: "src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there." But where is it the function that implements this? Is it in nv30_draw_vbo(...)? Please, give me a function name or at least a file name? 2016-04-19 10:04 GMT-04:00 Ilia Mirkin <imirki...

...rocess these three input floats before it is sent to the card? Where is the code for it? If you say the floats are memory mapped as in exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would say from what I learned that it has to pass through gallium and that means: st_draw_vbo(...) ending up in nv30_draw_vbo(..) but these functions don't make any reference to those (memory mapped) input floats. So where is the piece of code that instructs the card to fetch those three (possibly processed) input floats and send them to the card? Thanks in advance. -------------- next...

Hello, The method we previously used on Fermi and Kepler (0x142c) to flush the VBO cache before draw appears to be gone on Maxwell. Is there a replacement method we should use? (Or perhaps that method was never meant for VBO cache flush and instead flushed something related to the vertex quarantine area defined by 0x17bc/0x17c0/0x17c4, which in turn is gone on Maxwell?) Thanks...

...gt; Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card > processes > these three floats? Does the card work with floats? Does (mesa? gallium? > driver?) > process these three input floats before it is sent to the card? Where is the > code > for it? src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there. (Under some circumstances, the vbo data might have to be transformed on the cpu as well if the driver can't handle the format.) > > If you say the floats are memory mapped as in >...

...f the card and draw the line, possibly when glXSwapBuffers is called? Is the glColor(...) (the three floats) stored in the mmapped twice, one for each vertex? HELP I'M LOST :( This mine consideration is wrong... I guess... st_draw.c coments that all "rendering" is done through st_draw_vbo() which would end up calling nv30_draw_vbo() which would send data to the card... but where is the missing link?? The floats (for the vertices and color) are already mapped by ctx->Driver.MapBufferRange...*/ glBegin(GL_LINES); glColor3f(1.0, 1.0, 1.0); glVertex3f(0.0f, 0.0f, 0.0f);...

The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "11.0" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_program....

On Tue, Apr 19, 2016 at 11:01 AM, Daniel Melo Jorge da Cunha <dmjcunha at gmail.com> wrote: > Hi Ilia, you were straight to the point for me in: > > "src/mesa/vbo will upload it to a vbo. The driver then points the > hardware at the vbo and tells it to read from there." > > But where is it the function that implements this? Is it in > nv30_draw_vbo(...)? Please, give me a function name or > at least a file name? Before draw_vbo is called...

NOTE: we must not try to emit buffer relocations when vtxbuf_nr is 0 but vtxelt_nr is not --- src/gallium/drivers/nv50/nv50_vbo.c | 80 ++++++++++++++++++++++++---------- 1 files changed, 56 insertions(+), 24 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_vbo.c b/src/gallium/drivers/nv50/nv50_vbo.c index cbd9d6a..422c8c6 100644 --- a/src/gallium/drivers/nv50/nv50_vbo.c +++ b/src/gallium/drivers/nv50/nv50_vbo.c @...

https://bugs.freedesktop.org/show_bug.cgi?id=53519 Bug #: 53519 Summary: Missing bits of geometry in Unigine tropics Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/DRI/nouveau

...floats > fetched > by the pusher of the card and draw the line, possibly when glXSwapBuffers is > called? > Is the glColor(...) (the three floats) stored in the mmapped twice, one for > each > vertex? I think, but am not sure, that it will come in as a constant attribute (i.e. a VBO attribute with stride 0). > HELP I'M LOST :( This mine consideration is wrong... I guess... > st_draw.c > coments that all "rendering" is done through st_draw_vbo() which would end > up > calling nv30_draw_vbo() which would send data to the card... but where is > th...

..._stateobj.h +++ b/src/gallium/drivers/nouveau/nouveau_stateobj.h @@ -163,6 +163,15 @@ so_emit_reloc_markers(struct nouveau_channel *chan, struct nouveau_stateobj *so) for (i = 0; i < so->cur_reloc; i++) { struct nouveau_stateobj_reloc *r = &so->reloc[i]; + /* This is probably a vbo which has caused a pushbuf flush + * before mapping. Don't try to reloc it again, it will cause + * problems, because important stuff is skipped. + */ + if (r->bo->map) { + pb->remaining += 2; + continue; + } + if ((ret = nouveau_pushbuf_emit_reloc(chan, pb->cur++, r-...

...p_debug.c:335 #1 0xf76fe723 in nv20_state_emit_framebuffer (nv20=0x805ef68) at nv20_state_emit.c:139 #2 0xf76fef2e in nv20_emit_hw_state (nv20=0x805ef68) at nv20_state_emit.c:255 #3 0xf76ff70b in nv20_draw_elements (pipe=0x805ef68, indexBuffer=0x0, indexSize=0, prim=4, start=0, count=3) at nv20_vbo.c:20 #4 0xf76ff922 in nv20_draw_arrays (pipe=0x805ef68, prim=4, start=0, count=3) at nv20_vbo.c:73 #5 0xf7743ac8 in st_draw_vbo (ctx=0x8074d18, arrays=0x80ade38, prims=0x80ac994, nr_prims=1, ib=0x0, min_index=0, max_index=2) at state_tracker/st_draw.c:634 #6 0xf782c140 in vbo_exec_vtx_flush...

..., nouveau_transfer_write(nouveau_context(pipe), tx, box->x, box->width); } +/* Unmap stage of the transfer. If it was a WRITE transfer and the map that + * was returned was not the real resource's data, this needs to transfer the + * data back to the resource. + * + * Also marks vbo/cb dirty if the buffer's binding + */ static void nouveau_buffer_transfer_unmap(struct pipe_context *pipe, struct pipe_transfer *transfer) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.h b/src/gallium/drivers/nouveau/nouveau_buffer.h index fd7a3f1..aeb...

Requesting a new real buffer from the kernel and copying all the data is wasteful e.g. if only a few (but widely spread) vertices are accessed. --- src/gallium/drivers/nv50/nv50_context.h | 3 + src/gallium/drivers/nv50/nv50_vbo.c | 409 +++++++++++++++++++++++++++++-- 2 files changed, 394 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_context.h b/src/gallium/drivers/nv50/nv50_context.h index be53990..8e2d695 100644 --- a/src/gallium/drivers/nv50/nv50_context.h +++ b/src/gallium/drivers/nv5...

.../vmwgfx/vmwgfx_page_dirty.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c > @@ -452,12 +452,14 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf) > * sure the page protection is write-enabled so we don't get > * a lot of unnecessary write faults. > */ > - if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) > + if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) { > prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED); > - else > + ret = ttm_bo_vm_fault_reserved(vmf, prot, num_prefa...

...;> vm_fault >> >>>> *vmf) >> >>>>> * sure the page protection is write-enabled so we don't get >> >>>>> * a lot of unnecessary write faults. >> >>>>> */ >> >>>>> - if (vbo->dirty && vbo->dirty->method == >> VMW_BO_DIRTY_MKWRITE) >> >>>>> + if (vbo->dirty && vbo->dirty->method == >> VMW_BO_DIRTY_MKWRITE) >> >>>> { >> >>>>> prot = vm_get_page_prot(v...

...wgfx/vmwgfx_page_dirty.c >>> @@ -452,12 +452,14 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault >> *vmf) >>> * sure the page protection is write-enabled so we don't get >>> * a lot of unnecessary write faults. >>> */ >>> - if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) >>> + if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) >> { >>> prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED); >>> - else >>>...

Hello, I'm trying to debug why fbo-copyteximage-simple is failing, and I'm... failing. It's an extremely simple test. I'm pretty sure that the copyteximage part of it has nothing to do with the failure, at least it behaves identically when I just return tex instead of copiex_tex. Without any modifications, the test just renders one big red square. I think there's something

...v30=nv30 at entry=0x805cc70, hwtnl=hwtnl at entry=1 '\001') at nv30_state_validate.c:487 screen = 0x8078800 push = 0x8078938 bctx = 0x805d340 bref = <optimized out> validate = 0xb76a9d78 <hwtnl_validate_list+88> #8 0xb66c629e in nv30_draw_vbo (pipe=0x805cc70, info=0xbfffef10) at nv30_vbo.c:563 push = 0x8078938 #9 0xb69a4fb3 in u_vbuf_draw_vbo (mgr=0x81144e8, info=info at entry=0xbfffef10) at util/u_vbuf.c:1128 pipe = 0x805cc70 start_vertex = <optimized out> min_index = <optimized out>...

...52,12 +452,14 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault >>>> *vmf) >>>>> * sure the page protection is write-enabled so we don't get >>>>> * a lot of unnecessary write faults. >>>>> */ >>>>> - if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) >>>>> + if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE) >>>> { >>>>> prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED); >>&g...