Gfx: Fortify the clear color iterator

Created on 18 Jul 2018  路  2Comments  路  Source: gfx-rs/gfx

This is another unsound aspect of today's HAL that would be great to fix.

In begin_render_pass we receive an iterator over clear values. It's semantics currently matches Vulkan - a value per attachment, but not necessarily enough for all attachment, and some values are ignored. This is rather sad from the API standpoint, and we should fix it.

Perhaps, we could say that the iterator has to only contain the values for cleared attachments? Given that framebuffer/renderpass creation is rare, we could have the portability layer building a mask of cleared attachments, and then filter the given clear value slice based on that. Shouldn't introduce any visible overhead.

average hal ready for work api high

Most helpful comment

My idea would be to have a key-value pair list, something like a Vec<(u32, ClearValueRaw)>, but it can be also a struct. The key would be the index of the attachment. This way you could build the VkRenderPassBeginInfo.pClearValues array without knowing the render pass. In my opinion it would be more explicit.

All 2 comments

My idea would be to have a key-value pair list, something like a Vec<(u32, ClearValueRaw)>, but it can be also a struct. The key would be the index of the attachment. This way you could build the VkRenderPassBeginInfo.pClearValues array without knowing the render pass. In my opinion it would be more explicit.

@kocsis1david that would certainly ease the life of gfx-portability a bit, at the cost of making the API a bit more verbose, but the user should already know these attachment indices, so it sounds like a good compromise.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

InMath picture InMath  路  5Comments

norru picture norru  路  4Comments

Fluci picture Fluci  路  5Comments

djcsdy picture djcsdy  路  4Comments

msiglreith picture msiglreith  路  3Comments