| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour should match what libdrm_nouveau does closely.
- The solution remains statically sized, but when debugging is on it will check
for abuse.
Signed-off-by: Maarten Maathuis <[email protected]>
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
src/gallium/drivers/identity/id_context.c
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently in nvXX_transfer_new a temporary as large as the surface is created.
If the subrectangle is not the whole texture we would need to read
back the whole texture, but we aren't.
Thus, everything but the subrectangle specified is loaded as garbage.
This can be seen in progs/demos/ray.
This patch fixes the problem by creating a temporary that covers only
the desired subrectangle.
That makes us hit an alignment assert in nv04_surface_2d.c. Fix it
using the point registers instead of manipulating the swizzled surface
offset to account for the destination coordinates (which do not seem
to have a 1024 limit).
Signed-off-by: Francisco Jerez <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
- unreference state objects so that buffer objects are unreferenced and
eventually destroyed
- free channel at screen's destruction
Based on Krzysztof Smiechowicz's patch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I just coded a patch that does this and seems to work fine. It must be
fixed since it breaks OpenGL (or the state tracker can be changed, but
it seems better to do it in the driver).
The patch also fixes NV20 and NV30 in the same way. They compile but
are untested.
I would guess that using the 3D engine is faster for the larger
levels, but the 2D engine is faster for the smaller ones (and lacks
this issue).
|
| | |
|
|\ \
| |/
|/|
| |
| | |
Conflicts:
src/mesa/state_tracker/st_draw.c
|
| |
| |
| |
| |
| | |
several drivers which chose to ignore edgeflags might require some more work,
while edgeflags never worked there they might now crash.
|
|/
|
|
|
| |
Previously they depended on format blocks, but after removing those
they started depending on format encoding.
|
| |
|
|
|
|
|
|
| |
Thanks to Bob Gleitsmann for the patch.
I'll clean this up in a better way later if noone else beats me to it.
|
|\
| |
| |
| |
| | |
Conflicts:
src/gallium/state_trackers/xorg/xorg_exa.c
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
src/gallium/drivers/r300/r300_vs.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
SrcRegister -> Register
SrcRegisterInd -> Indirect
SrcRegisterDim -> Dimension
SrcRegisterDimInd -> DimIndirect
|
| | |
| | |
| | |
| | |
| | | |
DstRegister -> Register
DstRegisterInd -> Indirect
|
| | |
| | |
| | |
| | | |
DeclarationRange -> Range
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
InstructionPredicate -> Predicate
InstructionLabel -> Label
InstructionTexture -> Texture
FullSrcRegisters -> Src
FullDstRegisters -> Dst
|
| | |
| | |
| | |
| | |
| | | |
Rename Semantic.SemanticName to Semantic.Name. Similar for
SemanticIndex, and the members of the tgsi_version struct.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It would be nice if these drivers built under the linux-debug header
so that these types of interface changes can be minimally propogated
into those drivers by people without the hardware. They don't have to
generate a working driver -- though a command-dumping winsys would be
an excellent for regression checking.
|
| |/
|/| |
|
|/
|
|
| |
width/height/depth arrays
|
|
|
|
|
| |
Signed-off-by: Francisco Jerez <[email protected]>
Signed-off-by: Pekka Paalanen <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
No longer used. S3TC support is queried via
pipe_screen::is_format_supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
libdrm_nouveau is linked with the winsys, there's no good reason to do all
this through yet another layer.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
I should have gotten most uses and implementation
correctly fixed, but things might break.
Feel free to blame me.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core reference counting code is centralized in p_refcnt.h.
This has some consequences related to struct pipe_buffer:
* The screen member of struct pipe_buffer must be initialized, or
pipe_buffer_reference() will crash trying to destroy a buffer with reference
count 0. u_simple_screen takes care of this, but I may have missed some of
the drivers not using it.
* Except for rare exceptions deep in winsys code, buffers must always be
allocated via pipe_buffer_create() or via screen->*buffer_create() rather
than via winsys->*buffer_create().
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The template makefile that most libraries in
gallium included was based on dri and had a bunch
unrelevant junk in it.
Update it and improve the depending makefiles.
|
|\ |
|
| | |
|
|/
|
|
|
| |
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
| |
|