| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch unifies nv[34]0_screen.h, nv[34]0_context.h and
nv[34]0_state.h
The unified files are put in a new "nvfx" directory.
nv30_context.h and nv40_context.h still exist to hold the function
prototypes and include nvfx_context.h
nv[34]0_screen.h and nv[34]0_state.h are deleted, replaced by the
unified versions.
nv40 includes some extra fields for swtnl and user clip planes
support.
These fields will be unused on nv30 until that functionality gets
added to it too (by unification with nv40).
|
| |
|
|
|
|
|
| |
Result of running:
perl -i -p -e 's/rankine/eng3d/g; s/curie/eng3d/g;' nv[34]0/*.[ch]
This will allow to more easily unify nv30 and nv40.
|
| |
|
|
|
|
|
|
|
|
|
| |
It was decided to just use the NV34TCL_ constants for constants
common between nv30 and nv40, and deprecate the NV40TCL_ versions.
This patch changes the nv40 driver to use NV34TCL_ constants for
common functionality.
This reduces differences between nv30 and nv40 to ease further
unification.
|
| |
|
|
|
| |
Signed-off-by: Jeff Smith <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour should match what libdrm_nouveau does closely.
- The solution remains statically sized, but when debugging is on it will check
for abuse.
Signed-off-by: Maarten Maathuis <[email protected]>
|
| | |
|
| |
|
|
|
| |
several drivers which chose to ignore edgeflags might require some more work,
while edgeflags never worked there they might now crash.
|
| |
|
|
|
|
|
| |
SrcRegister -> Register
SrcRegisterInd -> Indirect
SrcRegisterDim -> Dimension
SrcRegisterDimInd -> DimIndirect
|
| |
|
|
|
| |
DstRegister -> Register
DstRegisterInd -> Indirect
|
| |
|
|
| |
DeclarationRange -> Range
|
| |
|
|
|
|
|
|
| |
InstructionPredicate -> Predicate
InstructionLabel -> Label
InstructionTexture -> Texture
FullSrcRegisters -> Src
FullDstRegisters -> Dst
|
| |
|
|
|
| |
Rename Semantic.SemanticName to Semantic.Name. Similar for
SemanticIndex, and the members of the tgsi_version struct.
|
| |
|
|
|
|
|
|
| |
It would be nice if these drivers built under the linux-debug header
so that these types of interface changes can be minimally propogated
into those drivers by people without the hardware. They don't have to
generate a working driver -- though a command-dumping winsys would be
an excellent for regression checking.
|
| |
|
|
|
|
| |
Likewise, the extended negate functionality hasn't been
used since mesa switched to using tgsi_ureg to build programs,
and has been translating the SWZ opcode internally to a single MAD.
|
| |
|
|
|
|
|
|
|
| |
These haven't been used by the mesa state tracker since the
conversion to tgsi_ureg, and it seems that none of the
other state trackers are using it either.
This helps simplify one of the biggest suprises when starting off with
TGSI shaders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free the data pointed to, uncertainty
about who owns the data, etc. There doesn't seem to be a need for it,
and it is unlikely to make much difference plus or minus to performance.
Added some asserts as we now will trip up on immediates with more
than four elements. There were actually already quite a few such asserts,
but the >4 case could be used in the future to specify indexable immediate
ranges, such as lookup tables.
|
| | |
|
| |
|
|
|
| |
libdrm_nouveau is linked with the winsys, there's no good reason to do all
this through yet another layer.
|
| | |
|
| | |
|
| |
|
|
| |
Gallium used to do this for us :)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It turns out the user planes handed to the driver are already in clip space.
Hence, we no longer need to transform incoming vertices before computing the
clip distance, and no longer need to change the interface provided by
gallium. Yay :)
The clip state change handling could be better, but this works.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
That was... fun..
|
