Age | Commit message (Collapse) | Author |
|
these formats are needed for hw that can sample and write stencil values.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
this adds the capability + a stencil semantic id, + tgsi scan support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
This diagram shows the rendering pipeline with an emphasis on
the inputs/outputs for each stage. Some stages emit new vertex
attributes and others consume some attributes.
|
|
|
|
different yet compatible formats
|
|
|
|
|
|
This allows to properly support OpenGL rectangle textures in a well
defined way, especially on drivers that don't expose
PIPE_CAP_NPOT_TEXTURES.
|
|
|
|
|
|
Per Jakob's request. Not super-pretty, but it's a good point for modding
later.
|
|
|
|
|
|
Plagiarizes email explanation from Roland.
|
|
Document the new unified drawing method and remove references to old
ones.
|
|
|
|
|
|
I'm not sure if I really got it right. This seems like one of those
"Duh, of course it works that way" things, but I'd like the
documentation to be readable by people not acquainted with OGL/D3D.
|
|
|
|
|
|
Was feeling kind of weird without it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We *did* reach an agreement on this a few months ago, and now the docs
reflect it. However, we never got around to UV and Z...
|
|
I'm not sure I picked the best voice here. I might come back to this
later.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
Conflicts:
src/mesa/state_tracker/st_gen_mipmap.c
src/mesa/state_tracker/st_texture.c
|
|
|
|
Also rearrange some of the fields into point/line/polygon categories.
|
|
|
|
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.
|
|
PIPE_CAP_GLSL and PIPE_CAP_SM3 not removed yet, as opcode support is not
yet covered.
|
|
|
|
|
|
Can't ref in the middle of a paragraph.
|