Now AlphaFunc avoids the blend state update in st/mesa and avoids
_mesa_update_state_locked.
The GL_ALPHA_TEST enable won't trigger blend state updates in st/mesa
after st/mesa stops relying on _NEW_COLOR.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
just don't set _NEW_VARYING_VP_INPUTS.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
not used
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Not needed and we get to bypass _mesa_update_state_locked that would be
a no-op.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
There is plenty of legacy stuff here.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
These are only used in the GL compatibility profile.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
st/mesa doesn't need the draw bounds for draw calls. I've added the call
where it's necessary in core Mesa and drivers, but I suspect that most
drivers can just move the call to the right places.
The core Mesa places aren't hot paths, so the call overhead doesn't matter
there.
For now, only st/mesa is made such that this function is invoked very
rarely.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
For the default framebuffer, _mesa_resize_framebuffer updates it.
For FBOs, _mesa_test_framebuffer_completeness updates it.
This code is redundant.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The idea is to remove the dependency on _mesa_update_state_locked,
so that st/mesa can skip it for stencil state updates, and then stop
setting _NEW_STENCIL in mesa/main if the driver is st/mesa.
The main motivation is to stop invoking _mesa_update_state_locked for
certain state groups.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
_mesa_update_state will no longer recompute Width/Height if the framebuffer
is complete. We now rely on the FBO completeness check to do it.
The only code that needs to be fixed seems to be this one.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
These locks were added in 2f28a0dc, but I don't see anything in the
intel_miptree_blit path that should make this necessary.
When asked, Kristian says:
I doubt it's needed now with the new blorp. If I remember correctly,
I had to drop the lock there since intel_miptree_blit() could hit
the XY blit path that requires a fast clear resolve. The fast
resolve being meta, would then try to lock the texture again.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Same as the previous commit, but this one was split out because it's
a bit more complicated: this field is given as a pointer to a function,
so the function had to be changed as well, and the function was use in
a bunch of places, which needed updating as well.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In newer gens, this field has a prefix and the non-IEEEE-745 mode is called
"Alternate", instead of simply "Alt".
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On gen6+, this is called "Dispatch GRF Start Register For Constant/Setup Data
0", while on gen5 and lower it's called only "Dispatch GRF Start Register For
URB Data", but it's essentially the same thing (URB data), so rename it to
match newer gens and simplify the C code that handles it.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
"Pixel Shader Kill Pixel" -> "Pixel Shader Kills Pixel", which is how it's
called on newer gens.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On gen4, WM_STATE only has one Kernel Start Pointer and one GRF Register
Count, but we can make the code that handles this on multiple gens simpler if
we add an index 0 to it too.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Just because it's not set doesn't mean that it doesn't exist. And since the
field is there on newer gens, having it on gen5 simplifies the code when
porting gen5 and lower.
Also add missing value to API Mode on CLIP_STATE on gen4.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a bitmask, so it can't be a boolean. Also rename it so it matches
gen6+.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These fields are set by brw_clip_unit, so we need them when converting to
genxml.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Rename "Rendering Enable" to "Rendering Enabled", so it matches gen6+.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Unlike the older gen2 hardware, gen3 performs perspective
correct interpolation even for the primary/secondary colors.
To do that it naturally needs us to emit W for the vertices.
Currently we emit W only when at least one texture coordinate
set gets emitted. This means the interpolation of color will
change depending on whether texcoords/varyings are used or not.
That's probably not what anyone would expect, so let's just
always emit W to get consistent behaviour. Trying to avoid
emitting W seems like more hassle than it's worth, especially
as bspec seems to suggest that the hardware will perform the
perspective division anyway.
This used to be broken until it was accidentally fixed it in
commit c349031c27 ("i915: Fix texcoord vs. varying collision
in fragment programs") by introducing a bug that made the driver
always emit W. After fixing that bug in commit c1eedb43f3
("i915: Fix wpos_tex vs. -1 comparison") we went back to the
old behaviour and caused an apparent regression.
Fixes: c1eedb43f3 ("i915: Fix wpos_tex vs. -1 comparison")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101451
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Same as with the colormasks, the blend color needs to be swizzled according
to the rendertarget format.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Reviewed-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Doom shipped with a broken version of GLSLang which handles samplers as
function arguments in a way that isn't spec-compliant. In particular,
it creates a temporary local sampler variable and copies the sampler
into it. While Dave has had a hack patch out for a while that gets it
working, we've never landed it because we've been hoping that a game
update would come out with fixed shaders. Unfortunately, no game update
appears on to be on the horizon and I've found this issue in yet another
application so I think we're stuck working around it. Hopefully, we can
delete this code one day.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99467
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Previously, texture formats were being used unconditionally without
checking. However nv30 supports neither RGBX8 nor R4A4/A4R4 formats. Add
sufficient fallbacks so that the nv30 driver can have working OSD.
Tested on a NV44A/PCI.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
By treating the rectangles as 1cpp, we can run up against some internal
copy engine limits and trigger a MEM2MEM_RECT_OUT_OF_BOUNDS error check
at launch time.
This commit enables the REMAP hardware, which allows us to specify both
the component size and number of components for a transfer. We're then
able to pass in the real width/nblocksx values and not hit the limits.
There's a couple of "supported" CPPs in the list that we can't actually
hit, but are there simply because they're possible.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Aside from reducing pushbuf usage in some situations, this commit should
have no other effect, and is just to make it somewhat obvious that those
methods have zero effect on linear surfaces.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
I just noticed a warning with a non-debug build, but really
this could all be one line, and I'm not even 100% the assert
makes sense here.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In 5f2fe9302c is_geminilake was introduced for the differenciate
broxton from geminilake. Unfortunately I failed as verifying that
is_broxton is throughout the code base to mean Gen9lp.
Fixes: 5f2fe9302c ("intel: common: add flag to identify platforms by name")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
