search for: draw_vbo

...T textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo & co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture...

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 <imirkin at alum.mit.edu>: > On Tue, Apr 19, 2016 at 8:52 AM, Daniel Melo Jorge da Cunha > <dmjcunha at gmail.com> wrote: > > Hi, for example, if I have glVertex3f(0.75, 0...

...e ddx, or something else.) The >> different sizes are handled by not exposing ARB_fbo. However the rest >> of the cases remain. >> >> Now that I kinda understand how things are structured, I was thinking >> of doing the following: >> >> When rendering (i.e. draw_vbo & co) and the fbo has changed (and has >> one of the problems above), I would instead put in a temporary texture >> as the depth attachment. Before actually drawing, I would blit from >> the real target texture into the temporary texture, and then when >> rendering is do...

...t sizes are handled by not exposing ARB_fbo. However the rest >>>> of the cases remain. >>>> >>>> Now that I kinda understand how things are structured, I was thinking >>>> of doing the following: >>>> >>>> When rendering (i.e. draw_vbo & co) and the fbo has changed (and has >>>> one of the problems above), I would instead put in a temporary texture >>>> as the depth attachment. Before actually drawing, I would blit from >>>> the real target texture into the temporary texture, and then when...

...ever the rest >>>>>> of the cases remain. >>>>>> >>>>>> Now that I kinda understand how things are structured, I was thinking >>>>>> of doing the following: >>>>>> >>>>>> When rendering (i.e. draw_vbo & co) and the fbo has changed (and has >>>>>> one of the problems above), I would instead put in a temporary texture >>>>>> as the depth attachment. Before actually drawing, I would blit from >>>>>> the real target texture into the temporary...

...ail.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, the vbo will have been set up via pipe->bind_vertex_elements_state and pipe->set_vertex_buffers. The draw call will then validate those, by calling nv30_state_validate (or something along those lin...

...llocated linearly by e.g. the ddx, or something else.) The > different sizes are handled by not exposing ARB_fbo. However the rest > of the cases remain. > > Now that I kinda understand how things are structured, I was thinking > of doing the following: > > When rendering (i.e. draw_vbo & co) and the fbo has changed (and has > one of the problems above), I would instead put in a temporary texture > as the depth attachment. Before actually drawing, I would blit from > the real target texture into the temporary texture, and then when > rendering is done, blit back fr...

...he >>> different sizes are handled by not exposing ARB_fbo. However the rest >>> of the cases remain. >>> >>> Now that I kinda understand how things are structured, I was thinking >>> of doing the following: >>> >>> When rendering (i.e. draw_vbo & co) and the fbo has changed (and has >>> one of the problems above), I would instead put in a temporary texture >>> as the depth attachment. Before actually drawing, I would blit from >>> the real target texture into the temporary texture, and then when >>>...

...ot exposing ARB_fbo. However the rest >>>>> of the cases remain. >>>>> >>>>> Now that I kinda understand how things are structured, I was thinking >>>>> of doing the following: >>>>> >>>>> When rendering (i.e. draw_vbo & co) and the fbo has changed (and has >>>>> one of the problems above), I would instead put in a temporary texture >>>>> as the depth attachment. Before actually drawing, I would blit from >>>>> the real target texture into the temporary texture, an...

https://bugs.freedesktop.org/show_bug.cgi?id=93004 Bug ID: 93004 Summary: Guild Wars 2 crash on nouveau DX11 cards Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

...ot; > + > +static void > +tegra_destroy(struct pipe_context *pcontext) > +{ > + struct tegra_context *context = to_tegra_context(pcontext); > + > + context->gpu->destroy(context->gpu); > + free(context); > +} > + > +static void > +tegra_draw_vbo(struct pipe_context *pcontext, > + const struct pipe_draw_info *pinfo) > +{ > + struct tegra_context *context = to_tegra_context(pcontext); > + struct pipe_draw_info info; > + > + if (pinfo && pinfo->indirect) { > + memcpy...

...ude "tegra/tegra_resource.h" +#include "tegra/tegra_screen.h" + +static void +tegra_destroy(struct pipe_context *pcontext) +{ + struct tegra_context *context = to_tegra_context(pcontext); + + context->gpu->destroy(context->gpu); + free(context); +} + +static void +tegra_draw_vbo(struct pipe_context *pcontext, + const struct pipe_draw_info *pinfo) +{ + struct tegra_context *context = to_tegra_context(pcontext); + struct pipe_draw_info info; + + if (pinfo && pinfo->indirect) { + memcpy(&info, pinfo, sizeof(info)); + info.indirect = tegra_resource_unwr...