| Age | Commit message (Collapse) | Author |
|---|
|
This isn't necessary, with some effort we can do this on the hw. However,
until I encounter something "real" that uses them there's not a lot of
point.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 1f0f029ba6f22ef4ada01fcdc153da91571a7963.
Which broke the debug build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to do it
|
|
May not always happen due to passthrough modes, etc.
|
|
|
|
|
|
The two functions were mostly the same. We can look at the shader header
info to determine if it's a vertex or fragment shader.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
