| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
PIPE_BUFFER_USAGE_DISCARD flag now exists.
|
|
Based on patch by Chia-I Wu <olvaffe@gmail.com>
Expose the name of the kernel driver as accepted by drmOpenByName.
|
|
Fixes gnome-shell on nouveau, as well as window resize with various
other applications.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
There is little point in having a special TGSI token just to handle
predicate register updates. Remove tgsi_dst_register_ext_predicate token
and instead use a new PREDICATE register file to update predicates.
Actually, the contents of the obsolete token are being moved
to tgsi_instruction_ext_predicate, where they should be
from the very beginning.
Remove the NVIDIA-specific condition code tokens -- nobody uses them
and they can be emulated with predicates if needed.
Introduce PIPE_CAP_SM3 that indicates whether a driver supports
SM3-level instructions, and in particular predicates.
Add PIPE_CAP_MAX_PREDICATE_REGISTERS that can be used to query the driver
how many predicate registers it supports (currently it would be 1).
|
|
It's really just another define. No need for its own header.
|
|
Likewise, the extended negate functionality hasn't been
used since mesa switched to using tgsi_ureg to build programs,
and has been translating the SWZ opcode internally to a single MAD.
|
|
These haven't been used by the mesa state tracker since the
conversion to tgsi_ureg, and it seems that none of the
other state trackers are using it either.
This helps simplify one of the biggest suprises when starting off with
TGSI shaders.
|
|
Provide a dummy implementation in the GL state tracker (move 0.5 to
the destination regs).
At some point, a motivated person could add a better
implementation of noise. Currently not even the nvidia
binary drivers do anything more than this. In any case, the
place to do this is in the GL state tracker, not the poor
driver.
|
|
Uf. Lots of files touched. Would people with working vega, xorg, dri1, etc.
please make sure you are not broken, and fix yourself up if you are.
There were only two or three places where the code did not have painful
fallbacks, so I would advise st maintainers to find less painful workarounds,
or consider overhauling util_surface_copy and util_surface_fill.
Per ymanton, darktama, and Dr_Jakob's suggestions, clear has been left as-is.
I will not add PIPE_CAP_BLITTER unless it is deemed necessary.
|
|
|
|
Asks the driver to map the texture storage directly or return NULL if that's
not possible.
|
|
Always test for PIPE_TRANSFER_READ/WRITE using the bit-wise and operator, and
add a pipe_transfer_buffer_flags() helper for getting the buffer usage flags
corresponding to them.
|
|
|
|
Interface is pipe_video_context::set_csc_matrix().
vl_csc.h defines some helpers to generate CSC matrices based on one of
the color standard and a user defined ProcAmp (brightness, contrast,
saturation, hue).
|
|
Since the various BSDs use some different features here,
define PIPE_OS_OPENBSD and PIPE_OS_NETBSD as well
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
This was redundant as drivers can just keep track of whether they are
inside a begin/end query pair. We want to add more query types later
and also support nested queries, none of which map well onto a flag like
this. No driver appeared to be using the flag.
|
|
|
|
|
|
gcc 4.4 seems particularly picky with int -> enum conversions.
|
|
|
|
|
|
|
|
No longer used. S3TC support is queried via
pipe_screen::is_format_supported.
|
|
|
|
|
|
|
|
|
|
|
|
Mac OS also has POSIX threads.
|
|
|
|
Can be implemented with CMP src2, src1, src0
|
|
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
|
