Age | Commit message (Collapse) | Author |
|
|
|
|
|
This adjustment fixes some rasterization differences between llvmpipe
and softpipe (and other renderers).
|
|
In some corner cases the right-most / bottom-most vertex can be
right on the edge of the framebuffer. Because the maxx, maxy vals
are computed with a series of float/int, pixel/tile transformations
we can end up with maxx >= scene->x_tiles or maxy >= scene->y_tiles.
This leads to putting data into bins that never get processed, or
reset. This becomes stale data that can lead to segfaults.
Clamping fixes this.
|
|
|
|
Conflicts:
src/gallium/auxiliary/util/u_surface.c
src/gallium/drivers/llvmpipe/Makefile
src/gallium/drivers/llvmpipe/SConscript
src/gallium/drivers/llvmpipe/lp_bld_arit.c
src/gallium/drivers/llvmpipe/lp_bld_flow.c
src/gallium/drivers/llvmpipe/lp_bld_interp.c
src/gallium/drivers/llvmpipe/lp_clear.c
src/gallium/drivers/llvmpipe/lp_context.c
src/gallium/drivers/llvmpipe/lp_context.h
src/gallium/drivers/llvmpipe/lp_draw_arrays.c
src/gallium/drivers/llvmpipe/lp_jit.c
src/gallium/drivers/llvmpipe/lp_jit.h
src/gallium/drivers/llvmpipe/lp_prim_vbuf.c
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/llvmpipe/lp_setup_point.c
src/gallium/drivers/llvmpipe/lp_state.h
src/gallium/drivers/llvmpipe/lp_state_blend.c
src/gallium/drivers/llvmpipe/lp_state_derived.c
src/gallium/drivers/llvmpipe/lp_state_fs.c
src/gallium/drivers/llvmpipe/lp_state_sampler.c
src/gallium/drivers/llvmpipe/lp_state_surface.c
src/gallium/drivers/llvmpipe/lp_tex_cache.c
src/gallium/drivers/llvmpipe/lp_tex_cache.h
src/gallium/drivers/llvmpipe/lp_tex_sample.h
src/gallium/drivers/llvmpipe/lp_tile_cache.c
|
|
The test to determine which of the pixels in a 2x2 quad is now done in
the fragment shader rather than in the calling C code. This is a little
faster but there's a few more things to do.
Note that the step[] array elements are in a different order now. Rather
than being in row-major order for the 4x4 grid, they're in "quad-major"
order. The setup of the step arrays is a little more complicated now.
So is the course/intermediate tile test code, but some lookup tables
help with that.
Next steps:
- early-cull 2x2 quads which are totally outside the triangle.
- skip the in/out test for fully contained quads
- make the in/out comparison code tighter/faster.
|
|
It was pretty confusing having an entity named "bin" and another named
"bins", not least because sometimes there was a need to talk about >1
of the "bins" objects, which couldn't be pluralized any further...
Scene is a term used in a bunch of places to talk about what a binner
operates on, so it's a decent choice here.
|
|
This stub function will interface to the queue system...
|
|
New lp_bins struct contains all bin information.
More move bin-related code into lp_bin.[ch]
Use new/updated bin-access functions to hide implementation details.
The result is more/cleaner separation between the setup and rast components.
This will make double-buffering of the bins easier, etc.
|
|
And put lp_ prefixes on some functions.
|
|
Makes lp_rast_triangle a little smaller (now 280 bytes on a 32-bit system).
|
|
Previously, each triangle had a pointer to the state to use for shading.
Now we insert state-change commands into the bins. When we execute one
of those commands we just update a 'current state' pointer and use that
pointer when calling the jit shader.
When inserting state-change commands into a bin we check if the previous
command was also a state-change command and simply replace it. This
avoids accumulating useless/redundant state-change commands.
|
|
|
|
Much less memory per triangle now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was overdoing it previously.
|
|
Adjustments for top-left fill convention were being lost.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The union itself consists of pointers. We don't need to be passing
pointer to pointers.
|
|
|
|
|
|
|
|
|
|
The "setup" module handles building per-tile display lists.
Intra-tile rendering is handled by lp_rast*.c
|
|
|
|
WIP, does't build or run.
Rasterizer code is based on Nick Capen's devmaster posts and the
larrabee articles, but currently doesn't share either the performance
or correctness of either...
|