| Age | Commit message (Collapse) | Author |
|---|
|
|
|
of vertices
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.
|
|
|
|
we need to change it to support composite types
|
|
Brian spotted those
|
|
|
|
|
|
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)
|
|
aka transform feedback
|
|
|
|
This interfacre replaces the drm_api api it works very much the same
way as drm_api but with the exception that its meant for the target
to implement it. And it does not export a get function and neither a
destroy function.
|
|
|
|
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>
|
|
Conflicts:
src/gallium/state_trackers/python/p_context.i
|
|
more consistent with rest of gallium naming conventions.
Also rename driver-internal names for these the same.
|
|
Define PUBLIC to __declspec(dllexport) when _MVC_VER is defined.
|
|
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.
|
|
With the removal of DRI1 support there where no use of this argument,
some drivers didn't even properly check it.
|
|
Since DRI1 support was dropped from st/dri it
makes no sense to keep this code around.
|
|
|
|
|
|
|
|
Conflicts:
src/mesa/state_tracker/st_gen_mipmap.c
src/mesa/state_tracker/st_texture.c
|
|
|
|
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.
|
|
|
|
|
|
PIPE_CAP_GLSL and PIPE_CAP_SM3 not removed yet, as opcode support is not
yet covered.
|
|
|
|
|
|
|
|
It was only used for D3D's REP/END/BGNFOR/ENDFOR. D3D's aL register is
just like another address register now.
|
|
|
|
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
|
|
Different environments seem to want to create these in different
orders. Abstract over this by combining the calls.
|
|
|
|
|
|
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.
|
|
The struct st_module isn't needed as it is the same thing as the st_api
struct. That is they both represent the API. Instead just use a single
function entry point to the the API.
|
|
|
|
|
|
|
|
|
|
|
|
Arcane DX9 opcodes that never were emitted by Mesa and have no DX10
counterpart. Slated for removal for quite some time now.
|
|
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)
|
