summaryrefslogtreecommitdiff
path: root/src/gallium/auxiliary
AgeCommit message (Collapse)AuthorFilesLines
2013-07-17gallivm: (trivial) simplify lp_build_cos/lp_build_sin a tiny bitRoland Scheidegger1-7/+6
Use "or" instead of "add" (this is a classic select sequence, which at least newer llvm versions can actually recognize (3.2+?), and the "add" might prevent that - and we really don't want an add instead of an or with avx if it isn't recognized (even without avx logic ops might be cheaper)). Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-17util/u_format_s3tc: handle srgb formats correctly.Roland Scheidegger2-185/+254
Instead of just ignoring the srgb/linear conversions, simply call the corresponding conversion functions, for all of pack/unpack/fetch, both for float and unorm8 versions (though some don't make a whole lot of sense, i.e. unorm8/unorm8 srgb/linear combinations). Refactored some functions a bit so don't have to duplicate all the code (there's a slight change for packing dxt1_rgb, as there will now be always 4 components initialized and sent to the external compression function so the same code can be used for all, the quite horrid and ad-hoc interface (by now) should always have worked with that). Fixes llvmpipe/softpipe piglit texwrap GL_EXT_texture_sRGB-s3tc. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-17gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}intEmil Velikov2-8/+8
Every function but the above four uses explicitly sized types for their src and dst arguments. Even fetch_rgba_{s,u}int follows the convention. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Marek Olšák <maraeo@gmail.com>
2013-07-17llvmpipe: use MCJIT on ARM and AArch64Kyle McMartin1-1/+1
MCJIT is the only supported LLVM JIT on AArch64 and ARM (the regular JIT has bit-rotted badly on ARM and doesn't exist on AArch64.) Signed-off-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-07-16llvmpipe: support sRGB framebuffersRoland Scheidegger2-4/+54
Just use the new conversion functions to do the work. The way it's plugged in into the blend code is quite hacktastic but follows all the same hacks as used by packed float format already. Only support 4x8bit srgb formats (rgba/rgbx plus swizzle), 24bit formats never worked anyway in the blend code and are thus disabled, and I don't think anyone is interested in L8/L8A8. Would need even more hacks otherwise. Unless I'm missing something, this is the last feature except MSAA needed for OpenGL 3.0, and for OpenGL 3.1 as well I believe. v2: prettify a bit, use separate function for packing. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-14gallivm: (trivial) use constant instead of exp2f() functionRoland Scheidegger1-2/+3
Some lame compilers can't do exp2f() and as far as I can tell they can't do exp2() (with doubles) neither so instead of providing some workaround for that (wouldn't actually be too bad just replace with pow) and since it is used with a constant only just use the precalculated constant.
2013-07-13gallivm: handle srgb-to-linear and linear-to-srgb conversionsRoland Scheidegger6-7/+332
srgb-to-linear is using 3rd degree polynomial for now which should be _just_ good enough. Reverse is using some rational polynomials and is quite accurate, though not hooked into llvmpipe's blend code yet and hence unused (untested). Using a table might also be an option (for srgb-to-linear especially). This does not enable any new features yet because EXT_texture_srgb was already supported via util_format fallbacks, but performance was lacking probably due to the external function call (the table used by the util_format_srgb code may not be all that much slower on its own). Some performance figures (taken from modified gloss, replaced both base and sphere texture to use GL_SRGB instead of GL_RGB, measured on 1Ghz Sandy Bridge, the numbers aren't terribly accurate): normal gloss, aos, 8-wide: 47 fps normal gloss, aos, 4-wide: 48 fps normal gloss, forced to soa, 8-wide: 48 fps normal gloss, forced to soa, 4-wide: 47 fps patched gloss, old code, soa, 8-wide: 21 fps patched gloss, old code, soa, 4-wide: 24 fps patched gloss, new code, soa, 8-wide: 41 fps patched gloss, new code, soa, 4-wide: 38 fps So there's a performance hit but it seems acceptable, certainly better than using the fallback. Note the new code only works for 4x8bit srgb formats, others (L8/L8A8) will continue to use the old util_format fallback, because I can't be bothered to write code for formats noone uses anyway (as decoding is done as part of lp_build_unpack_rgba_soa which can only handle block type width of 32). Compressed srgb formats should get their own path though eventually (it is going to be expensive in any case, first decompress, then convert). No piglit regressions. v2: use lp_build_polynomial instead of ad-hoc polynomial construction, also since keeping both linear to srgb functions for now make sure both are compiled (since they share quite some code just integrate into the same function). v3: formatting fixes and bugfix in the complicated (disabled) linear-to-srgb path. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-13gallivm: better support for fast rsqrtRoland Scheidegger2-16/+63
We had to disable fast rsqrt before because it wasn't precise enough etc. However in situations when we know we're not going to need more precision we can still use a fast rsqrt (which can be several times faster than the quite expensive sqrt). Hence introduce a new helper which does exactly that - it is probably not useful calling it in some situations if there's no fast rsqrt available so make it queryable if it's available too. v2: use fast_rsqrt consistently instead of rsqrt_fast, fix indentation, let rsqrt use fast_rsqrt. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-11gallium: fixup definitions of the rsq and sqrtZack Rusin2-13/+8
GLSL spec says that rsq is undefined for src<=0, but the D3D10 spec says it needs to be a NaN, so lets stop taking an absolute value of the source which completely breaks that behavior. For the gl program we can simply insert an extra abs instrunction which produces the desired behavior there. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2013-07-12util/u_format: Comment out half float denormal test case.José Fonseca1-0/+5
So that lp_test_format doesn't fail until we decide what should be done.
2013-07-12gallivm: Eliminate redundant lp_build_select calls.José Fonseca1-12/+2
lp_build_cmp already returns 0 / ~0, so the lp_build_select call is unnecessary. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2013-07-12tgsi: rename the TGSI fragment kill opcodesBrian Paul14-46/+44
TGSI_OPCODE_KIL and KILP had confusing names. The former was conditional kill (if any src component < 0). The later was unconditional kill. At one time KILP was supposed to work with NV-style condition codes/predicates but we never had that in TGSI. This patch renames both opcodes: TGSI_OPCODE_KIL -> KILL_IF (kill if src.xyzw < 0) TGSI_OPCODE_KILP -> KILL (unconditional kill) Note: I didn't just transpose the opcode names to help ensure that I didn't miss updating any code anywhere. I believe I've updated all the relevant code and comments but I'm not 100% sure that some drivers had this right in the first place. For example, the radeon driver might have llvm.AMDGPU.kill and llvm.AMDGPU.kilp mixed up. Driver authors should review their code. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-12tgsi: fix-up KILP commentsBrian Paul2-5/+3
KILP is really unconditional fragment kill. We've had KIL and KILP transposed forever. I'll fix that next. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-12tgsi: exec TGSI_OPCODE_SQRT as a scalar instruction, not vectorBrian Paul1-1/+1
To align with the docs and the state tracker. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-12tgsi: use X component of the second operand in exec_scalar_binary()Brian Paul1-1/+1
The code happened to work in the past since the (scalar) src args effectively always have a swizzle of .xxxx, .yyyy, .zzzz, or .wwww so whether you grab the X or Y component doesn't really matter. Just fixing the code to make it look right. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2013-07-12os: add os_get_process_name() functionBrian Paul3-0/+133
v2: explicitly test for BSD/APPLE, #warning for unexpected environments.
2013-07-12hud: silence some MSVC warningsBrian Paul1-8/+8
2013-07-12util: add casts to silence MSVC warnings in u_blit.cBrian Paul1-14/+14
2013-07-12tgsi: s/unsigned/int/ to silence MSVC warningBrian Paul1-1/+1
2013-07-10util/u_math: Use xmmintrin.h whenever possible.José Fonseca1-9/+17
It seems __builtin_ia32_ldmxcsr is only available on gcc and only when -msse is used. xmmintrin.h/pmmintrin.h provide portable intrinsics, but these too are only available with gcc when -msse/-msse3 are set. scons build always sets -msse on x86 builds, but autotools doesn't seem to. We could try to get this working on gcc x86 without -msse by emitting assembly, but I believe that in this day and age we really should be building Mesa with -msse and -msse2.
2013-07-09util: treat denorm'ed floats like zeroZack Rusin4-0/+72
The D3D10 spec is very explicit about treatment of denorm floats and the behavior is exactly the same for them as it would be for -0 or +0. This makes our shading code match that behavior, since OpenGL doesn't care and on a few cpu's it's faster (worst case the same). Float16 conversions will likely break but we'll fix them in a follow up commit. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2013-07-05gallivm: (trivial) fix using one lod instead of per-quad lod for texel fetchRoland Scheidegger1-1/+2
The logic for choosing number of lods was bogus. (The code should ultimately handle the case of only one lod even with multiple quads but currently can't.)
2013-07-05gallivm: Remove bogus assert.José Fonseca1-4/+1
It is perfectly valid for the swizzle to be bigger than 2. For example the texel offsets could be SAMPLE ..., IMM[0].zzz What is not correct is for chan_index to be bigger than 2. Trivial.
2013-07-05gallivm: (trivial) fix bogus assertion for per-element lod with 1d resourcesRoland Scheidegger2-2/+1
The assertion was always broken but the code unused until enabling the per-element lod code. Fixes piglit texelFetch vs isampler1D and similar tests (only run with GL 3.0 version override).
2013-07-04gallivm: do per-pixel lod calculations for explicit lodRoland Scheidegger9-125/+193
d3d10 requires per-pixel lod calculations for explicit lod, lod bias and explicit derivatives, and we should probably do it for OpenGL too - at least if they are used from vertex or geometry shaders (so doesn't apply to lod bias) this doesn't just affect neighboring pixels. Some code was already there to handle this so fix it up and enable it. There will no doubt be a performance hit unfortunately, we could do better if we'd knew we had a real vector shift instruction (with variable shift count) but this requires AVX2 on x86 (or a AMD Bulldozer family cpu). Don't do anything for lod bias and explicit derivatives yet, though no special magic should be needed for them neither. Likewise, the size query is still broken just the same. v2: Use information if lod is a (broadcast) scalar or not. The idea would be to base this on the actual value, for now just pretend it's a scalar in fs and not a scalar otherwise (so, per-pixel lod is only used in gs/vs but same code is generated for fs as before). Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
2013-07-03draw: fix overflows in the indexed rendering pathsZack Rusin4-43/+159
The semantics for overflow detection are a bit tricky with indexed rendering. If the base index in the elements array overflows, then the index of the first element should be used, if the index with bias overflows then it should be treated like a normal overflow. Also overflows need to be checked for in all paths that either the bias, or the starting index location. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2013-07-03draw/llvm: index overflows if it's greater than elt maxZack Rusin1-1/+1
The comparison, incorrectly, was greater-than-or-equal to elt max. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2013-07-03postprocess: move second temporary assertion into isolated configurationMatthew McClure1-2/+2
With this patch we will only assert that the second temporary is allocated, when there are more than two active filters. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66423 Signed-off-by: Brian Paul <brianp@vmware.com>
2013-07-02gallivm: Simplify intrinsic name construction.José Fonseca1-23/+10
Just noticed this could be slightly shortened when fixing MSVC build. Trivial.
2013-07-02gallivm: Fix MSVC build.José Fonseca1-8/+7
2013-07-02gallivm: Fix indirect immediate registers.José Fonseca1-2/+2
If reg->Register.Indirect is true then the immediate is not truly a constant LLVM expression. There is no performance regression in using LLVMBuildBitCast, as it will fallback to LLVMConstBitCast internally when the argument is a constant. Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw/translate: fix instancingZack Rusin13-24/+93
We were incorrectly computing the buffer offset when using the instances. The buffer offset is always equal to: start_instance * stride + (instance_num / instance_divisor) * stride We were completely ignoring the start instance quite often producing instances that completely wrong, e.g. if start instance = 5, instance divisor = 2, then on the first iteration it should be: 5 * stride, not (5/2) * stride as we'd have currently, and if start instance = 1, instance divisor = 3, then on the first iteration it should be: 1 * stride, not 0 as we'd have. This fixes it and adjusts all the code to the changes. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw: fix incorrect clipper invocation statisticsZack Rusin1-6/+0
clipper invocations are computed earlier (of course before the emittion) so this code was adding bogus numbers to already computed clipper invocations. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw/gallivm: export overflow arithmetic to its own fileZack Rusin4-44/+234
We'll be reusing this code so lets put it in a common file and use it in the draw module. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw: check for integer overflows in instance computationZack Rusin2-0/+7
Integers could easily overflow is the starting instance was large enough. Instead of letting bogus counts through set the instance to max if it overflown and let our regular buffer overflow computation handle it. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw: check for an integer overflow when computing strideZack Rusin1-10/+43
Our buffer overflow arithmetic was susceptible to integer overflows which was the buffer overflow logic to break. Lets use the llvm overflow intrinsics to check for integer overflows while computing the stride/needed buffer size. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-28draw: account for elem size when computing overflowZack Rusin1-7/+23
We weren't taking into account the size of element that is to be fetched, which meant that it was possible to overflow the buffer reads if the stride was very close to the end of the buffer, e.g. stride = 3, buffer size = 4, and the element to be read = 4. This should be properly detected as an overflow. Signed-off-by: Zack Rusin <zackr@vmware.com>
2013-06-30st/mesa: handle SNORM formats in generic CopyPixels pathMarek Olšák2-0/+23
v2: check desc->is_mixed in util_format_is_snorm
2013-06-27postprocess: handle partial intialization failures.Matthew McClure7-95/+281
This patch fixes segfaults observed when enabling the post processing features. When the format is not supported, or a texture cannot be created, the code must gracefully handle failure and report the error to the calling code for proper failure handling. To accomplish this the following changes were made to the filters.h prototypes: - bool return for pp_init_func - Added pp_free_func for filter specific resource destruction Fixes segfaults from backtraces: * util_destroy_blit pp_free * u_transfer_inline_write_vtbl pp_jimenezmlaa_init_run pp_init This patch also uses tgsi_alloc_tokens to allocate temporary tokens in pp_tgsi_to_state, instead of allocating the array on the stack. This fixes the following stack corruption segfault in pp_run.c: * _int_free aaline_delete_fs_state pp_free Bug Number: 1021843 Reviewed-by: Brian Paul <brianp@vmware.com>
2013-06-26hud: add float casts to silence MSVC warningsBrian Paul1-49/+49
2013-06-26hud: include stdio.h since we use fprintf(), fscanf(), etcBrian Paul1-0/+2
2013-06-26hud: add cast to silence MSVC warningBrian Paul1-1/+1
2013-06-26os: add cast in os_time_sleep() to silence MSVC warningBrian Paul1-1/+1
2013-06-26util: int/unsigned changes to silence some MSVC warningsBrian Paul2-3/+3
2013-06-26util: add some casts to silence some MSVC warningsBrian Paul1-2/+2
2013-06-26util: s/int/unsigned/ to silence some MSVC warningsBrian Paul1-2/+2
2013-06-26vl/mpeg12: handle mpeg-1 bitstreams more correctlyMaarten Lankhorst1-5/+16
Add support for D-frames. Add support for slices ending on a different horizontal row of macroblocks.
2013-06-25util/debug: Cleanup/improve debug_symbol_name_dbghelp.José Fonseca1-78/+161
- use mgwhelp -- the successor for bfdhelp which does not have a hard dependency on BFD, and works on 64bits. - use a macro instead of hand-typing to dispatch DbgHelp functions - dump line numbers - dump module names when symbols are not available - support 64bits. - add comments Reviewed-by: Brian Paul <brianp@vmware.com>
2013-06-25util/debug: Make debug_backtrace_capture work for 64bit windows.José Fonseca2-2/+61
Rely on Windows' CaptureStackBackTrace to do the grunt work. Reviewed-by: Brian Paul <brianp@vmware.com>
2013-06-25draw: allow overflows in the llvm pathsZack Rusin1-4/+8
Because our code couldn't handle it we were skipping rendering if we detected overflows. According to the spec we should still render but with all 0 vertices, which is what the llvm code already does. So for the llvm paths lets enable processing even if an overflow condition has been detected. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-25 08:02:40 +0000