allows application to not only request the frequency of the TIME_ELAPSED
clock but also to detect if that frequency was consistent throughout the
entire bracketed range of graphics commands.
like normal temporaries, but allows to define a number of distinct
arrays, all of which make it explicit that they contain /indexable/
registers.
as a side-effect we're adding support for multi-dimensional destination
registers.
The whole thing looks like this:
DCL TEMPX[0][0..128] # 0 array with 128 registers
ADD TEMPX[0][0], IN[0], IMM[0]
ADD TEMPX[0][1], IN[0], IMM[0]
ABS OUT[0], TEMPX[0][TEMP[0]]
allows one to specify a safe (bound checked) array
filled with immediates. it works just like a const
array and declares much like our current immediates.
lots and lots of fixes for geometry shaders. in particular now we work when the gs
emits a different primitive than the one the pipeline was started with and also
we work when gs emits more vertices than would fit in the original buffer.
interface wise we have everything needed by d3d10 and gl transform feedback.
the draw module misses implementation of some corner cases (e.g. when stream
output wants different number of components per output than normal rendering
paths)
This passes on r300g, the only bit I'm not really sure about is the handling
of the sampler_view in st_atom_texture.c, I unreference it there if the swizzle
value changes and I also have to create a new set of functions to create a new
one since the u_sampler.c ones don't handle swizzle so much.
adds r300g + softpipe enables, I think other drivers could pass easily enough.
Signed-off-by: Dave Airlie <airlied@redhat.com>
clears were a bit limited in gallium:
- no scissoring (OGL only) nor explicit rectangle list (d3d9)
- no color/stencil masks (OGL only)
- no separate depth/stencil clears (d3d9/d3d10/OGL)
- cannot really clear single color buffer (only with resource_fill_region)
Additionally, d3d can clear surfaces not currently bound to the framebuffer.
It is, however, not easy to find some common ground what a clear should be able
to do, due to both API requirements and also hw differences (a case which might
be able to use a special clear path on one hw might need a "normal" quad render
on another).
Hence several clear methods are provided, and a driver should implement all of
them.
- clear: slightly modified to also be able to clear only depth or stencil in a
combined depth/stencil surface. This is however optional based on driver
capability though ideally it wouldn't be optional. AFAIK this is in fact
something used by applications quite a bit.
Otherwise, for now still doesn't allow clearing with scissors/mask (or single
color buffers)
- clearRT: clears a single (potentially unbound) color surface. This was formerly
roughly known as resource_fill_region. mesa st will not currently use this,
though potentially would be useful for GL ClearBuffer.
- clearDS: similar to above except for depth stencil surfaces.
Note that clearDS/clearRT currently handle can handle partial clear. This might
change however.
Previously, surface_copy was said to allow overlapping blits, and it was
"optional". However, some state trackers actually assumed it is always present,
and quite some code (like in u_blit) assumed overlapping isn't allowed.
Hence, resource_copy_region (and in the same spirit, resource_fill_region) is
now mandatory, but overlapping blits are no longer allowed. A driver can plug
in the cpu fallback util_resource_copy_region if it does not want to provide its
own implementation, though this is not optimal.
due to popular request, use nr_samples parameter in is_format_supported()
instead of new is_msaa_supported() query.
This makes it easily possible to query if a format with a given sample count
is also supported not only as render target, but for sampler views (note that
texture sampling from multisampled resources isn't supported yet).
It is not quite how dx10 format msaa queries work, but we might need to revisit
format queries completely in the future anyway.
Use front/back instead of cw/ccw throughout.
Also, use offset_point/line/fill instead of offset_cw/ccw.
Brings gallium representation of this state into line with its main
user, and also what turns out to be the most common hardware
representation.
This fixes a long-standing bias in the interface towards the
architecture of the software rasterizer.
add function to set sample mask, and state for alpha-to-coverage and
alpha-to-one. Also make it possible to query for supported sample count
with is_msaa_supported().
Use explicit resource_resolve() to resolve a resource. Note that it is illegal
to bind a unresolved resource as a sampler view, must be resolved first (as per
d3d10 and OGL APIs, binding unresolved resource would mean that special texture
fetch functions need to be used which give explicit control over what samples
to fetch, which isn't supported yet).
Also change surface_fill() and surface_copy() to operate directly on resources.
Blits should operate directly on resources, most often state trackers just used
get_tex_surface() then did a blit. Note this also means the blit bind flags are
gone, if a driver implements this functionality it is expected to handle it for
all resources having depth_stencil/render_target/sampler_view bind flags (might
even require it for all bind flags?).
Might want to introduce quality levels for MSAA later.
Might need to revisit this for hw which does instant resolve.
indexBias corresponds to:
- BaseVertexIndex parameter of D3D9's
IDirect3DDevice9::DrawIndexedPrimitive method
- BaseVertexLocation parameter of ID3D10Device::DrawIndexed
Although a positive indexBias can be easily be implemented in Gallium by
adding indexBias*stride to each vertex buffer base offset, a negative
indexBias cannot, as the final vertex buffer offset could be negative.
I'm not aware of this functionality being exposed to GL drivers, so for
now all hardware drivers will just assert(indexBias == 0).
See also:
- http://msdn.microsoft.com/en-us/library/bb174369.aspx (D3D9)
- http://msdn.microsoft.com/en-us/library/ff556126.aspx (D3D10 DDI)
