the number of vertices to fetch doesn't necessarily equal the
total number of input vertices, e.g. we might want to fetch
a single vertex but then draw it twice. Lets use the correct
number of input vertices in the statistics.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We would crash when stride was bigger than the size of the buffer.
The correct behavior is to just fetch zero's in this case.
Unfortunatly with user_buffer's there's no way to validate the size
because currently we're just not getting it. Adjust the draw interface
to pass the size along the mapped buffer, which works perfectly
for buffer backed vertex_buffers and, in future, it will allow
us to plumb user_buffer sizes through the same interface.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The support is analogous to the way we handle indirect addressing
in temporaries, except that we don't have to worry about storing
(after declarations) and thus we'll able to keep using the old
code when indirect addressing isn't used. In other words we're
still using constants directly, unless the instruction has
immediate register with indirect addressing.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Note: this is a candidate for the 9.1 branch
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Static initialization of internal libstdc++ data related to iostream
causes segfaults with some apps.
This patch replaces all uses of std::ostream and std::ostringstream in sb
with custom lightweight classes.
Prevents segfaults with ut2004demo and probably some other old apps.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Parsing and ir construction is required for optimization only,
it's unnecessary if we only need to print shader dump.
This should make new disassembler more tolerant to any new
features in the bytecode.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Resource mapping is distinct from resource allocation, and is going to get
more and more complex. Move the related functions to a new file to make the
separation clear.
Now tells Gallium that ilo supports primitive restart.
Updated ilo_draw_vbo to be able to check that the indexed
primitive being rendered can actually be supported in HW. If not,
will break up into individual prims similar to what Mesa does.
[olv: a minor fix after rebasing and formatting]
It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).
I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop optimizations could
still be useful in the future.
Reviewed-by: Brian Paul <brianp@vmware.com>
This basically reverts commit
2acc719374.
With the previous change, we're not batchbuffer limited any
longer. So we actually start seeing a performance difference
between X and Y tiling. X tiling is funny because it is
faster for screen-aligned quads but slower in games. So let's
use Y tiling which is 10% faster overall.
Now that we don't throttle at every batchbuffer, we can shrink
the size of batchbuffers to achieve early flushing. This gives
a significant speed boost in a lot of games (on the order of
20%).
It should be TGSI_TYPE_UNSIGNED, not TGSI_TYPE_FLOAT.
Fixed also gallivm not_emit_cpu() to use uint build context.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Move the body of tgsi_opcode_infer_dst_type() to a new helper function,
tgsi_opcode_infer_type(), and call the helper function from
tgsi_opcode_infer_dst_type(). The diff looks complicated simply because the
code is moved around.
A following commit will make tgsi_opcode_infer_src_type() call
tgsi_opcode_infer_type().
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reorder opcodes by their assigned numbers. This makes it easier to see the
differences between tgsi_opcode_infer_src_type() and
tgsi_opcode_infer_dst_type().
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Make use of tgsi_util_get_texture_coord_dim() to replace the big switch table.
There is a subtle difference with this change. When TXP is used with an array
texture, the layer is now also projected. This behavior matches the TGSI doc.
Since GLSL does not allow TXP on an array texture, I am not sure which
behavior is correct or preferred.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
This util function returns the dimension of the texture coordinates for a
texture target, and the location of the shadow reference value.
For example, when the texture target is TGSI_TEXTURE_SHADOW2D, the dimension
of the texture coordinates is 2, and the location of the ref value is 2
(that is, the Z channel).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Adds the remaining integer opcodes, and some opcodes are moved to more
appropriate places, along with getting rid of the (already nearly empty)
ps_2_x section. Though the CAP bits for some of these are still a bit in
the air so the documentation isn't quite as watertight as is desirable.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We can replace CNDxx with MOV (and possibly eliminate after
propagation) in following cases:
If src1 is equal to src2 in CNDxx instruction then the result doesn't
depend on condition and we can replace the instruction with
"MOV dst, src1".
If src0 is const then we can evaluate the condition at compile time and
also replace it with MOV.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Use the same limit for kcache constants in alu group on r6xx as on other
chips (two const pairs). Relaxing this will require additional checks to
make sure that all 4 consts in the group come from 2 kcache sets (clause
limit), probably without noticeable improvements of shader performance.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
This library is very small, so there is not much to gain from building
it as a shared library. Also, when linking statically with LLVM, a
shared libradeonllvm exports LLVM symbols and creates problems when
used with other shared objects that also link statically to LLVM.
Reviewed-by: Mathias.Froehlich@web.de
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
v2:
- Split target initialization and lookup into separate functions
Reviewed-by: Mathias.Froehlich@web.de