On 16 October 2016 at 21:46, Józef Kucia jkucia@codeweavers.com wrote:
-static void buffer_invalidate_bo_range(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size) +static void buffer_mark_dirty_area(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size)
I assume this is for consistency with buffer_clear_dirty_areas() and the like, but in the larger context we're using validate/invalidate for terminology.
On Wed, Oct 19, 2016 at 1:32 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 16 October 2016 at 21:46, Józef Kucia jkucia@codeweavers.com wrote:
-static void buffer_invalidate_bo_range(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size) +static void buffer_mark_dirty_area(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size)
I assume this is for consistency with buffer_clear_dirty_areas() and the like, but in the larger context we're using validate/invalidate for terminology.
Yes, it's mainly for consistency with buffer_clear_dirty_areas(), but additionally: * having two functions with very similar names is confusing (wined3d_buffer_invalidate_range() and buffer_invalidate_bo_range()), * dirty areas are also used for flushing modified areas when BO is being unmapped (see wined3d_buffer_unmap()).
On 19 October 2016 at 13:52, Józef Kucia joseph.kucia@gmail.com wrote:
Yes, it's mainly for consistency with buffer_clear_dirty_areas(), but additionally:
- having two functions with very similar names is confusing
(wined3d_buffer_invalidate_range() and buffer_invalidate_bo_range()),
Somewhat. It would be good to make that less confusing somehow, but I don't think using different terminology makes it better. One is a more specific helper for the other, and I imagine ultimately wined3d_buffer_invalidate_range() would be the only caller of buffer_invalidate_bo_range(). I.e., similar to how e.g. surface_load_location() and surface_load_texture() are related.
- dirty areas are also used for flushing modified areas when BO is
being unmapped (see wined3d_buffer_unmap()).
Yes, but I don't think that conflicts with the current name?