| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Trivial.
|
|\
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| | |
It's not common to end up in u_vbuf and at the same time support user buffers
in a driver, but such a combination should work.
|
| | |
|
| |
| |
| |
| | |
so that it's installed in the other state trackers too
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
For consistency.
Reviewed-by: Brian Paul <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some code relies on the existing of an invalid texture target. It seems
safer to bring it back than to deal with unintended consequences.
This partially reverts commit a4ebb04214bab1cd9bd41967232ec89441e31744.
Reviewed-by: Brian Paul <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The goal is to have a uniform interface to create winsys and
pipe_screen instances for any driver, exposing the device enumeration
capabilities that might be supported by the operating system (for now
there's a "drm" back-end using udev and a "sw" back-end that always
returns the same built-in devices).
The typical use case of this library will be:
>
> struct pipe_loader_device devs[n];
> struct pipe_screen *screen;
>
> pipe_loader_probe(&devs, n);
>[pick some device from the array...]
>
> screen = pipe_loader_create_screen(dev, library_search_path);
>[do something with screen...]
>
> screen->destroy(screen);
> pipe_loader_release(&devs, N);
>
A part of the code was taken from targets/gbm/pipe_loader.c, which
will be removed and replaced with calls into this library by a future
commit.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Structured branch instructions like IF, ELSE, BGNLOOP, ENDLOOP no
longer require a label argument, make it optional for them.
|
| | |
|
| |
| |
| |
| | |
UREG_MAX_TEMP.
|
| |
| |
| |
| | |
Reviewed-by: Jakob Bornecrantz <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change will be useful to implement function parameter passing on
top of TGSI. As we don't have a proper stack, a register-based
calling convention will be used instead, which isn't necessarily a bad
thing given that GPUs often have plenty of registers to spare.
Using the same register space for local temporaries and
inter-procedural communication caused some inefficiencies, because in
some cases the register allocator would lose the freedom to merge
temporary values together into the same physical register, leading to
suboptimal register (and sometimes, as a side effect, instruction)
usage.
The LOCAL declaration modifier specifies that the value isn't intended
for parameter passing and as a result the compiler doesn't have to
give any guarantees of it being preserved across function boundaries.
Ignoring the LOCAL flag doesn't change the semantics of a valid
program in any way, because local variables are just supposed to get a
more relaxed treatment. IOW, this should be a backwards-compatible
change.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Define a new STORE opcode with a role dual to the LOAD opcode, and add
flags to specify that a shader resource is intended for writing.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Normal resource access (e.g. the LOAD TGSI opcode) is supposed to
perform a series of conversions to turn the texture data as it's found
in memory into the target data type.
In compute programs it's often the case that we only want to access
the raw bits as they're stored in some buffer object, and any kind of
channel conversion and scaling is harmful or inefficient, especially
in implementations that lack proper hardware support to take care of
it -- in those cases the conversion has to be implemented in software
and it's likely to result in a performance hit even if the pipe_buffer
and declaration data types are set up in a way that would just pass
the data through.
Add a declaration flag that marks a resource as typeless. No channel
conversion will be performed in that case, and the X coordinate of the
address vector will be interpreted in byte units instead of elements
for obvious reasons.
This is similar to D3D11's ByteAddressBuffer, and will be used to
implement OpenCL's constant arguments. The remaining four compute
memory spaces can also be understood as raw resources.
|
| |
| |
| |
| |
| |
| | |
This texture type was already referred to by the documentation but it
was never defined. Define it as 0 to match the pipe_texture_target
enumeration values.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Move Interpolate, Centroid and CylindricalWrap from tgsi_declaration
to a separate token -- they only make sense for FS inputs and we need
room for other flags in the top-level declaration token.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit splits the current concept of resource into "sampler
views" and "shader resources":
"Sampler views" are textures or buffers that are bound to a given
shader stage and can be read from in conjunction with a sampler
object. They are analogous to OpenGL texture objects or Direct3D
SRVs.
"Shader resources" are textures or buffers that can be read and
written from a shader. There's no support for floating point
coordinates, address wrap modes or filtering, and, unlike sampler
views, shader resources are global for the whole graphics pipeline.
They are analogous to OpenGL image objects (as in
ARB_shader_image_load_store) or Direct3D UAVs.
Most hardware is likely to implement shader resources and sampler
views as separate objects, so, having the distinction at the API level
simplifies things slightly for the driver.
This patch introduces the SVIEW register file with a declaration token
and syntax analogous to the already existing RES register file. After
this change, the SAMPLE_* opcodes no longer accept a resource as
input, but rather a SVIEW object. To preserve the functionality of
reading from a sampler view with integer coordinates, the
SAMPLE_I(_MS) opcodes are introduced which are similar to LOAD(_MS)
but take a SVIEW register instead of a RES register as argument.
|
| |
| |
| |
| |
| |
| | |
Reimplemented by Olivier Galibert <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Vadim Girlin <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The signal.h include was missed in the commit
bc16c73407d11bb6702cf7de9925bfaeb80a5272 which leads to broken
compilations under Linux.
Signed-off-by: José Fonseca <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
So that its output can be seen on GUI window apps.
Tested-by: James Benton <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
| |
| |
| |
| | |
Brittle, complex, and unecesary. Just use function pointer constant.
|
| |
| |
| |
| | |
To be reused in all places where we want to call C code.
|
| |
| |
| |
| |
| |
| |
| | |
- Move to lp_bld_const where it belongs
- Rename to lp_build_const_string
- take the length from the argument (and don't count the zero terminator twice)
- bitcast the constant to generic i8 *
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows the creation of const aos masks which have the mask swizzled
to match the correct format.
Updated existing mask creation code to use the swizzled version where
necessary (tgsi register masks and llvmpipe aos blending).
Signed-off-by: José Fonseca <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
unsigned ints
This is useful for debugging the linear llvm path as it handles pixels in this format
Signed-off-by: José Fonseca <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: José Fonseca <[email protected]>
|
| |
| |
| |
| |
| | |
Reviewed-by: José Fonseca <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: José Fonseca <[email protected]>
|
| | |
|
|/
|
|
| |
on entry, rather than condition check on loop
|
| |
|
| |
|
|
|
|
|
|
|
| |
To ensure that the alloca is at the top of the function body, otherwise
LLVM will not eliminate them, causing stack misalignment on 32bits.
Reviewed-by: James Benton <[email protected]>
|
| |
|