search for: set_framebuffer_state

Displaying 11 results from an estimated 11 matches for "set_framebuffer_state".

2014 May 21
2
[Mesa-dev] RFC: Fixing nv30 fbo attachments
...d more importantly -- >>>> when... what happens if allocation fails?) >>>> >>>> 2. Having to blit the depth texture back and forth on every draw seems >>>> _really_ wasteful... anything I can do about that? >>> >>> You can do that in set_framebuffer_state. When binding, blit to a >>> depth buffer which matches the colorbuffer format. When unbinding, >>> blit back. >> >> set_framebuffer_state doesn't allow an error to be returned. Should I >> just print a warning and move on? > > Yes, because you have no...
2014 May 20
2
[Mesa-dev] RFC: Fixing nv30 fbo attachments
.... Where do I get the temporary texture from? (And more importantly -- >> when... what happens if allocation fails?) >> >> 2. Having to blit the depth texture back and forth on every draw seems >> _really_ wasteful... anything I can do about that? > > You can do that in set_framebuffer_state. When binding, blit to a > depth buffer which matches the colorbuffer format. When unbinding, > blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? I guess I'm still not 100% on all the terminology -- what do you mean ex...
2014 May 21
1
[Mesa-dev] RFC: Fixing nv30 fbo attachments
...hen... what happens if allocation fails?) >>>>>> >>>>>> 2. Having to blit the depth texture back and forth on every draw seems >>>>>> _really_ wasteful... anything I can do about that? >>>>> >>>>> You can do that in set_framebuffer_state. When binding, blit to a >>>>> depth buffer which matches the colorbuffer format. When unbinding, >>>>> blit back. >>>> >>>> set_framebuffer_state doesn't allow an error to be returned. Should I >>>> just print a warning and move...
2014 May 20
0
[Mesa-dev] RFC: Fixing nv30 fbo attachments
...porary texture from? (And more importantly -- >>> when... what happens if allocation fails?) >>> >>> 2. Having to blit the depth texture back and forth on every draw seems >>> _really_ wasteful... anything I can do about that? >> >> You can do that in set_framebuffer_state. When binding, blit to a >> depth buffer which matches the colorbuffer format. When unbinding, >> blit back. > > set_framebuffer_state doesn't allow an error to be returned. Should I > just print a warning and move on? Yes, because you have no other choice. > > I gu...
2014 May 21
0
[Mesa-dev] RFC: Fixing nv30 fbo attachments
...t;>>>> when... what happens if allocation fails?) >>>>> >>>>> 2. Having to blit the depth texture back and forth on every draw seems >>>>> _really_ wasteful... anything I can do about that? >>>> >>>> You can do that in set_framebuffer_state. When binding, blit to a >>>> depth buffer which matches the colorbuffer format. When unbinding, >>>> blit back. >>> >>> set_framebuffer_state doesn't allow an error to be returned. Should I >>> just print a warning and move on? >> >&g...
2014 May 20
2
RFC: Fixing nv30 fbo attachments
Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth
2009 Apr 08
0
[PATCH/Gallium] nv50: update nv50_clear to new interface
...+ ps = fb.zsbuf = s_fb.zsbuf; } else { - fb.nr_cbufs = 1; - fb.cbufs[0] = ps; fb.zsbuf = NULL; } + + /* actually this can't happen, so initializing ps to NULL isn't + * really necessary as well */ + assert(ps); + fb.width = ps->width; fb.height = ps->height; pipe->set_framebuffer_state(pipe, &fb); + /* XXX: mesa state tracker does clear_with_quad if scissor is enabled, + * so this is probably unnecessary (?) */ sc.minx = sc.miny = 0; sc.maxx = fb.width; sc.maxy = fb.height; @@ -59,28 +88,30 @@ nv50_clear(struct pipe_context *pipe, struct pipe_surface *ps, nv50_stat...
2014 May 20
0
[Mesa-dev] RFC: Fixing nv30 fbo attachments
...his approach: > > 1. Where do I get the temporary texture from? (And more importantly -- > when... what happens if allocation fails?) > > 2. Having to blit the depth texture back and forth on every draw seems > _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. You can also drop support for 16-bit formats. What about rendering to R16F, RG16F, and RGBA16F? Does R16F have to be coupled with a 16-bit depth buffer too? Marek
2014 Nov 27
0
[Mesa-dev] [RFC] tegra: Initial support
...fer, buf, sizeof(buffer)); > + buffer.buffer = tegra_resource_unwrap(buffer.buffer); > + buf = &buffer; > + } > + > + context->gpu->set_constant_buffer(context->gpu, shader, index, buf); > +} > + > +static void > +tegra_set_framebuffer_state(struct pipe_context *pcontext, > + const struct pipe_framebuffer_state *fb) > +{ > + struct tegra_context *context = to_tegra_context(pcontext); > + struct pipe_framebuffer_state state; > + unsigned i; > + > + if (fb) { > +...
2014 Nov 27
7
[RFC] tegra: Initial support
...constant_buffer buffer; + + if (buf && buf->buffer) { + memcpy(&buffer, buf, sizeof(buffer)); + buffer.buffer = tegra_resource_unwrap(buffer.buffer); + buf = &buffer; + } + + context->gpu->set_constant_buffer(context->gpu, shader, index, buf); +} + +static void +tegra_set_framebuffer_state(struct pipe_context *pcontext, + const struct pipe_framebuffer_state *fb) +{ + struct tegra_context *context = to_tegra_context(pcontext); + struct pipe_framebuffer_state state; + unsigned i; + + if (fb) { + memcpy(&state, fb, sizeof(state)); + + for (i = 0; i < fb->nr_cbufs; i++)...
2010 Aug 06
4
nv vpe video decoder
Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for