[Mesa-dev] RFC: Fixing nv30 fbo attachments

[Marek Olšák]

Not in OpenGL.

Marek

On Wed, May 21, 2014 at 3:05 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> Can you not render to a texture buffer? That might not be supported by
> nv30 actually.
>
> On Tue, May 20, 2014 at 8:49 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> ARB_buffer_storage doesn't have anything to do with framebuffers.
>>
>> Marek
>>
>> On Wed, May 21, 2014 at 2:27 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Tue, May 20, 2014 at 6:20 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>> On Tue, May 20, 2014 at 4:51 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>> On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>>>> 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 format, and a 32-bit color format must be paired with a
>>>>>>> 32-bit depth format (well, Z24S8). This HW also can't handle different
>>>>>>> per-attachment sizes, and also the "linearity" of all the attachments
>>>>>>> must be the same. (Whether a surface is linear or not is _generally_
>>>>>>> dictated by its w/h, but not always -- POT 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 back into the
>>>>>>> target. This deals with the target texture getting modified between
>>>>>>> draws with various blits/mapping/whatever.
>>>>>>>
>>>>>>> This means that you'll only get 16 bits of depth even if you ask for
>>>>>>> 24 with a 16-bit color format, but the alternative seems too
>>>>>>> complex/costly.
>>>>>>>
>>>>>>> So there are a few questions from this 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.
>>>>>
>>>>> 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 guess I'm still not 100% on all the terminology -- what do you mean
>>>>> exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So
>>>>> basically I would blit once on set_framebuffer_state, and then blit
>>>>> back and forth on resource map/unmap, and only ever render to the
>>>>> "temporary" buffer without worrying about blitting wihle rendering?
>>>>
>>>> "bind" is when a buffer is set, "unbind" is when the buffer is unset.
>>>> set_framebuffer_state unbinds the current framebuffer and binds a new
>>>> one.
>>>>
>>>> transfer_map/unmap must use the resource which contains the latest
>>>> data, there is no doubt about that.
>>>>
>>>> If there are no transfers, you only have to do the blits between
>>>> 32-bit and 16-bit in set_framebuffer_state, because that's the only
>>>> place where the framebuffer is changed.
>>>
>>> OK, I see. That makes sense, I think. So I just have to be careful
>>> with the transfers to make sure to blit things back first (or maybe I
>>> don't even have to do that, haven't checked the transfer api), similar
>>> for blit. And I'll need to turn off ARB_buffer_storage.
>>>
>>>   -ilia