Changeset View
Changeset View
Standalone View
Standalone View
source/blender/gpu/metal/kernels/compute_texture_read.msl
| Show First 20 Lines • Show All 68 Lines • ▼ Show 20 Lines | |||||
| template<> uchar convert_type<uchar>(float val) | template<> uchar convert_type<uchar>(float val) | ||||
| { | { | ||||
| return uchar(val * float(0xFF)); | return uchar(val * float(0xFF)); | ||||
| } | } | ||||
| template<> uint convert_type<uint>(float val) | template<> uint convert_type<uint>(float val) | ||||
| { | { | ||||
| return uint(val * double(0xFFFFFFFFu)); | return uint(val * float(0xFFFFFFFFu)); | ||||
fclem: Is this change for performance ? or is it for accuracy / consistency?
By the way, how does… | |||||
Not Done Inline ActionsThis was a previous oversight from the other review. Double is not supported as a type in Metal, so the type must be kept as float. In the case of val being > 1.0, this is a good point, as in these cases, this value would overflow. Perhaps need to understand the exact use-cases of this, and whether values are stored in the zero-one range. Should val likely be clamped? Is there an actual use case which may hit this, with a higher-precision colour target being read as UINT? MichaelPW: This was a previous oversight from the other review. Double is not supported as a type in Metal… | |||||
Not Done Inline ActionsYou are right, it is unlikely to be the case if we make sure to enforce correct API usage in the backend. fclem: You are right, it is unlikely to be the case if we make sure to enforce correct API usage in… | |||||
| } | } | ||||
| struct TextureReadParams { | struct TextureReadParams { | ||||
| int mip_index; | int mip_index; | ||||
| int extent[3]; | int extent[3]; | ||||
| int offset[3]; | int offset[3]; | ||||
| }; | }; | ||||
| ▲ Show 20 Lines • Show All 89 Lines • ▼ Show 20 Lines | #if IS_DEPTH_FORMAT != 1 | ||||
| } | } | ||||
| /* Fill in empty cells if more components are being read than exist */ | /* Fill in empty cells if more components are being read than exist */ | ||||
| for (int i = COMPONENT_COUNT_INPUT; i < COMPONENT_COUNT_OUTPUT; i++) { | for (int i = COMPONENT_COUNT_INPUT; i < COMPONENT_COUNT_OUTPUT; i++) { | ||||
| output_data[index + i] = convert_type<OUTPUT_DATA_TYPE>(0); | output_data[index + i] = convert_type<OUTPUT_DATA_TYPE>(0); | ||||
| } | } | ||||
| #endif | #endif | ||||
| } | } | ||||
| No newline at end of file | No newline at end of file | ||||
Is this change for performance ? or is it for accuracy / consistency?
By the way, how does those behave if val > 1.0f? Is that a case that can happen here in texture read?