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