summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/nv30
Commit message (Collapse)AuthorAgeFilesLines
* Remove useless checks for NULL before freeingMatt Turner2012-09-051-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as earlier commit, except for "FREE" This patch has been generated by the following Coccinelle semantic patch: // Remove useless checks for NULL before freeing // // free (NULL) is a no-op, so there is no need to avoid it @@ expression E; @@ + FREE (E); + E = NULL; - if (unlikely (E != NULL)) { - FREE(E); ( - E = NULL; | - E = 0; ) ... - } @@ expression E; type T; @@ + FREE ((T) E); + E = NULL; - if (unlikely (E != NULL)) { - FREE((T) E); ( - E = NULL; | - E = 0; ) ... - } @@ expression E; @@ + FREE (E); - if (unlikely (E != NULL)) { - FREE (E); - } @@ expression E; type T; @@ + FREE ((T) E); - if (unlikely (E != NULL)) { - FREE ((T) E); - } Reviewed-by: Brian Paul <[email protected]>
* Revert "gallium: specify resource_resolve destination via a pipe_surface"Christoph Bumiller2012-08-011-4/+1
| | | | | | | | | | | This reverts commit 5d5af7d359e0060fa00b90a8f04900b96f9058b0. It turns out the issue this was supposed to fix merely counter-acted a bug in the hardware driver that I wasn't aware of. The resource_resolve is not supposed to do sRGB conversion, period. (This would violate the requirement that source and destination must be of the same format).
* gallium: specify resource_resolve destination via a pipe_surfaceChristoph Bumiller2012-07-281-1/+4
| | | | | | | | | | | The format member of pipe_surface may differ from that of the pipe_resource, which is used to communicate, for instance, whether sRGB encode should be enabled in the resolve operation or not. Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB is disabled. Reviewed-by: Brian Paul <[email protected]>
* nv30: Support negative offsets in indirect constant access.Roy Spliet2012-07-204-8/+15
| | | | | | | | Fixes piglit vp-address-01 amongst several others. Signed-off-by: Roy Spliet <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Tested-by: Lucas Stach <[email protected]>
* nouveau: implement missing timer query functionalityChristoph Bumiller2012-07-132-3/+9
|
* gallium: add QUERY_TIMESTAMP cap and get_timestamp screen functionMarek Olšák2012-07-101-0/+1
|
* gallium: Add PIPE_CAP_START_INSTANCEFredrik Höglund2012-06-191-0/+1
| | | | Reviewed-by: Brian Paul <[email protected]>
* automake: Globally add stub automake targets to the old Makefiles.Eric Anholt2012-06-111-3/+0
| | | | | | | | | I tried to update all the old Makefiles that included the default config to be sure they had a default target if they didn't previously have one, since this new all target will always point at it. Almost everything had one. Reviewed-by: Kenneth Graunke <[email protected]>
* nouveau: fix scratch buffer leakMarcin Slusarz2012-06-051-1/+1
| | | | ...and create common function for destroying nouveau_context
* draw: simplify index buffer specificationBrian Paul2012-05-311-3/+4
| | | | | Replace draw_set_index_buffer() and draw_set_mapped_index_buffer() with draw_set_indexes() which simply takes a pointer and an index size.
* nv30: Fix generic passing to fragment program in NV34.Roy Spliet2012-05-253-5/+9
|
* nv30: handle user index buffersChristoph Bumiller2012-05-254-17/+27
|
* nv30: check for NULL vertex buffers in prevalidate_vbufsChristoph Bumiller2012-05-221-1/+1
|
* nouveau: place static buffers in VRAM if preferred by the driverChristoph Bumiller2012-05-171-3/+7
|
* gallium: remove user_buffer_create from the interfaceMarek Olšák2012-05-121-1/+0
| | | | Nothing uses it now.
* nv30: Silence pipe_cap warningsRoy Spliet2012-05-121-0/+4
| | | | | Signed-off-by: Roy Spliet <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
* nv30/shader: SSG, LIT only requires one source registerRoy Spliet2012-05-122-2/+2
| | | | | | | Fixes crashing due to assertion error Signed-off-by: Roy Spliet <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
* Merge branch 'gallium-userbuf'Marek Olšák2012-05-113-9/+28
|\ | | | | | | | | | | | | | | Conflicts: src/gallium/docs/source/screen.rst src/gallium/drivers/nv50/nv50_state.c src/gallium/include/pipe/p_defines.h src/mesa/state_tracker/st_draw.c
| * gallium: add void *user_buffer to pipe_constant_bufferMarek Olšák2012-04-301-0/+10
| | | | | | | | This reduces CPU overhead when updating constants.
| * gallium: add void *user_buffer in pipe_index_bufferMarek Olšák2012-04-302-3/+5
| | | | | | | | | | | | | | Adapted drivers: i915, llvmpipe, r300, r600, radeonsi, softpipe. User index buffers have been disabled in nv30, nv50, nvc0 and svga to keep things working.
| * gallium: remove pipe_context::redefine_user_bufferMarek Olšák2012-04-301-2/+0
| |
| * gallium: add void *user_buffer in pipe_vertex_bufferMarek Olšák2012-04-302-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | This reduces CPU overhead in st_draw_vbo and removes a lot of unnecessary code in that function which was required only to comply with the gallium interface, but wasn't any useful really. Adapted drivers: i915, llvmpipe, r300, softpipe. No changes required in: r600, radeonsi. User vertex buffers have been disabled in nv30, nv50, nvc0 and svga to keep things working.
| * gallium: change set_constant_buffer to be UBO-friendlyMarek Olšák2012-04-301-1/+2
| |
| * gallium: add PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENTMarek Olšák2012-04-301-0/+2
| | | | | | | | | | | | | | | | This is required for any serious constant buffer support. Constant buffer offsets on ATI and NVIDIA DX10 and DX11 GPUs must be a multiple of 256. In OpenGL, this can be queried via GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT.
| * gallium: add PIPE_CAP_USER_INDEX_BUFFERS and PIPE_CAP_USER_CONSTANT_BUFFERSMarek Olšák2012-04-301-0/+2
| |
* | gallium/drivers: handle TGSI_OPCODE_CEILChristoph Bumiller2012-05-092-0/+10
|/
* nv30: properly init window informationBen Skeggs2012-04-272-3/+4
| | | | | | Should fix >2k rendering issues reported on nv4x. Signed-off-by: Ben Skeggs <[email protected]>
* gallium drivers: report that user vertex buffers are supportedMarek Olšák2012-04-241-0/+1
|
* nv30: init sample_mask to some default value at context creation timeBen Skeggs2012-04-151-0/+1
| | | | Fixes demos/lodbias.
* nv30: fix some sifm transfer issuesBen Skeggs2012-04-151-3/+2
|
* nv30: s/DUAL_SOURCE_BLEND/MAX_DUAL_SOURCE_RENDER_TARGETSChristoph Bumiller2012-04-141-1/+1
| | | | Merge accident.
* nv30: import new driver for GeForce FX/6/7 chipsets, and Quadro variantsBen Skeggs2012-04-1436-0/+13716
| | | | | | | | | | | | | | | | | | The primary motivation for this rewrite was to have a maintainable driver going forward, as nvfx was quite horrible in a lot of ways. The driver is heavily based on the design of the nv50/nvc0 3d drivers we already have, and uses the same common buffer/fence code. It also passes a HEAP more piglit tests than nvfx did, supports a couple more features, and a few more to come still probably. The CPU footprint of this driver is far far less than nvfx, and translates into far greater framerates in a lot of applications (unless you're using a CPU that's way way newer than the GPUs of these generations....) Basically, we once again have a maintained driver for these chipsets \o/ Feel free to report bugs now!
* nv30, nv40: move last files to nvfx/ and rm -rf nv30 nv40Luca Barbieri2010-03-153-328/+0
| | | | | | | | | | | This is the last nvfx unification patch. nv[34]0_fragtex.c are moved to the common directory nv[34]0_shader.h are renamed to nv[34]0_vertprog.h and moved to the common directory The separate nv30 and nv40 directories are removed from the build system
* nv30, nv40: partially non-trivially unify sampler state in nv[34]0_state.cLuca Barbieri2010-03-153-181/+31
| | | | | | Many things, like texture wrap modes and min/mag filters are common. Some others, like annisotropy and lod settings, are not.
* nv30, nv40: partially non-trivially unify nv[34]0_fragtex.cLuca Barbieri2010-03-151-44/+1
| | | | | The bulk files cannot be unified, but the frontend can and allows to share some code and simplify state_emit.c
* nv30, nv40: unify nv[34]0_context.cLuca Barbieri2010-03-152-91/+0
| | | | | They are now almost identical, except for nv30 vs nv40 fragtex initialization.
* nv30, nv40: fully unify nv[34]0_context.hLuca Barbieri2010-03-153-16/+2
| | | | Move the remaining content to the common header.
* nv30, nv40: non-trivially unify nv[34]0_screen.cLuca Barbieri2010-03-152-362/+0
| | | | | | The files have the same structure but are substantially different. They are unified with appropriate conditionals.
* nv30, nv40: non-trivially unify nv[34]0_vertprog.cLuca Barbieri2010-03-153-847/+1
| | | | | | | | | | | | | | | | vertprog.c is similar but has substantial differences: 1. nv40 supports clip planes 2. nv40 uses a more advanced register allocator 3. Some register setup is different 4. Constants with the same name have different values This patch unifies the two files. nv30 gains clip plane support and the nv40 register allocator. A new NVFX_VP(x) macro is introduced that at runtime resolved to either the nv30 or the nv40 constant value. nv30 clip planes are not tested and might not work
* nv30, nv40: partially unify nv[34]0_state.cLuca Barbieri2010-03-153-579/+2
| | | | | | | | | state.c is identical except for: 1. Sampler state creation is different 2. nv40 swtnl support 3. Separate blend equations on nv40 This patch unifies nv[34]0_state.c, except the sampler state creation code.
* nv30, nv40: unify nv[34]0_vbo.cLuca Barbieri2010-03-154-575/+2
| | | | | | The files are identical, except for swtnl support which is commented out on nv30 and restart being initialized on nv30 to avoid a compiler warning.
* nv30, nv40: non-trivially unify nv[34]0_draw.cLuca Barbieri2010-03-154-66/+1
| | | | | | | | | | | | nv30_draw.c is a stub. This patch makes both nv30 and nv40 use the nv40 swtnl path. Note that this doesn't actually work on nv30 because the vertex program is encoded in the nv40-only layout. However, swtnl was unimplemented before on nv30, so this is not a regression. Furthermore, a patch to fix this is available near the end of the patchset.
* nv30, nv40: non-trivially unify nv[34]0_fragprog.cLuca Barbieri2010-03-154-910/+1
| | | | | | | | | The files are mostly the same except: 1. On NV40, some TGSI instructions are emulated with several hardware ones 2. Some instructions such as DDX/DDY, and STR were missing from nv30 3. NV40 has more sophisticated register management nv30 now supports all instructions and uses the nv40 register management.
* nv30, nv40: non-trivially partially unify nv[34]0_shader.hLuca Barbieri2010-03-153-475/+154
| | | | | | | | | | | | shader.h is similar, except for the following differences: 1. The instruction sets are not exactly the same, but mostly similar 2. Vertex program fields are in different bit positions This patch unifies all parts of nv[34]0_shader.h except the vertex program fields. Vertex opcodes are also changed so that the constant names includes SCA if it is a scalar opcode and VEC if it is a vector opcode.
* nv30, nv40: non-trivially unify nv[34]0_state_fb.cLuca Barbieri2010-03-153-175/+0
| | | | | | | | | | | | | | The files are significantly different due to: 1. nv30 support 2 render targets, nv40 4 2. z-buffer pitch is set differently 3. nv30 has a limitation of colour_bits >= zeta_bits. This may not actually exist in the driver though 4. nv30 points color0 at depth in the depth-only case 5. nv30 sets NV34TCL_VIEWPORT_TX_ORIGIN to 0. This is probably unnecessary This patch attempts to unify the two files and preserve the existing behavior.
* nv30, nv40: unify nv[34]0_state_viewport.cLuca Barbieri2010-03-153-44/+0
| | | | The files are identical, except for an extra comment in nv30.
* nv30, nv40: unify nv[34]0_query.cLuca Barbieri2010-03-155-195/+2
| | | | The files are identical except formatting.
* nv30, nv40: unify nv[34]0_miptree.cLuca Barbieri2010-03-154-244/+1
| | | | | | | | | | | | | | | | The only difference between nv30 and nv40 is that nv30 allowed swizzling for more texture types. This patch preserves the existing behavior, using conditional code. Note however that this does not make sense, since all texture types can be swizzled on nv40 and probably on nv30 too. However, the handling of swizzled surfaces in the current 2D code is partially broken, so it's best not to touch this. A whole rewrite of the 2D code will be submitted, which will solve this problem.
* nv30, nv40: unify nv[34]0_state_stipple.cLuca Barbieri2010-03-153-42/+0
| | | | | | | The files are identical, except for the fact that the nv40 version forgets to unreference the stateobj. Unified to the correct nv30 version.
* nv30, nv40: unify identical nv[34]0_state_zsa.cLuca Barbieri2010-03-153-44/+0
|