summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-09-05mesa: document known possible deviations from ARB_color_buffer_floatfloatingLuca Barbieri1-0/+5
2010-09-05llvmpipe: respect fragment clamping and turn on ARB_color_buffer_floatLuca Barbieri3-1/+11
2010-09-05llvmpipe: rework blending to work properlyLuca Barbieri7-45/+191
Blending has likely been broken from the move to float tiles, since values are no longer automatically clamped. Also, we need to rework it to properly support blending for both fixed and floating point formats. Note that this approach is probably suboptimal, and we should instead always keep tiles with whatever data type the resource has, and blend in the resource data type. Blending in the resource data type gives the correct clamping semantics for free, and should be faster.
2010-09-05llvmpipe: switch from byte-filled tiles to float-filled tiles (v2)Luca Barbieri16-110/+117
Changes in v2: - don't try to use SSE3 swizzles, fixes x86-64 build This is probably undesirable in this form, since it will quadruplicate the memory bandwidth and cache occupation for all resources. It might however reduce the number of instructions. (It also quadruplicates RAM usage, but we are fine with this, since system RAM is typically four times the size of VRAM) Making a byte-based llvmpipe and a float-based one coexist should be the appropriate solution, but is not done in this patch currently.
2010-09-05softpipe: respect fragment clamping and turn on ARB_color_buffer_floatLuca Barbieri2-0/+25
Apparently, we were never clamping fragment colors, resulting in broken OpenGL compliance in presence of blending, even without floating point targets.
2010-09-05softpipe: rework blending to work properlyLuca Barbieri4-170/+158
This changes makes softpipe clamp blend source, destination input, source factor and destination factor if the target is fixed point. Also, it makes it support an unclamped blend color properly. Note this is NOT related to vertex/fragment clamping and is independent of these controls, and only dependent on the type of _each_ color buffer. This is supposed to be the behavior specified by OpenGL 4.1 and ARB_color_buffer_float. Not sure about other APIs.
2010-09-05draw: disable SSE and PPC paths (use LLVM instead)Luca Barbieri1-0/+7
These paths don't support vertex clamping, and are anyway obsoleted by LLVM. If you want to re-enable them, add vertex clamping and test that it works with the ARB_color_buffer_float piglit tests.
2010-09-05draw_llvm: respect vertex color clampLuca Barbieri2-5/+35
2010-09-05draw: respect vertex clamping in interpreter pathLuca Barbieri1-5/+17
2010-09-05mesa/st: respect fragment clamping in st_DrawPixelsLuca Barbieri1-0/+1
2010-09-05mesa/st: support fragment and vertex color clampingLuca Barbieri1-0/+4
2010-09-05llvmpipe: don't assert on new unclamped color capsLuca Barbieri1-0/+3
2010-09-05gallium: add color clamping to the interfaceLuca Barbieri3-1/+33
2010-09-05mesa/st: use floating point temp texture in st_DrawPixels if necessaryLuca Barbieri1-3/+14
Otherwise, we lose precision and get the data always clamped. TODO: should we always try this for floating point input data? TODO: do the transfer operations benefit from conversion to fixed point TODO: happening only after them?
2010-09-05mesa/st: expose ARB_color_buffer_float if unclamping is supportedLuca Barbieri1-0/+7
2010-09-05mesa/st: use unclamped colorsLuca Barbieri3-5/+5
This assumes that Gallium is to be interpreted as given drivers the responsibility to clamp these colors if necessary.
2010-09-05mesa: regenerate glapi for ARB_color_buffer_float (v2)Luca Barbieri13-7918/+8022
Changes in v2: - Fixes brokenness due to outdated code generator
2010-09-05mesa: expose GL_ARB_color_buffer_floatLuca Barbieri6-0/+30
TODO: what about display lists?
2010-09-05mesa, mesa/st: handle read color clamping properlyLuca Barbieri5-12/+34
This follows the idea in this comment: /* XXX * This test should probably go away. Have the caller set/clear the * IMAGE_CLAMP_BIT as needed. */ We set IMAGE_CLAMP_BIT in the caller based on _ClampReadColor, where the operation mandates it. TODO: did I get the set of operations mandating it right?
2010-09-05mesa: respect color clamping in texenv programs (v2)Luca Barbieri9-19/+57
Changes in v2: - Fix attributes other than vertex color sometimes getting clamped
2010-09-05mesa: compute floatMode for FBOs and return it on RGBA_FLOAT_MODELuca Barbieri2-1/+15
2010-09-05mesa: restore color clamps on glPopAttribLuca Barbieri1-0/+3
2010-09-05mesa: clamp color queries if and only if fragment clamping is enabledLuca Barbieri3-9/+62
2010-09-05mesa: introduce derived _ClampXxxColor state resolving FIXED_ONLYLuca Barbieri3-1/+51
To do this, we make ClampColor call FLUSH_VERTICES with the appropriate _NEW flag. We introduce _NEW_FRAG_CLAMP since fragment clamping has wide-ranging effects, despite being in the Color attrib group. This may be easily changed by s/_NEW_FRAG_CLAMP/_NEW_COLOR/g
2010-09-05mesa: add unclamped color parametersLuca Barbieri6-33/+63
2010-09-05mesa: rename MESAX_texture_float to ARB_texture_floatLuca Barbieri1-1/+1
Other than the texel saturation just added, I think we fully implement the ARB extension, as far as I can tell.
2010-09-05mesa: clamp texels in the texenv program as required by ARB_texture_floatLuca Barbieri1-1/+1
Changed in a later patch when ARB_color_buffer_float support is added.
2010-09-05llvmpipe: refuse float16 formats for sampling/render in favor of float32Luca Barbieri1-0/+15
This should be faster, and the state tracker will automatically fall back to the 32-bit formats.
2010-09-05softpipe: remove 32-bit size limit on render target formatLuca Barbieri1-0/+2
2010-09-05mesa/st: enable ARB_texture_float if supported formats allow itLuca Barbieri1-0/+10
2010-09-05mesa/st: support ARB_texture_float internal formatsLuca Barbieri1-0/+124
2010-09-05mesa/st: convert L/A/I floating point formatsLuca Barbieri1-0/+48
2010-09-05gallium: add L/A/I floating point formatsLuca Barbieri2-0/+18
2010-09-05mesa/st: enable ARB_half_float_pixelLuca Barbieri1-0/+1
It seems that nothing else is needed, since the format helpers already support it. I might be missing something though
2010-09-05mesa: don't smash the stack in _mesa_find_used_registersLuca Barbieri1-2/+6
At some point this actually triggered, not sure if it still does. Give a meaningful assert and refuse to smash the stack anyway.
2010-09-05mesa: don't expose unsupported GL_ARB_geometry_shader4 for nowLuca Barbieri1-1/+2
The new GLSL compiler doesn't support it. Advertising it prevents Unigine Heaven from working, since it attempts to use it.
2010-09-05nouveau: delete nouveau_class.h, move nv50 regs to nv50_reg.hLuca Barbieri4-9050/+1775
nv50 should switch to rules-ng-ng too at some point. The classic Mesa Nouveau driver also includes a copy of nouveau_class.h, and should convert to rules-ng-ng too and remove it.
2010-09-05nvfx: move nv04_2d to rules-ng-ngLuca Barbieri3-17/+1518
2010-09-05nvfx: switch to rules-ng-ng register headersLuca Barbieri18-334/+2587
This is the new register generation toolkit in use by nouveau. As far as I know, this is the best register description toolkit in existence, and you should use it too for your hardware :) Thanks to Marcin Kościelnicki for inventing it and performing invaluable reverse engineering work of nVidia chips.
2010-09-05nvfx: remove remaining BEGIN_RING/eng3d usesLuca Barbieri2-15/+18
2010-09-05nvfx: pause occlusion queries during blitter usageLuca Barbieri4-10/+36
Thanks for Dave Airlie and Jerome Glisse for their code which made me realize I need this too.
2010-09-05nvfx: properly return fogcoord.w == 1Luca Barbieri1-1/+15
Hardware sets it to 0, so we add an ADD to put an 1 there if the application really wants the alpha channel.
2010-09-05nvfx: support saturate in vpLuca Barbieri2-66/+93
Completely untested, since Mesa apparently never uses this currently. In particular, it might not work with scalar slot op.
2010-09-05nvfx: add rewritten swtnl supportLuca Barbieri8-263/+238
The old swtnl code was broken by the new shader linkage support for GLSL. This is a rewrite of swtnl support, which should instead work properly, be faster and more closer to the much more tested hardware pipeline.
2010-09-05nvfx: use a piglit-ignored format for unknown cap messageLuca Barbieri1-1/+1
2010-09-05llvmpipe: Remove some broken MinGW hacks in the sin/cos reference code.José Fonseca1-49/+0
2010-09-05glsl: Add new files to sconscript.José Fonseca1-0/+3
2010-09-05llvmpipe: Fix perspective divide interpolation.José Fonseca2-9/+76
Intuition != mathematics, so this time I actually worked out the right formula for first order approximation of perspective interpolation. Ironically, per quad divide actually makes things slower when compared with per pixel divide -- probably because the divide hardware unit is rarely used, whereas the multiply unit is typically already saturated and the first order approximation imply more multiplications.
2010-09-05util: Helper function to determined whether two formats can be memcpy'ed.José Fonseca5-4/+139
These are the non-trivial conversions that this function recognizes, which was produced by u_format_compatible_test.c: b8g8r8a8_unorm -> b8g8r8x8_unorm a8r8g8b8_unorm -> x8r8g8b8_unorm b5g5r5a1_unorm -> b5g5r5x1_unorm b4g4r4a4_unorm -> b4g4r4x4_unorm l8_unorm -> r8_unorm i8_unorm -> l8_unorm i8_unorm -> a8_unorm i8_unorm -> r8_unorm l16_unorm -> r16_unorm z24_unorm_s8_uscaled -> z24x8_unorm s8_uscaled_z24_unorm -> x8z24_unorm r8g8b8a8_unorm -> r8g8b8x8_unorm a8b8g8r8_srgb -> x8b8g8r8_srgb b8g8r8a8_srgb -> b8g8r8x8_srgb a8r8g8b8_srgb -> x8r8g8b8_srgb a8b8g8r8_unorm -> x8b8g8r8_unorm r10g10b10a2_uscaled -> r10g10b10x2_uscaled r10sg10sb10sa2u_norm -> r10g10b10x2_snorm State trackers and pipe drivers should be updated to take advantage of this knowledge, e.g., in surface_copy.
2010-09-05llvmpipe: Relax the colormask constraint on opaque.José Fonseca2-13/+29
Also, include the color buffer in the key. Not having it there causes a tight knots in the logic to determine when it is OK or not to discard previous color buffer contents.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 15:38:18 +0000