aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium
Commit message (Collapse)AuthorAgeFilesLines
* i915g: Fix assertStephane Marchesin2013-10-121-1/+1
| | | | | | Now that we support start, assert on start + num < max samplers Reported by xexaxo
* radeon/llvm: show LLVM disassembly when availableJay Cornwall2013-10-123-1/+9
| | | | | | | | With code dump enabled LLVM may generate disassembly during compilation. Show this disassembly when available and prefer it to SI bytecode dump. Reviewed-by: Tom Stellard <[email protected]> Signed-off-by: Jay Cornwall <[email protected]>
* softpipe: fix seamless cube filteringRoland Scheidegger2013-10-121-48/+151
| | | | | | | | | | | | | | | | | | | | | | Fix coord wrapping (and face selection too) in case of edges. Unfortunately, the coord wrapping is way more complicated than what the code did, as it depends on the face and the direction where the texel falls off the face (the logic needed to get this right in fact seems utterly ridiculous). Also fix a bug in (y direction under/overflow) face selection. And get rid of complicated cube corner handling. Just like edge case, the coord wrapping was wrong and it seems very difficult to fix. I'm near certain it can't always work anyway (though ordinary seamless filtering on edge has actually a similar problem but not as severe) because we don't have per-pixel face, hence could have multiple corner texels which would make it very difficult to average the remaining texels correctly. Hence simply pick a texel which would only have fallen off one edge but not both instead, which is not quite accurate but actually I think should be enough to meet OpenGL (but not d3d10) requirements. v2: small fixes suggested by Brian, add some comments. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: increase fs shader variant instruction cache limit by factor 4Roland Scheidegger2013-10-121-2/+2
| | | | | | | | | | | | | | | | | The previous limit of of 128*1024 was reported to cause frequent recompiles in some apps due to shader variant thrashing on IRC in some apps leading to noticeable lags. Note that the LP_MAX_SHADER_VARIANTS limit (1024) was more or less impossible to reach, since even simple fragment shaders without texturing (glxgears) used more than twice than 128 instructions, hence the instruction limit would have always been reached first (excluding things like trivial shaders not writing color). Even with the new limit it is VERY likely the instruction limit is hit first. Should help with such lags due to recompiles (though other shader types have their own limits, LP_MAX_SETUP_VARIANTS and DRAW_MAX_SHADER_VARIANTS, in particular the latter seems a bit small (128)). Reviewed-by: Brian Paul <[email protected]>
* svga: s/0/FALSE/Brian Paul2013-10-111-2/+2
|
* wayland: Don't rely on static variable for identifying wl_drm buffersKristian Høgsberg2013-10-111-2/+9
| | | | | | | | | | | | Now that libEGL has been fixed to not leak all kinds of symbols, gbm links to its own copy of the libwayland-drm.a helper library. That means we can't rely on comparing the addresses of a static vtable symbol in that library to determine if a wl_buffer is a wl_drm_buffer. Instead, we move the vtable into the wl_drm struct and use that for comparing. https://bugs.freedesktop.org/show_bug.cgi?id=69437 Cc: 9.2 <[email protected]>
* r600g: fix crash in set_framebuffer_stateGrigori Goronzy2013-10-112-12/+26
| | | | | | | | We should be able to safely set the framebuffer state without a fragment shader bound. bind_ps_state will take care of updating the necessary state bits later. v2: check in update_db_shader_control
* haiku: Fix llvmpipe and clean up softpipe tracingAlexander von Gluck IV2013-10-104-8/+6
| | | | | | | * Fix LLVM library and defines * Only enable tracing when scons build=debug Acked-by: Brian Paul <[email protected]>
* haiku: Remove common directory search pathAlexander von Gluck IV2013-10-101-2/+0
| | | | | | | * /boot/common no longer exists in Haiku as of a few days ago (and this is undefined) Acked-by: Brian Paul <[email protected]>
* dri: Move API version validation into dri/common.Eric Anholt2013-10-102-8/+13
| | | | | | | | | | | | | | | | | i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the same logic, except where they failed to. Notably, swrast had code that appeared to try to enable GLES1/2 but forgot to set api_mask (thus preventing any gles context from being created), and the non-intel drivers didn't support MESA_GL_VERSION_OVERRIDE. nouveau still relies on _mesa_compute_version(), because I don't know what its limits actually are, and gallium drivers don't declare limits up front at all. I think I've heard talk about doing so, though. v2: Compat max version should be 30 (noted by Ken) Drop r100's custom max version check, too (noted by Emil Velikov) Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Merge drisw_util.c into dri_util.cEric Anholt2013-10-103-7/+14
| | | | | | | | | | | | The only important difference was not calling drmGetVersion, and making the swrast extension vtable. That doesn't justify duplicating the other 330 lines of code. v2: fix the scons build (code by Emil Velikov) v3: fix scons build with swrast-only (code by Emil Velikov) v4: Drop the new define I added, when we already have __NOT_HAVE_DRM_H. Signed-off-by: Emil Velikov <[email protected]>
* radeon/winsys: fix handling in radeon_drm_cs_flush v2Christian König2013-10-102-5/+4
| | | | | | | | | | | | | Calling radeon_drm_cs_flush from multiple threads might cause deadlocks, fix this by immediately signaling the semaphore after waiting for it. This is a candidate for the stable branch(es). Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=70123 v2: some fixes on commit message Signed-off-by: Christian König <[email protected]>
* util: Fix MinGW build.José Fonseca2013-10-091-1/+1
| | | | | _GNU_SOURCE appears to not be used reliably. Use _MSC_VER instead so that MSVC alone is affected.
* llvmpipe: We don't use the draw pipeline for offset_point/line.José Fonseca2013-10-091-2/+0
| | | | | | | | Unless the polygon fill mode is different from PIPE_POLYGON_MODE_FILL, so checking the the polygon mode is sufficient. Testing done: no regression in polygon-mode-offset Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: kill old per-quad face selection codeRoland Scheidegger2013-10-101-475/+286
| | | | | | | | | | Not used since ages, and it wouldn't work at all with explicit derivatives now (not that it did before as it ignored them but now the code would just use the derivs pre-projected which would be quite random numbers). v2: also get rid of 3 helper functions no longer used. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: handle explicit derivatives for cubemapsRoland Scheidegger2013-10-103-56/+235
| | | | | | | | | | | | | | | | | | | | They need some special handling. Quite complicated. Additionally, use the same code for implicit derivatives too if no_rho_approx and no_quad_lod is set, because it seems while generally it should be ok to use per quad lod for implicit derivatives there's at least some test which insists that in case of cubemaps the shared lod value MUST come from a pixel inside the primitive (due to the derivatives becoming different if a different larger major axis is chosen). v2: based on Brian's feedback, clean up code a bit. And use sign bit of major axis instead of pre-select s/t/r sign for coord mirroring (which should be the same in the end, saves 2 ands). Also fix two bugs with select/mirror of derivatives, the minor axes need to use major axis sign as well (instead of major derivative axis sign), and don't mistakenly use absolute values of major derivative and inverse major values. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: ignore rho approximation for cube mapsRoland Scheidegger2013-10-101-30/+20
| | | | | | | | | | | | | | There's two reasons for this: 1) even when ignoring rho approximation for cube maps, the result is still not correct, but it's better as the max error at edges is now sqrt(2) instead of 2 (which was a full mip level), same as it is for ordinary 2d maps when doing rho approximations (so the error actually goes from factor 2 at edges and sqrt(2) completely inside a face to sqrt(2) at edges and 0 inside a face). 2) I want to repurpose rho_no_approx for cubemaps for fully correct cubemap derivatives (so don't need yet another debug var). Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* util/u_math: Fix C++ include of u_math.h on MSVC.José Fonseca2013-10-101-1/+1
| | | | | | | GNU C++ compiler declares the C99 lrint, etc. when _GNU_SOURCE is defined, but MSVC does not. Trivial.
* llvmpipe: abstract the code to set number of subpixel bitsZack Rusin2013-10-093-10/+15
| | | | | | | | | | As we're moving towards expanding the number of subpixel bits and the width of the variables used in the computations we need to make this code a bit more centralized. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: implement 64 bit mul opcodes in llvmpipeZack Rusin2013-10-091-0/+60
| | | | | | | | | Both the imul_hi and umul_hi are working with this patch. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: Add support for 32x32 muls with 64 bit resultsZack Rusin2013-10-098-1/+103
| | | | | | | | | | | | | | The code introduces two new 32bit integer multiplication opcodes which can be used to produce correct 64 bit results. GLSL, OpenCL and D3D10+ require them. We use two seperate opcodes, because they match the behavior of GLSL and OpenCL, are a lot easier to add than a single opcode with multiple destinations and because there's not much (any) difference wrt code-generation. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallivm: support printing of 64 bit integersZack Rusin2013-10-091-1/+6
| | | | | | | only 8 and 32 bit integers were supported before. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallium/state_trackers/glx: X11/Xlib.h: No such file or directoryGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | | | | | The compiler cannot find the Xlib.h in the installed system headers. All supplied include directives point to inside the mesa module. The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. The Xlib.h file is not installed on my workstation. It is supplied in the libx11-dev package. This allows an X developer control over which version of this file is used for X development. Use to test: --enable-gallium-egl --enable-xlib-glx --disable-dri Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* gallium/targets/libgl-xlib: X11/Xlib.h: No such file or directoryGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | | | The compiler cannot find the Xlib.h in the installed system headers. All supplied include directives point to inside the mesa module. The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. The Xlib.h file is not installed on my workstation. It is supplied in the libx11-dev package. This allows an X developer control over which version of this file is used for X development. Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* gallium/state_trackers/egl: use X11_INCLUDES rather than X11_CFLAGSGaetan Nadon2013-10-091-1/+1
| | | | | | | | | | | | | The X11_CFLAGS variable is undefined (not defined in config.status). It appears the intent was to use X11_INCLUDES defined in configure.ac. It is used for building the code in the x11 subdir. The build does not fail on this one as LIBDRM_CFLAGS happens to have the inludedir value as the one for X11. It will not always be the case. The option --enable-gallium-egl is required durimg configuration. Acked-by: Brian Paul <[email protected]> Signed-off-by: Gaetan Nadon <[email protected]>
* st/vdpau: really block until surface is idleGrigori Goronzy2013-10-091-1/+2
| | | | | | | | | | | | pipe_screen::fence_finish with zero timeout returns quickly and doesn't wait at all. Fix that, and also delete the fence afterwards, so that QuerySurfaceStatus returns the right state later. Addresses: https://trac.videolan.org/vlc/ticket/9281 https://bugs.freedesktop.org/show_bug.cgi?id=68792 Reviewed-by: Christian König <[email protected]>
* st/vdpau: add new formats to OutputSurface renderingGrigori Goronzy2013-10-092-1/+24
| | | | | | | | OutputSurfaces have simple YCbCr rendering functionality built in, but so far only 4:2:0 subsampling worked correctly. This fixes 4:2:2 and 4:4:4 formats. Reviewed-by: Christian König <[email protected]>
* st/vdpau: fix GenerateCSCMatrix with NULL procampGrigori Goronzy2013-10-091-9/+12
| | | | | | | | | | | | As per API specification, it is legal to supply a NULL procamp. In this case, a CSC matrix according to the colorspace should be generated, but no further adjustments are made. Addresses: https://trac.videolan.org/vlc/ticket/9281 https://bugs.freedesktop.org/show_bug.cgi?id=68792 Reviewed-by: Christian König <[email protected]>
* radeon/uvd: disable VC-1 simple/main profileGrigori Goronzy2013-10-091-1/+3
| | | | | | | | It doesn't work (decodes to garbage) with most videos on UVD 3.0. Worse yet, it often results in random memory corruption or GPU hangs. Rumor has it only the newest UVD hardware could do it anyway. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: try to fix VC-1 decodingGrigori Goronzy2013-10-091-33/+38
| | | | | | | | | | | | | The DPB size calculations seem to be off; there is various random corruption happening, even with advanced profile. Always assuming a minimum number of references appears to fix it, similarly to H.264. This might overallocate the DPB. Also clean up the SPS/PPS field setup so that it matches VC-1 specifications better. With these changes, all advanced profile VC-1 files I could get my hand on work fine. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: fix video format reportingGrigori Goronzy2013-10-091-2/+5
| | | | | | | | | | UVD can only support NV12 in the case of hardware decoding, but we can still use all other formats for software decoding. Use the UNKNOWN profile to signal that we're not interesting in hardware decoding. v2: use profile instead of entrypoint Reviewed-by: Christian König <[email protected]>
* gallium/dri targets: use DRI_DRIVER_LDFLAGSMarek Olšák2013-10-099-9/+9
| | | | | | | which contains -Wl,-Bsymbolic. If I understand it correctly, it prevents symbols from clashing if multiple drivers are loaded at the same time. Tested-by: Emil Velikov <[email protected]>
* radeonsi: fix occlusion queries for CIKMarek Olšák2013-10-091-3/+12
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* radeonsi: draw register fixes for CIKMarek Olšák2013-10-092-9/+27
| | | | | | This doesn't fix any known issue. I'm just following the docs. Reviewed-by: Michel Dänzer <[email protected]>
* st/dri: don't export any private symbolsMarek Olšák2013-10-082-1/+3
| | | | Reviewed-by: Tom Stellard <[email protected]>
* gallium/swrast: don't export any private symbolsMarek Olšák2013-10-084-4/+8
| | | | Reviewed-by: Tom Stellard <[email protected]>
* gallium/radeon: don't export any private symbolsMarek Olšák2013-10-0814-16/+32
| | | | Reviewed-by: Tom Stellard <[email protected]>
* i915g: Rename sampler to fragment_samplerStéphane Marchesin2013-10-074-9/+9
| | | | Otherwise it is fairly confusing.
* i915g: Fix the sampler bind functionStéphane Marchesin2013-10-071-19/+30
| | | | | | | | The new sampler bind sends us NULL samplers, so we need to count the number of valid samplers ourselves. This fixes ~500 piglit regressions from the sampler rework. While we're at it, let's also support start.
* clover: fix building with llvm-3.4 since rev191922Laurent Carlier2013-10-071-1/+5
| | | | http://llvm.org/viewvc/llvm-project?view=revision&revision=191922
* radeon/vdpau: only export necessary symbolsChristian König2013-10-073-0/+9
| | | | | | Export only the absolutely necessary symbols in radeon vdpau targets. Signed-off-by: Christian König <[email protected]>
* radeon/uvd: optimize message handling a bitChristian König2013-10-071-44/+53
| | | | | | | No need to keep a copy of the message in system memory anymore, since it should now be in GART memory on newer chips. Signed-off-by: Christian König <[email protected]>
* Revert "r600g: only flush the caches that need to be flushed during CP DMA ↵Marek Olšák2013-10-064-139/+28
| | | | | | | | | | | | | | | | | operations" This reverts commit 7948ed1250cae78ae1b22dbce4ab23aceacc6159. It caused graphical corruption. I've got no idea why. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70042 https://bugs.freedesktop.org/show_bug.cgi?id=68451 Conflicts: src/gallium/drivers/r600/evergreen_hw_context.c src/gallium/drivers/r600/r600_hw_context.c src/gallium/drivers/r600/r600_pipe.h
* haiku: Ensure correct libraries are referenced.Alexander von Gluck IV2013-10-041-1/+0
|
* haiku: Clean up code, use target-helpersAlexander von Gluck IV2013-10-041-10/+6
| | | | * Thanks for the help xexaxo!
* haiku: Drop haiku-softpipe.c; fix extern CAlexander von Gluck IV2013-10-044-103/+1
| | | | | | | * It isn't needed any longer as we're moving in the code that called it. * The winsys code is C, so make sure we include the header in the extern C
* haiku: Correct Haiku softpipe libraryAlexander von Gluck IV2013-10-041-1/+1
| | | | * Use LoadableModule vs SharedLibrary
* haiku: Add first Haiku renderer (softpipe)Alexander von Gluck IV2013-10-049-5/+1249
| | | | | * This shared library gets parsed by the system as a system "add-on"
* haiku: Build Haiku's libGL from within MesaAlexander von Gluck IV2013-10-048-0/+1242
| | | | | | | * This in essence means that Mesa would be taking control of Haiku's OpenGL kit. * This works by dispatching renderers from the OpenGL add-ons directory
* r600g: texture offsets for non-TXF instructionsGrigori Goronzy2013-10-041-10/+10
| | | | | | | All texture instructions can use offsets, not just TXF. Offsets into the literals array were wrong, too. Signed-off-by: Marek Olšák <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 20:18:34 +0000