Age | Commit message (Collapse) | Author |
|
nouveau_vieux_dri.so.tmp: undefined reference to `_mesa_need_secondary_color'
|
|
r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled'
|
|
|
|
|
|
|
|
|
|
This gets one more piece of the pipeline onto the new codegen backend.
Once ARB_fragment_program can generate GLSL programs, we can nuke the
old backend.
|
|
This is like how we track FragmentProgram._Current for the computed
ARB fragment program for fixed function texenv, but this gives direct
access to the gl_shader_program for drivers to codegen from, skipping
ARB_fp.
|
|
This is a step towards providing a direct route for drivers accepting
GLSL IR for codegen. Perhaps more importantly, it runs the fixed
function fragment program through the GLSL IR optimization. Having
seen how easy it is to make ugly fixed function texenv code that can
do unnecessary work, this may improve real applicatinos.
|
|
It would be nice if we handled optimized uniform math like this in
some generic way, since people often end up doing uniform expressions
in shaders, but for now keep this hard-coded like it was in the
texenvprogram code.
|
|
For fixed function fragment processing in GLSL IR, we want to be able
to reference this state value. gl_* not explicitly permitted is
reserved, so using this variable name internally shouldn't be any
issue.
|
|
This file is about to change to generating a shader program instead of
a fragment program.
|
|
This is used in the upcoming fixed function shader_program generation,
and shader_program and ARB programs are together in this code until
both fragment and vertex ff get converted.
|
|
It fails on assertions if the key isn't actually present.
|
|
|
|
The drivers have been changed so that they behave as if all of the flags
were set. This is already implicit in most hardware drivers and required
for multiple contexts.
Some state trackers were also abusing the PIPE_FLUSH_RENDER_CACHE flag
to decide whether flush_frontbuffer should be called.
New flag ST_FLUSH_FRONT has been added to st_api.h as a replacement.
|
|
|
|
So that they don't have the driver-specific param and return type.
|
|
Only st/xorg used it and even incorrectly with regards to pipelined transfers.
|
|
Without this, EXT_texture_from_pixmap is trivially broken. With it,
it's merely subtly broken.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Since we're compiling/linking GLSL shaders we should check against
the shader uniform limits, not the legacy vertex/fragment program
parameter limits which are usually lower.
|
|
The gl_program_constants struct is for limits that are applicable to
any/all shader stages. Move the geometry shader-only fields into the
gl_constants struct.
Remove redundant MaxGeometryUniformComponents field too.
|
|
Without these checks we could create shaders with more samplers,
constants than the driver could handle. Fail linking rather than
dying later.
|
|
and rename them.
|
|
Need to flush rendering (or at least indicate that the rug might be getting
pulled out from underneath us) when a shader, buffer object or query object
is about to be deleted.
Also, this helps to tell the VBO module to unmap its current vertex buffer.
|
|
|
|
DMAs.
|
|
upload->offset is how much we used. upload->size is the whole buffer size.
|
|
With 3 pipes cards we need to align with NPOT values. This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=32945
Signed-off-by: Nicolas Peninguy <nico@lostgeeks.org>
|
|
|
|
I don't see a reason we need them.
|
|
The framebuffer cache flush should be implicit when calling
set_framebuffer_state.
There is no need to flush the command stream either.
|
|
This reverts commit 6d4e337f3890105c7d8a2f132412c137d2570d25.
The commit is incorrect. I'll rework it. Revert for now.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Tested by temporarily using util_clear even when not using the blitter.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
u_blitter is lazy and doesn't fully clear it's stack-allocated fb.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Benefits:
- spares us a relocation.
- needed for zone rendering (if that ever happens).
- just awesome.
v2: Rename the debug option. Completely disabling the blitter is
required for Y tiling to work, so this option will cover other
code paths in the future.
v3: Implement suggestions by Jakob Bornecrantz.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No need to assert.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Flushing the batch/hw backend doesn't invalidate the derived state.
So kill the unnecessary function calls and add an assert in
emit_hardware_state for paranoia.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
With the new clear code this is possible (if the app call glClear
before drawing the first primitive).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The polygon stipple fallback does not have to be implemented in the
draw module (it doesn't need window coords, etc). Drivers can use
this utility and avoid sw vertex fallbacks if pstipple is enabled.
Note: this is WIP and not used by any driver yet.
|
|
|
|
The gc var would be NULL if called from line 238. Instead, get
the opcode from __glXSetupForCommand(dpy) as done in other places.
And remove the unused gc parameter.
Fixes a bug reported by "John Doe" on 3/9/2011.
NOTE: This is a candidate for the 7.10 branch.
|
|
Make sure we only upload parts of vertex arrays that are actually used
by a draw command.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
This fd gets passed in from outside, closing it causes the X.org server
to crap out when the driver doesn't identify the chipset.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This is an expected behavior when we're testing for the presence of
new kernel features.
|
|
Improves performance of a hacked-up scissor-many (to reuse a small set
of scissors instead of blowing out the cache, and then to run 100x
more iterations so it actually took some time) by 3.6% +/- 1.2% (n=10)
|
|
Got lost in f80c03e1875fe96ff2f4c022e3cb76357828140d.
|
|
|
|
Reviewed-by: Henri Verbeet <hverbeet@gmail.com>
|