| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This avoids the massive conditional move array access, and brings code
generation quality for the new VS backend into the realm of efficiency
of the old backend (roughly 20% more instructions generated than
before across shader-db, instead of assertion failing for generating
over 10,000 instructions on many shaders!).
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
v2: reworked the instruction emit and made use of gen6_resolve_implied_move,
from Ken's review
|
|
|
|
|
|
| |
We sometimes want to put an instruction somewhere besides the end of
the instruction stream, and we also want per-opcode instruction
generation to enable compile-time checking of operands.
|
|
|
|
|
|
|
| |
We'll be using that to track things for the new VS backend, and this will
avoid cluttering brw_vs_surface_state.c for it.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were primarily failing to convert in the NativeIntegers case, which
this fixes. However, we were also just truncating float uniforms when
converting to integer, which does not appear to be the correct
behavior. Note, however, that the NVIDIA drivers also truncate
instead of rounding.
GL_DOUBLE return type is dropped because it was never used and
completely broken. It can be added when there's test code.
Fixes piglit ARB_shader_objects/getuniform
v2: This is a rewrite of my previous glGetUniform patch, which Ken
pointed out missed storage_type-based conversions to integer,
which was totally broken still thanks to a typo in the testcase.
v3: Quote the spec justifying the rounding behavior.
Acked-by: Kenneth Graunke <[email protected]>
Acked-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
At least for Intel, all our uniform components are of uint32_t size, either
float or signed or unsigned int. For uploading uniform data in the driver,
it's much easier to upload a full dword per uniform element instead of trying
to pick out the bool byte and then fill in the top 3 bytes of pad with 0.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Compile tested only.
Reviewed-by: Chia-I Wu <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Replace each occurence of
#include "../glsl/*.h"
with
#include "glsl/*.h"
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
libmesa_dri_common is a static library that contains the sources in
src/mesa/drivers/dri/common. Each DRI driver should link to it.
Reviewed-by: Chia-I Wu <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
In src/mesa/Android.mk, it is non-trivial to determine which variables are
imported by `include sources.mak`. So document them.
Reviewed-by: Chia-I Wu <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
libmesa_dricore.a is analogous to the libmesa.a built by the Autoconf
build.
Reviewed-by: Chia-I Wu <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Commit 2ea1ff38164d95f8291ef2e5dfe2cb13936a60f2 caused the regression.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40413
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order that the Autoconf and Android build can share the same source
lists, move the lists from
src/mesa/drivers/dri/Makefile.defines
into
src/mesa/drivers/dri/common/Makefile.sources
I would like for Android to just reuse Makefile.defines, but the file is
unsuitable for reuse.
Reviewed-by: Chia-I Wu <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
driverfuncs.o is already contained in libmesa.a, so remove it from the
following source lists:
src/mesa/drivers/dri/Makefiles.defines:COMMON_SOURCES.
src/mesa/drivers/dri/swrast/Makefile:SWRAST_COMMON_SOURCES
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Remove defintion of COMMON_SOURCES from {r300,r660}/Makefile. The
defintion is a duplicate of that found in
src/mesa/drivers/dri/Makefile.defines.
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
The layersize calculation is slightly different on +evergreen.
This makes mpeg2 video decoding and piglits texture-packed-formats
test work correctly on this hardware.
|
| |
|
|
|
|
|
| |
Should get rid of "destroying GPU memory cache with some buffers
still in use" message.
|
|
|
|
|
|
|
|
| |
I noticed that a thread was created for every time async flush was called, so I moved it and used some semaphores to synch.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Christian König <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
Will round to nearest-even.
|
|
|
|
|
|
| |
This prevents null dereferences in validation of interdependent
state after a switch to a pipe context where we mark all state
as dirty but where not all state is valid / set yet.
|
|
|
|
|
|
| |
The window system buffer will be BGRA and applications will try to
directly resolve to it, which would trigger an INVALID_OPERATION in
BlitFramebuffer if the multisample renderbuffer is RGBA.
|
|
|
|
| |
A change in sampleBuffers affects the final enable value.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Totally broken, and deprecated by scons.
|
|
|
|
| |
Mingw-w64 actually seems to be closer to MSVC in terms of .DEF parsing.
|
|
|
|
| |
Which already declares wglSwapMultipleBuffers and WGLSWAP.
|
|
|
|
|
|
|
|
| |
All commonly used windows toolchains define wgl entrypoints in the windows
headers, and mesa_wgl.h not only is unnecessary but actually often stands
in the waydue to slight inconsistencies.
So remove it.
|
|
|
|
|
| |
This allows to use mingw-w64 binaries on debian systems which already
include a (typically incomplete) 64 cross compiler.
|
|
|
|
|
|
| |
The nouveau xvmc decoder doesn't need it.
Signed-off-by: Maarten Lankhorst <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of vec4_visitor::try_rewrite_rhs_to_dst to fs_visitor.
Not only is this technique less invasive and more robust, it also
generates better code. Over and above the previous technique, this
reduced instruction count in shader-db by 0.28% on average and 1.4% in
the best case.
In no case did this technique result in more code than the prior method.
Signed-off-by: Kenneth Graunke <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 53c89c67f33639afef951e178f93f4e29acc5d53, along with
the subsequent this->result = reg_undef additions it required.
Both Eric and I agree that the way he did this is really fragile; if you
forget to add this->result = reg_undef before calling accept(), it may
end up using the same register for two separate things, breaking things
in strange and mysterious ways.
The next commit will port over the new VS backend's method for solving
this problem, which is simpler, less intrusive, and still manages to
avoid MOVs in the common case.
|
|
|
|
|
|
|
|
|
|
|
| |
Nothing in Mesa supports color-index textures, and most of the other
infrastructure that could allow such support has already been removed.
This puts the final nail in the coffin.
Also clean out some GL_COLOR_INDEX comments in formats.c.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This came from the "kill it with fire" discussion at XDS 2010.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
It uses MapTextureImage() now, so we don't need our own mapping.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Now that Mesa core knows how to map teximages, we no longer needed the
compressed paths here.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
This continues to allocate texImage->Data as before, so
drivers calling these functions need to use that when present.
Reviewed-by: Brian Paul <[email protected]>
|