| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
All HW buffers (also suballocated ones) are already aligned.
Just make sure that also the initial sysram buffers have proper
alignment.
|
|
|
|
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
v2: update relnotes-9.1
v3: use align_malloc and align_free for malloced buffers in r300g
v4: document the new CAP in the docs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows updating only a subrange of buffer bindings.
set_vertex_buffers(pipe, start_slot, count, NULL) unbinds buffers in that
range. Binding NULL resources unbinds buffers too (both buffer and user_buffer
must be NULL).
The meta ops are adapted to only save, change, and restore the single slot
they use. The cso_context can save and restore only one vertex buffer slot.
The clients can query which one it is using cso_get_aux_vertex_buffer_slot.
It's currently set to 0. (the Draw module breaks if it's set to non-zero)
It should decrease the CPU overhead when using a lot of meta ops, but
the drivers must be able to treat each vertex buffer slot as a separate
state (only r600g does so at the moment).
I can imagine this also being useful for optimizing some OpenGL use cases.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"get_transfer + transfer_map" becomes "transfer_map".
"transfer_unmap + transfer_destroy" becomes "transfer_unmap".
transfer_map must create and return the transfer object and transfer_unmap
must destroy it.
transfer_map is successful if the returned buffer pointer is not NULL.
If transfer_map fails, the pointer to the transfer object remains unchanged
(i.e. doesn't have to be NULL).
Acked-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Christoph Bumiller <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Christoph Bumiller <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The functionality is provided by the new blit function.
Tested-by: Michel Dänzer <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Tested-by: Michel Dänzer <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same as earlier commit, except for "FREE"
This patch has been generated by the following Coccinelle semantic
patch:
// Remove useless checks for NULL before freeing
//
// free (NULL) is a no-op, so there is no need to avoid it
@@
expression E;
@@
+ FREE (E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- FREE(E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
type T;
@@
+ FREE ((T) E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- FREE((T) E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
@@
+ FREE (E);
- if (unlikely (E != NULL)) {
- FREE (E);
- }
@@
expression E;
type T;
@@
+ FREE ((T) E);
- if (unlikely (E != NULL)) {
- FREE ((T) E);
- }
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Just figured out what that bit does.
Note: It's converted back to sRGB on write, so no effective
conversion occurs.
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5d5af7d359e0060fa00b90a8f04900b96f9058b0.
It turns out the issue this was supposed to fix merely counter-acted
a bug in the hardware driver that I wasn't aware of.
The resource_resolve is not supposed to do sRGB conversion, period.
(This would violate the requirement that source and destination must
be of the same format).
|
|
|
|
|
|
|
|
|
|
|
| |
The format member of pipe_surface may differ from that of the
pipe_resource, which is used to communicate, for instance, whether
sRGB encode should be enabled in the resolve operation or not.
Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB
is disabled.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
| |
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
It manifests at exit as:
"WARNING: destroying GPU memory cache with some buffers still in use"
|
|
|
|
|
|
|
|
|
| |
I tried to update all the old Makefiles that included the default
config to be sure they had a default target if they didn't previously
have one, since this new all target will always point at it. Almost
everything had one.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
...and create common function for destroying nouveau_context
|
|
|
|
| |
Can save about 200 bytes of command buffer space.
|
| |
|
|
|
|
| |
Looks like only 128-bit access doesn't work.
|
|
|
|
| |
Fixes, for instance, object highlighting in Diablo 3 (wine).
|
| |
|
| |
|
| |
|
|
|
|
| |
And restructure VBO validation a little in the process.
|
| |
|
| |
|
|
|
|
| |
Nothing uses it now.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/docs/source/screen.rst
src/gallium/drivers/nv50/nv50_state.c
src/gallium/include/pipe/p_defines.h
src/mesa/state_tracker/st_draw.c
|
| |
| |
| |
| | |
This reduces CPU overhead when updating constants.
|
| |
| |
| |
| |
| |
| |
| | |
Adapted drivers: i915, llvmpipe, r300, r600, radeonsi, softpipe.
User index buffers have been disabled in nv30, nv50, nvc0 and svga to keep
things working.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reduces CPU overhead in st_draw_vbo and removes a lot of unnecessary code
in that function which was required only to comply with the gallium interface,
but wasn't any useful really.
Adapted drivers: i915, llvmpipe, r300, softpipe.
No changes required in: r600, radeonsi.
User vertex buffers have been disabled in nv30, nv50, nvc0 and svga to keep
things working.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is required for any serious constant buffer support.
Constant buffer offsets on ATI and NVIDIA DX10 and DX11 GPUs must be
a multiple of 256.
In OpenGL, this can be queried via GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT.
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
Cannot sample depth/stencil with a single view, and needed to use
different shader code for nve4.
|
| |
|
|
|
|
|
| |
Don't really know what they are yet but for groups of textures, the
last one should use mode "p" and the others "t".
|
| |
|
|
|
|
|
| |
Put them before first uses instead of right after the texturing
instruction and cull unnecessary barriers.
|
| |
|