| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Most use cases just got the buffer from the texture
and then called into one of the get_handle functions.
Also with this patch it would be easier to move to a
generic function for getting handles from textures
and textures from handles, that is exposed via the screen.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This prevents the driver from discarding a buffer when the whole buffer
is mapped for writing, but only a portion is effectively written.
This is a temporary fix, because WRITE shouldn't imply DISCARD.
The full fix implies using PIPE_BUFFER_USAGE_DISCARD, throughout
the code, and will go only into master.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
We need aditional meta data about the usage of the surface
in softpipe because we need to be able tell the diffrence
between PRIMARY and DISPLAY_TARGET surfaces.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The LOOP/ENDLOOP pair is renamed to BGNFOR/ENDFOR as its behaviour
is similar to a C language for-loop.
The BGNLOOP2/ENDLOOP2 pair is renamed to BGNLOOP/ENDLOOP as now
there is no name collision.
|
| |
| |
| |
| |
| |
| |
| | |
The only valid usage for LOOP/ENDLOOP instructions
is LOOP[0] as a destination register.
The only valid usage for the remaining instructions
is LOOP[0].x as an indirect register.
|
| |
| |
| |
| |
| |
| | |
Remove commented-out opcodes. Remove information about API mappings
to opcodes, but add a reference to tgsi-instruction-set.txt where
that information is better presented.
|
| |
| |
| |
| |
| |
| | |
Various opcodes which can be implemented trivially with other TGSI opcodes,
such as matrix multiplication and negation. These were not used by any
state tracker or implemented by any of the drivers.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a source of ongoing confusion. TGSI has multiple names for
opcodes where the same semantics originate in multiple shader APIs.
For instance, TGSI includes both Mesa/GLSL and DX/SM30 names for
opcodes with the same semantics, but aliases those names to the same
underlying opcode number.
This makes it very difficult to visually inspect two sets of opcodes
(eg in state tracker & driver) and check if they implement the same
functionality.
This patch arbitarily rips out the versions of the opcodes not currently
favoured by the mesa state tracker and leaves us with a single name
for each distinct operation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free the data pointed to, uncertainty
about who owns the data, etc. There doesn't seem to be a need for it,
and it is unlikely to make much difference plus or minus to performance.
Added some asserts as we now will trip up on immediates with more
than four elements. There were actually already quite a few such asserts,
but the >4 case could be used in the future to specify indexable immediate
ranges, such as lookup tables.
|
| |
| |
| |
| | |
default extension list
|
| | |
|
| |
| |
| |
| | |
plus it saves us a cacheline in the cso
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
mesa allocates both frontface and pointcoord registers within the fog
coordinate register, by using swizzling. to make it cleaner and easier
for drivers we want each of them in its own register. so when doing
compilation from the mesa IR to tgsi allocate new registers for both
and add new semantics to the respective declarations.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
buffer_flush_mapped_range.
When a buffer was mapped for write and no explicit flush range was provided
the existing semantics were that the whole buffer would be flushed, mostly
for backwards compatability with non map-buffer-range aware code.
However if the buffer was mapped/unmapped with nothing really written --
something that often happens with the vbo -- we were unnecessarily assuming
that the whole buffer was written.
The new PIPE_BUFFER_USAGE_FLUSH_EXPLICIT flag (based from ARB_map_buffer_range
's GL_MAP_FLUSH_EXPLICIT_BIT flag) allows to clearly distinguish the
legacy usage from the nothing written usage.
|
| |
| |
| |
| |
| |
| |
| | |
This was only present for the sake of GL_ARB_shadow_ambient which we
never implemented in Gallium. If we someday want GL_ARB_shadow_ambient
we can implement it in the state tracker by adding a MAD after the
relevant TEX instructions.
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/api_validate.c
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
progs/util/extfuncs.h
|
| |
| |
| |
| |
| |
| | |
3f2e006b759705abd7c409d30f9aeb1f2a75b83f
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|\| |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/state_tracker/st_cb_fbo.c
src/mesa/state_tracker/st_framebuffer.c
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
| |
that a driver needs to implement on top of the drm api to support dri1.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
|
|
|
|
| |
Make it possible to pass state-tracker-specific data to the
init_screen function, and even open the door for device-specific
state-tracker screen initialization.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
| |
|
| |
|
| |
|
|
|
|
| |
Cleaner than the previous cleanup...
|
|
|
|
| |
Some builds end up picking this up.
|
|
|
|
|
|
|
| |
Also implement context member functions to optimize away those
flushes whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
|
| |
The format field encodes compressed vs. uncompressed already. We can easily
check if a texture is compressed with pf_is_compressed(texture->format).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Only allows clearing currently bound buffers, but colour and depth/stencil in
a single call.
|