summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* radeonsi: Simplify si_dma_copy_tile functionMichel Dänzer2014-09-111-62/+41
| | | | | | No functional change intended. Reviewed-by: Marek Olšák <[email protected]>
* u_vbuf: simple whitespace fixBrian Paul2014-09-101-1/+2
|
* mesa: fix UNCLAMPED_FLOAT_TO_UBYTE() macro for MSVCBrian Paul2014-09-101-4/+4
| | | | | | | | | | MSVC replaces the "F" in "255.0F" with the macro argument which leads to an error. s/F/FLT/ to avoid that. It turns out we weren't using this macro at all on MSVC until the recent "mesa: Drop USE_IEEE define." change. Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: trim down some #includesBrian Paul2014-09-107-12/+2
|
* pipe-loader: Include unistd.h in pipe_loader_drm.c for close function.Vinson Lee2014-09-101-0/+1
| | | | | | | | | | | This patch fixes a build error on DragonFly. CC libpipe_loader_la-pipe_loader_drm.lo pipe_loader_drm.c: In function 'pipe_loader_drm_probe': pipe_loader_drm.c:207:10: error: implicit declaration of function 'close' [-Werror=implicit-function-declaration] Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Disable guardband clipping in the smaller-than-viewport case.Kenneth Graunke2014-09-101-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Apparently guardband clipping doesn't work like we thought: objects entirely outside fthe guardband are trivially rejected, regardless of their relation to the viewport. Normally, the guardband is larger than the viewport, so this is not a problem. However, when the viewport is larger than the guardband, this means that we would discard primitives which were wholly outside of the guardband, but still visible. We always program the guardband to 8K x 8K to enforce the restriction that the screenspace bounding box of a single triangle must be no more than 8K x 8K. So, if the viewport is larger than that, we need to disable guardband clipping. Fixes ES3 conformance tests: - framebuffer_blit_functionality_negative_height_blit - framebuffer_blit_functionality_negative_width_blit - framebuffer_blit_functionality_negative_dimensions_blit - framebuffer_blit_functionality_magnifying_blit - framebuffer_blit_functionality_multisampled_to_singlesampled_blit v2: Mention the acronym expansion for TA/TR/MC in the comments. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: Request lowering gl_VertexIDIan Romanick2014-09-101-0/+1
| | | | | | | | | | | | | Fixes the (new) piglit tests gles-3.0-drawarrays-vertexid, gl-3.0-multidrawarrays-vertexid, and gl-3.2-basevertex-vertexid. Fixes gles3conform failure in: ES3-CTS.gtf.GL3Tests.transform_feedback.transform_feedback_vertex_id Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80247 Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Expose gl_BaseVertex via a vertex attribute.Kenneth Graunke2014-09-103-20/+65
| | | | | | | | | | | | | | | | | | | Now that we have the data available, we need to expose it to the shaders. We can reuse the same vertex element that we use for gl_VertexID, but we need to back it by an actual vertex buffer. A hardware restriction requires that vertex attributes coming from a buffer (STORE_SRC) must come before any other types (i.e. STORE_0). So, we have to make gl_BaseVertex be the .x component of the vertex attribute. This means moving gl_VertexID to a different component. I chose to move gl_VertexID and gl_InstanceID to the .z and .w components, respectively, to make room for gl_BaseInstance in the .y component (which would also come from a buffer, and therefore be STORE_SRC). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Refactor Gen4-7 VERTEX_BUFFER_STATE emission into a helper.Kenneth Graunke2014-09-101-30/+47
| | | | | | | | | We'll need to emit another VERTEX_BUFFER_STATE for gl_BaseVertex; pulling this into a helper function will save us from having to deal with cross-generation differences in that code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Make gl_BaseVertex available in a buffer object.Kenneth Graunke2014-09-103-0/+31
| | | | | | | | | | | This will be used for GL_ARB_shader_draw_parameters, as well as fixing gl_VertexID, which is supposed to include gl_BaseVertex's value. For indirect draws, we simply point at the indirect buffer; for normal draws, we upload the value via the upload buffer. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Calculate start/base_vertex_location after preparing vertices.Kenneth Graunke2014-09-106-12/+34
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Handle SYSTEM_VALUE_VERTEX_ID_ZERO_BASEIan Romanick2014-09-101-0/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Fix glGetActiveAttribute for gl_VertexID when lowered.Kenneth Graunke2014-09-101-1/+13
| | | | | | | | | | | | | The lower_vertex_id pass converts uses of the gl_VertexID system value to the gl_BaseVertex and gl_VertexIDMESA system values. Since gl_VertexID is no longer accessed, it would not be considered active. Of course, it should be, since the shader uses gl_VertexID. v2: Move the var->name dereference past the var != NULL check. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Replace string comparisons with SYSTEM_VALUE enum checks.Kenneth Graunke2014-09-101-2/+2
| | | | | | | This is more efficient. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Add a lowering pass for gl_VertexIDIan Romanick2014-09-106-0/+165
| | | | | | | | | | | | | | | | | | | | | | | | | Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed by SYSTEM_VALUE_BASE_VERTEX. v2: Put the enum in struct gl_constants and propoerly resolve the scope in C++ code. Fix suggested by Marek. v3: Reabase on Matt's foreach_in_list changes (was using foreach_list). v4 (Ken): Use a systemvalue instead of a uniform because STATE_BASE_VERTEX has been removed. v5: Use a boolean to select lowering, and only allow one lowering method. Suggested by Ken. v6 (Ken): Replace strcmp against literal "gl_BaseVertex"/"gl_VertexID" with SYSTEM_VALUE enum checks, for efficiency. v7: Rebase on context constant initialization work. Signed-off-by: Ian Romanick <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* glsl/linker: Make get_main_function_signature publicIan Romanick2014-09-102-4/+8
| | | | | | | | The next patch will use this function in a different file. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Add SYSTEM_VALUE_BASE_VERTEXIan Romanick2014-09-102-1/+15
| | | | | | | | | This system value represents the basevertex value passed to glDrawElementsBaseVertex and related functions. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Add SYSTEM_VALUE_VERTEX_ID_ZERO_BASEIan Romanick2014-09-102-0/+13
| | | | | | | | | | | | There exists hardware, such as i965, that does not implement the OpenGL semantic for gl_VertexID. Instead, that hardware does not include the value of basevertex in the gl_VertexID value. SYSTEM_VALUE_VERTEX_ID_ZERO_BASE is the system value that represents this semantic. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Document SYSTEM_VALUE_VERTEX_ID and SYSTEM_VALUE_INSTANCE_IDIan Romanick2014-09-101-0/+57
| | | | | | | | | v2: Additions to the documentation for SYSTEM_VALUE_VERTEX_ID. Quote the GL_ARB_shader_draw_parameters spec and mention DirectX SV_VertexID. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* configure.ac: unbreak the build with non gnu grepJonathan Gray2014-09-101-1/+1
| | | | | | | | | | | | | | 181581280bd430d122d416e308c1de82db82da04 changed the way the llvm-config version is read from sed to grep and introduced a requirement for gnu grep extension that treats BREs as EREs. Avoid this by calling egrep instead of grep which should be able to handle EREs everywhere. This allows Mesa to build on OpenBSD again. Reviewed-by: Tom Stellard <[email protected]> Signed-off-by: Jonathan Gray <[email protected]>
* vc4: Add support for shadow samplers.Eric Anholt2014-09-091-3/+58
| | | | | | | This doesn't quite make depth-tex-compare work, presumably because we're not hitting equality with itof(sample) * 1.0/0xffffff in the 0xffffff case. arb_fragment_program_shadow tests pass, though, as well as a bunch of other shadow-related stuff.
* vc4: Add support for texture swizzles.Eric Anholt2014-09-091-1/+8
| | | | Fixes depth-tex-modes.
* vc4: Move the texture format into a struct.Eric Anholt2014-09-091-3/+5
| | | | I'm going to be putting some bitfields into the struct as well.
* vc4: Add support for depth texturing.Eric Anholt2014-09-091-3/+13
|
* vc4: Expose r4 to register allocation.Eric Anholt2014-09-094-23/+49
| | | | | | | | We potentially need to be careful that use of a value stored in r4 isn't copy-propagated (or something) across another r4 write. That doesn't appear to happen currently, and this makes the dataflow more obvious. It also opens up not unpacking the r4 value, which will be useful for depth textures.
* vc4: Drop pointless raddr conflict handling on SF.Eric Anholt2014-09-091-1/+0
| | | | SF doesn't have a src[1].
* vc4: The r4_count is supposed to be how many writes, not reads.Eric Anholt2014-09-091-1/+1
| | | | It's part of the key so that you can tell which r4 value is being read.
* r600g,radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOsMichel Dänzer2014-09-103-5/+13
| | | | | | | This lets the kernel know that such BOs can be pinned outside of the CPU accessible part of VRAM. Reviewed-by: Marek Olšák <[email protected]>
* freedreno/a3xx: enable hw primitive-restartRob Clark2014-09-094-9/+20
| | | | | | | | | | Since software primitive-restart emulation is going to be removed (and anyways, mostly seemed to be crash prone in combination with u_primconvert and oddball scenarios (like PIPE_PRIM_POLYGON with only a single vertex), might as well do it in hardware (which fortunately didn't turn out to be too hard to figure out). Signed-off-by: Rob Clark <[email protected]>
* freedreno: update generated headersRob Clark2014-09-094-13/+18
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: fix potential segfault in RARob Clark2014-09-091-2/+6
| | | | | | | | | | | | | | | | | | | | | | Triggered by shaders like: FRAG PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1 DCL OUT[0], COLOR DCL CONST[0] DCL TEMP[0..2], LOCAL 0: IF CONST[0].xxxx :0 1: MOV TEMP[0], TEMP[1] 2: ELSE :0 3: MOV TEMP[0], TEMP[2] 4: ENDIF 5: MOV OUT[0], TEMP[0] 6: END not really a sane shader, although driver segfaulting is probably not the appropriate response. Signed-off-by: Rob Clark <[email protected]>
* freedreno: don't overflow cmdstream buffer so muchRob Clark2014-09-091-0/+15
| | | | | | | | | | | | | | We currently aren't too clever about dealing with running out of cmdstream buffer space. Since we use a single buffer for both drawing and tiling commands, we need to ensure there is enough space at the tail of the cmdstream buffer to fit the tiling commands. Until we get more clever, the easy solution is a threshold to trigger flushing rendering even if the application does not trigger flush (swap, changing render target, etc). This way we at least don't crash for apps that do several thousand draw calls (like some piglit tests do). Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: add no-copy-propagate fallback stepRob Clark2014-09-093-11/+21
| | | | | | | | | | | Most of the things the new compiler still has trouble with basically amount to cp stage removing too many copies. But without the cp stage, the shaders the new compiler produces are still better (perf and correctness) than the old compiler. So a simple thing to do until I have more time to work on it is first trying falling back to new compiler without cp, before finally falling back to old compiler. Signed-off-by: Rob Clark <[email protected]>
* ilo: add ilo_builder.h to the sources listEmil Velikov2014-09-091-0/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* ir_to_mesa: Stop converting uniform booleans.Kenneth Graunke2014-09-091-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Excess conversions considered harmful. Recently Matt reworked the boolean uniform handling to use the value of UniformBooleanTrue, rather than integer 1, when uploading uniforms: mesa: Upload boolean uniforms using UniformBooleanTrue. glsl: Use UniformBooleanTrue value for uniform initializers. Marek then set the default to 1.0f for drivers without native integer support: mesa: set UniformBooleanTrue = 1.0f by default However, ir_to_mesa was assuming a value of integer 1, and arranging for it to be converted to 1.0f on upload. Since Marek's commit, we were uploading 1.0f = 0x3f800000 which was being interpreted as the integer value 1065353216 and converted to float as 1.06535322E9, which broke assumptions in ir_to_mesa that "true" was exactly 1.0f. +13 Piglits on classic swrast (fs-bool-less-compare-true, {vs,fs}-op-not-bool-using-if, glsl-1.20/execution/uniform-initializer). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83573 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* configure.ac: strip _GNU_SOURCE from llvm-config outputJonathan Gray2014-09-091-0/+1
| | | | | | | | | | | Mesa already defines _GNU_SOURCE for glibc based systems and defining _GNU_SOURCE will break the Mesa build on other systems such as OpenBSD. _GNU_SOURCE only seems to be included in llvm-config output when LLVM is built via autoconf and not when it is built by cmake. Cc: "10.2 10.3" <[email protected]> Signed-off-by: Jonathan Gray <[email protected]>
* xmlconfig: suppress libGL warnings when LIBGL_DEBUG == "quiet"Stefan Dirsch2014-09-091-1/+3
| | | | | | | | Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way. Fixes: https://bugzilla.novell.com/show_bug.cgi?id=895730 Signed-off-by: Stefan Dirsch <[email protected]> Reviewed-by: Courtney Goeltzenleuchter <[email protected]>
* automake: remove obsolete NEED_GALLIUM_LOADEREmil Velikov2014-09-095-10/+6
| | | | | | | Superseded by HAVE_LOADER_GALLIUM. The latter has a *DRM* brethren making the whose easier on which one to keep. Signed-off-by: Emil Velikov <[email protected]>
* configure: enable the gallium loader only when neededEmil Velikov2014-09-091-10/+16
| | | | | | | | | | | | | | | With the gallium megadrivers we've converted most ST to optionally use either statically linked in or shared pipe-drivers. The hardcoded switch forgot to conditionally enable the build of the shared pipe-drivers which resulted in them being constantly build. Cc: "10.3" <[email protected]> Cc: James Ausmus <[email protected]> Reported-by: James Ausmus <[email protected]> Tested-by: James Ausmus <[email protected]> Bugzilla: https://code.google.com/p/chromium/issues/detail?id=412089 Signed-off-by: Emil Velikov <[email protected]>
* configure: inform the user when we're building sw/kms-driEmil Velikov2014-09-091-0/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* configure: kill off NEED_WINSYS_WRAPPEREmil Velikov2014-09-092-4/+0
| | | | | | | | Just drop the conditional and simplify our build. This means that it'll build every time, but it does not require any dependencies nor does it take that long to compile 200 lines of boilerplate code. Signed-off-by: Emil Velikov <[email protected]>
* configure: kill off NEED_NONNULL_WINSYSEmil Velikov2014-09-091-33/+21
| | | | | | | | The variable was unused and gave false information. The need for nonnull winsys currently does not relate as it used to. Nowadays one can mix and match more freely with plenty of winsys' to make your head spin. Signed-off-by: Emil Velikov <[email protected]>
* configure: bail out if building svga without libdrmEmil Velikov2014-09-091-0/+3
| | | | | | | | | | | | | | | | | With recent commit we removed the NEED_NONNULL_WINSYS checks when selecting the hardware (inc svga) winsys. svga has only one winsys that explicitly requires libdrm (via it's bundled version of vmwgfx_drm.h) but configure.ac never really checks for it. Add the check early to prevent people from shooting themselves when they select the driver but lack libdrm. $ ./autogen.sh --disable-dri --disable-egl --disable-gallium-llvm --with-dri-drivers=swrast --with-gallium-drivers=svga,swrast Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82539 Cc: "10.2 10.3" <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* vc4: Fix segfaults when rendering with no color render target.Eric Anholt2014-09-092-8/+18
|
* vc4: Fill out the stencil clear field.Eric Anholt2014-09-093-1/+5
| | | | | | The rest of stencil handling isn't done yet, but it documents an extra cl_u8(0) and helps make it obvious why we don't need to format clear_depth the same way the depth/stencil buffer is formatted.
* vc4: Flip around the depth/stencil fields.Eric Anholt2014-09-093-5/+9
| | | | | After implementing depth stores, it looks like this is the way things actually are, according to hiz-depth-read-fbo-d24-s0's probes.
* vc4: Add support for loading/storing the depth buffer.Eric Anholt2014-09-092-7/+62
| | | | | | For now it still requires the color buffer to be present -- we're relying on the store of color buffer contents to end the frame, and we have to do something with color buffers in the rendering config packet.
* vc4: Don't forget to do initial tile clearing for depth/stencil.Eric Anholt2014-09-091-1/+6
|
* vc4: Ignore non-address bits of the offset for load/store.Eric Anholt2014-09-091-1/+1
| | | | | These only get used for full buffer dumps, which we don't support yet anyway.
* vc4: Add a debug flag for flushing after every draw.Eric Anholt2014-09-093-0/+6
| | | | | It was useful on i965, but it's even more useful for debugging tiled renderers.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 09:00:09 +0000