| Age | Commit message (Collapse) | Author |
|---|
|
we were only running the llvm paths when the input elts were linear,
now we can handle abritrary fetch elts arrays. we do this by generating
two paths - linear and fetch_elts one and just selecting the right one
at run time.
|
|
Everybody should respect max_index, specially llvm generated code, which
likes to eat vertices 4 at a time, so it may end up chew a bit a bit more
than actually exists.
|
|
Now that draw depends on llvm it is very difficult to correctly handle
broken llvm installations. Either the user requests LLVM and it needs to
supply a working installation. Or it doesn't, and it gets no LLVM
accelerate pipe drivers.
|
|
our code resets pipe_vertex_buffer's with different offsets when rendering
vbo, meaning that we kept creating insane number of shaders even for simple
apps e.g. geartrain had 54 shaders and it was taking almost 27 seconds just to
compile them. this patch passes pipe_vertex_buffer's to the jit function and lets
it to the stride/buffer_offset computation at run time. the slowdown at runtime
is largely unnoticable but the we go from 54 shaders to 3, and from 27 seconds to less
than 1.
|
|
|
|
there's no good way of aligning the output's, and since the vertex_header
is variable sized in the first place we need to extract elements from a vector
and store them individually into an array. this gets the basic examples working
again
|
|
|
|
the from translation isn't quite right yet
|
|
the values passed are still not right, but the general scheme
is looking good.
|
|
code generate big chunks of the vertex pipeline in order to speed up
software vertex processing.
|
