aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/main/format_utils.h
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Fix some signed-unsigned comparison warningsJan Vesely2015-01-211-1/+1
| | | | | | | | v2: s/unsigned int/unsigned/ in prog_optimize.c Signed-off-by: Jan Vesely <[email protected]> Reviewed-by: David Heidelberg <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* format_utils: Use a more precise conversion when decreasing bitsNeil Roberts2015-01-161-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When converting to a format that has fewer bits the previous code was just shifting off the bits. This doesn't provide very accurate results. For example when converting from 8 bits to 5 bits it is equivalent to doing this: x * 32 / 256 This works as if it's taking a value from a range where 256 represents 1.0 and scaling it down to a range where 32 represents 1.0. However this is not correct because it is actually 255 and 31 that represent 1.0. We can do better with a formula like this: (x * 31 + 127) / 255 The +127 is to make it round correctly. The new code has a special case to use uint64_t when the result of the multiplication would overflow an unsigned int. This function is inline and only ever called with constant values so hopefully the if statements will be folded. The main incentive to do this is to make the CPU conversion path pick the same values as the hardware would if it did the conversion. This fixes failures with the ‘texsubimage pbo’ test when using the patches from here: http://lists.freedesktop.org/archives/mesa-dev/2015-January/074312.html v2: Use 64-bit arithmetic when src_bits+dst_bits > 32 Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: rename RGBA8888_* format constants to something appropriate.Iago Toral Quiroga2015-01-141-4/+4
| | | | | | | | The 8888 suggests 8-bit components which is not correct, so replace that with the actual size of the components in each format. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Let _mesa_swizzle_and_convert take array format types instead of GL typesIago Toral Quiroga2015-01-121-2/+6
| | | | | | | | In the future we would like to have a format conversion library that is independent of GL so we can share it with Gallium. This is a step in that direction. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Add a helper _mesa_compute_rgba2base2rgba_component_mappingIago Toral Quiroga2015-01-121-0/+3
| | | | | | | This will come in handy when callers of _mesa_format_convert need to compute the rebase swizzle parameter to use. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Add a rebase_swizzle parameter to _mesa_format_convertIago Toral Quiroga2015-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | The new parameter allows callers to provide a rebase swizzle that the function needs to use to match the requirements of the base internal format involved. This is necessary when the source or destination internal formats (depending on whether we are doing the conversion for a pixel download or a pixel upload respectively) do not match the base formats of the source or destination formats of the conversion. This can happen when the driver does not support the internal formats and uses a different format to store pixel data internally. For example, a texture upload from RGB to Luminance in a driver that does not support textures with a Luminance format may decide to store the Luminance data as RGBA. In this case we want to store the RGBA values as (R,R,R,1). Following the same example, when we download from that texture to RGBA we want to read (R,0,0,1). The rebase_swizzle parameter allows these transforms to happen. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Add an implementation of a master convert function.Jason Ekstrand2015-01-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v2 by Iago Toral <[email protected]>: - When testing if we can directly pack we should use the src format to check if we are packing from an RGBA format. The original code used the dst format for the ubyte case by mistake. - Fixed incorrect number of bits for dst, it was computed using the src format instead of the dst format. - If the dst format is an array format, check if it is signed. We were only checking this for the case where it was not an array format, but we need to know this in both scenarios. - Fixed incorrect swizzle transform for the cases where we convert between array formats. - Compute is_signed and bits only once and for the dst format. We were computing these for the src format too but they were overwritten by the dst values immediately after. - Be more careful when selecting the integer path. Specifically, check that both src and dst are integer types. Checking only one of them should suffice since OpenGL does not allow conversions between normalized and integer types, but putting extra care here makes sense and also makes the actual requirements for this path more clear. - The format argument for pack functions is the destination format we are packing to, not the source format (which has to be RGBA). - Expose RGBA8888_* to other files. These will come in handy when in need to test if a given array format is RGBA or in need to pass RGBA formats to mesa_format_convert. v3 by Samuel Iglesias <[email protected]>: - Add an RGBA8888_INT definition. v4 by Iago Toral <[email protected]> after review by Jason Ekstrand: - Added documentation for _mesa_format_convert. - Added additional explanatory comments for integer conversions. - Ensure that we use _messa_swizzle_and_convert for all signed source formats. - Squashed: do not directly (un)pack to RGBA UINT if the source is not unsigned. v5 by Iago Toral <[email protected]>: - Adapted to the new implementation of mesa_array_format as a plain uint32_t bitfield. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Fix _mesa_swizzle_and_convert integer conversions to clamp properlySamuel Iglesias Gonsalvez2015-01-121-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | Fix various conversion paths that involved integer data types of different sizes (uint16_t to uint8_t, int16_t to uint8_t, etc) that were not being clamped properly. Also, one of the paths was incorrectly assigning the value 12, instead of 1, to the constant "one". v2: - Create auxiliary clamping functions and use them in all paths that required clamp because of different source and destination sizes and signed-unsigned conversions. v3: - Create MIN_INT macro and use it. v4: - Add _mesa_float_to_[un]signed() and mesa_half_to_[un]signed() auxiliary functions. - Add clamp for float-to-integer conversions in _mesa_swizzle_and_convert() Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/format_utils: Prefix and expose the conversion helper functionsJason Ekstrand2015-01-121-0/+105
| | | | | | | | | | | Signed-off-by: Jason Ekstrand <[email protected]> v2 by Samuel Iglesias <[email protected]>: - Fix compilation errors Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/format_utils: Add a function to convert a mesa_format to an array formatJason Ekstrand2014-08-051-0/+4
| | | | | | | | | | | | | This commits adds the _mesa_format_to_array function that determines if the given format can be represented as an array format and computes the array format parameters. This is a direct helper function for using _mesa_swizzle_and_convert v2: Better documentation and commit message v3: Fixed a potential segfault from an invalid endianness swizzle Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/format_utils: Add a general format conversion functionJason Ekstrand2014-08-051-0/+41
Most format conversion operations required by GL can be performed by converting one channel at a time, shuffling the channels around, and optionally filling missing channels with zeros and ones. This adds a function to do just that in a general, yet efficient, way. v2: * Add better comments including full docs for functions * Don't use __typeof__ * Use inline helpers instead of writing out conversions by hand, * Force full loop unrolling for better performance v3: Add another set of parens around the MAX_INT macro Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>