| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Acked-by: Daniel Stone <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We have a persistent mapping. Don't map it a second time or try to
unmap it. Just use the pointer.
This most likely would wreak havoc except that this code is unused
(it's only called from an if (0) debug block).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eduardo Lima Mitev <[email protected]>
|
|
|
|
|
|
|
|
| |
It makes sense to put a function which prints out the entire contents
of the program cache in the file that implements the program cache.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eduardo Lima Mitev <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We had five copies of the same "walk the cache and look for an
existing shader variant for this program" code. Now we have one
helper function that returns the key.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eduardo Lima Mitev <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Co-authored by Matt Turner.)
Image atomics, for example, return a value - but the shader may not
want to use it. We assigned a useless VGRF destination. This seemed
harmless, but it can actually be quite harmful. The register allocator
has to assign that VGRF to a real register. It may assign the same
actual GRF to the destination of an instruction that follows soon after.
This results in a write-after-write (WAW) dependency, and stall.
A number of "Deus Ex: Mankind Divided" shaders use image atomics, but
don't use the return value. Several of these were hitting WAW stalls
for nearly 14,000 (poorly estimated) cycles a pop. Making dead code
elimination null out the destination avoids this issue.
This patch cuts one shader's estimated cycles by -98.39%! Removing the
message response should also help with data cluster bandwidth.
On Skylake:
(instruction counts remain identical)
total cycles in shared programs: 255413890 -> 248081010 (-2.87%)
cycles in affected programs: 12019948 -> 4687068 (-61.01%)
helped: 24
HURT: 10
v2: Make can_omit_write independent of can_eliminate (Curro).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In theory we might have incorrectly NOP'd instructions that write the
flag, but where that flag value isn't used, and yet the instruction
either writes the accumulator or has side effects.
I don't believe any such instructions exist, so this is mostly a
code cleanup.
Curro pointed out that FS_OPCODE_FB_WRITE has a null destination and
actually writes the flag on Gen4-5 to dynamically decide whether to
write some payload data. The hunk removed in this patch might have
NOP'd it, except that we don't actually mark flags_written() in the
IR, so it doesn't think the flag is touched at all. That's sketchy,
but it means it wouldn't hit this today (though there are likely other
problems!).
v2: Properly replace the inst->regs_written() check in the second
hunk with the flag being live (mistake caught by Curro).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to Matt, the dead code pass explicitly avoided IF and WHILE
because on Sandybridge, these could have conditional modifiers and
null destination registers. Normally, those instructions use BAD_FILE
for the destination register. Nowadays, we don't do that anymore, so
we could technically drop these checks.
However, it's clearer to explicitly leave control flow instructions
alone, so change it to the more generic !inst->is_control_flow().
This should have no actual change.
[This patch implements review feedback from Curro and Matt.]
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This implements support for emitting FBFETCH ops, using the existing
lowering pass for advanced blend logic, and disabling hw blend when
advanced blending is enabled.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
This is so that we can differentiate between flushing any framebuffer
reading caches from regular sampler caches.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
The extension spec is not currently published, so it's a bit premature
to require it for BlendBarrier usage.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
This may fix GPU hangs on Gen8. I don't know if it does though.
Cc: [email protected]
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Everything is in place and the test results look solid.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 7428e6f86ab5 we switched the barrier SEND message's
destination type to UW to avoid problems in SIMD16 compute shaders.
Tessellation control shaders also use barriers, and in vec4 mode, we
were emitting them in align16 mode. The simulator warns that only UD,
D, F, and DF are valid destination types - UW is technically illegal.
So, switch to align1 mode. Either mode should work fine.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes glxgears rendering, which had surprisingly been broken since
late October! Specifically, commit 91d61fbf7cb61a44adcaae51ee08ad0dd6b.
glxgears uses glShadeModel(GL_FLAT) when drawing the main portion of the
gears, then uses glShadeModel(GL_SMOOTH) for drawing the Gouraud-shaded
inner portion of the gears. This results in the same fragment program
having two different state-dependent interpolation maps: one where
gl_Color is flat, and another where it's smooth.
The problem is that there's only one gen4_fragment_program, so it can't
store both. Each FS compile would trash the last one. But, the FS
compiles are cached, so the first one would store FLAT, and the second
would see a matching program in the cache and never bother to compile
one with SMOOTH. (Clearing the program cache on every draw made it
render correctly.)
Instead, move it to brw_wm_prog_data, where we can keep a copy for
every specialization of the program. The only downside is bloating
the structure a bit, but we can tighten that up a bit if we need to.
This also lets us kill gen4_fragment_program entirely!
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reverts 57bab6708f2bbc1ab8a3d202e9a467963596d462, which was
causing issues with ILK and earlier VS programs.
1. brw_nir.c: Revert "i965/vec4/nir: vec4 also needs to remap vs attributes"
Do not perform a remap in vec4 backend. Rather, do it later when
setup attributes
2. brw_vec4.cpp: This fixes mapping ATTRx to proper GRFn.
Suggested-by: Kenneth Graunke <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99391
[[email protected]: merge Juan's two patches from bugzilla]
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the "Gather4 R32G32_FLOAT Bug" internal documentation
page, the R32G32_UINT and R32G32_SINT formats are affected by the
same bug as R32G32_FLOAT. Applying the same workarounds should be
viable - apparently the R32G32_FLOAT_LD format shouldn't corrupt
integer data which is NaN or other sketchy floating point values.
One irritating caveat is that, because it's a FLOAT format, the
alpha channel or any set to SCS_ONE return 0x3f8 (1.0) rather than
integer 1. So we need shader code to whack those channels to 1.
Fixes GL45-CTS.texture_gather.plain-gather-int-cube-rg on Haswell.
v2: Fix swizzle component zeroing (caught by Jordan Justen).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Unused since 0a7691ee (mesa: Enable enums for OES_viewport_array).
Silence a warning of unused variable.
Signed-off-by: Boyan Ding <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Boyan Ding <[email protected]>
[Emil Velikov: handle the final case in glXCreateContextAttribsARB]
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Boyan Ding <[email protected]>
[Emil Velikov: handle the all cases]
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Signed-off-by: Boyan Ding <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a copy of commit 536003c11e4cb1172c540932ce3cce06f03bf44e
except for i915.
Original log for the i965 commit follows:
Some application, such as drm backend of weston, uses XRGB8888 config as
default. i965 doesn't provide this format, but before commit 65c8965d,
the drm platform of EGL takes ARGB8888 as XRGB8888. Now that commit
65c8965d makes EGL recognize format correctly so weston won't start
because it can't find XRGB8888. Add XRGB8888 format to i965 just as
other drivers do.
Signed-off-by: Derek Foreman <[email protected]>
Acked-by: Boyan Ding <[email protected]>
Tested-by: Mark Janes <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, if a call to get_attachment fails is because attachment
is a INVALID_ENUM. But for some specific cases, if COLOR_ATTACHMENTm
(where m >= MAX_COLOR_ATTACHMENTS) is used, it should raise an
INVALID_OPERATION exception instead.
Fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameter_errors
GL45-CTS.direct_state_access.framebuffers_renderbuffer_attachment_errors
v2: extra new line before quote block. Include "color attachment" on both
new message errors (Nicolai).
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Some callers would need that info to know if they should raise
INVALID_ENUM or INVALID_OPERATION. An alternative would be the caller
to check if the attachment is a GL_COLOR_ATTACHMENTm, but that seems
redundant as get_attachment is already doing that.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a proper check for feature support, and raise an invalid enum for
GL_CLAMP_VERTEX/FRAGMENT_COLOR unconditionally in core profiles, since
those enums were explicitly removed after the extension was promoted
to core functionality (not in the profile sense) with OpenGL 3.0.
This matches the behavior of the AMD closed source driver and fixes
GL45-CTS.gtf30.GL3Tests.half_float.half_float_textures.
Cc: "12.0 13.0" <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
| |
This fixes a defect detected by Coverity Scan.
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
|
|
| |
GL_ARB_vertex_attrib_64bit was the last piece missing.
v2: update docs (Jordan)
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: update docs (Jordan)
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
ARB_vertex_attrib_64bit for HSW+
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: update docs (Jordan)
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
| |
Those not supporting 64 bit input vertex attributes will have the
dual_slot value as false.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For dvec3 and dvec4 types, a single GRF do not have enough space to
allocate two inputs from two different vertices (SIMD4x2).
So the GRF only contains first two components for the two vertices, and
the next GRF has the remaining components.
We want to put all the components for the same vertex in the same
register. Thus, we do a shuffle to reorder the data.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Doubles needs more that one slot per attribute. So when filling the
attribute_map we check if it is a double in order to allocate one
extra register.
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Doubles need extra space, so we would need to do a remapping for vec4
too in order to take that into account. We reuse the already
existing remap_vs_attrs, but passing is_scalar, so they could
remap accordingly.
v2: code-format remap_vs_attrs_params initialization (Matt)
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the payload setup, setup_attributes is called with the first
GRF that can be used for the attributes (first ones are used for
uniforms for example) and returns the first GRF that is not part of the
payload. Before this patch, it adds directly the number of attributes.
But as with 64-bit attributes can consume more than one slot, that is
not valid anymore. This patch change the addition to use the number of
slots consumed.
gen >= 8 would not be affected, as they use the scalar mode. For that
case, the vs configuration is done at fs_visitor::assign_vs_urb_setup.
v2: add explanation in commit log (Jordan)
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen < 8 doesn't support *64*PASSTHRU formats when emitting
vertices. So in order to provide the equivalent functionality, we need
to downsize the format to equivalent *32*FLOAT, and in some cases
(R64G64B64 and R64G64B64A64) submit two 3DSTATE_VERTEX_ELEMENTS for
each vertex element.
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Although gen7 doesn't include surface types as a valid conversion format,
we return it, as it reflects what we want to achieve, even if we need
to workaround it on gen < 8.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From OpenGL 3.1 spec, section 4.3.1 "Reading Pixels", page 190 (203 PDF)
"When READ FRAMEBUFFER BINDING is zero, i.e. the default
framebuffer, src must be one of the values listed in table 4.4,
including NONE . FRONT_AND_BACK , FRONT , and LEFT refer to the
front left buffer."
There is an equivalent text on OpenGL 4.5 spec, section 18.2.1
"Selecting Buffers for Reading", page 502 (524 PDF), so the behaviour
is still the same.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
is allowed under some circumstances:
From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
for Writing", page 493 (page 515 of the PDF):
"An INVALID_ENUM error is generated if any value in bufs is FRONT,
LEFT, RIGHT, or FRONT_AND_BACK . This restriction applies to both
the de- fault framebuffer and framebuffer objects, and exists
because these constants may themselves refer to multiple buffers, as
shown in table 17.4."
And on page 492 (page 514 of the PDF):
"If the default framebuffer is affected, then each of the constants
must be one of the values listed in table 17.6 or the special value
BACK . When BACK is used, n must be 1 and color values are written
into the left buffer for single-buffered contexts, or into the back
left buffer for double-buffered contexts."
This patch keeps the same behaviour if OpenGL version is < 4. We
assume that for 4.x this is the intended behaviour, so a fix, but for
3.x the intended behaviour is the already in place.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
v2: remove forgot printf
v3: remove spaces before commas on spec quote, split line too
long (Anuj)
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Predication needs cmd parser only on gen7. For newer platforms, it
should be available without it.
v2 (Ken): rebase on recent changes.
Signed-off-by: Rafael Antognolli <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the below stats are encouraging this pass will also become
very usefull for avoiding regression once
brw_do_channel_expressions() and brw_do_vector_splitting() are
disabled.
On Broadwell:
total instructions in shared programs: 13078787 -> 13060898 (-0.14%)
instructions in affected programs: 1809827 -> 1791938 (-0.99%)
helped: 4527
HURT: 157
total cycles in shared programs: 256562762 -> 256590424 (0.01%)
cycles in affected programs: 159749392 -> 159777054 (0.02%)
helped: 5583
HURT: 2289
total spills in shared programs: 14929 -> 14923 (-0.04%)
spills in affected programs: 62 -> 56 (-9.68%)
helped: 1
HURT: 0
total fills in shared programs: 20144 -> 20141 (-0.01%)
fills in affected programs: 253 -> 250 (-1.19%)
helped: 1
HURT: 3
LOST: 0
GAINED: 2
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm going to add a boolean scheduling pass that I want run late, but
after copy propagation and dead code elimination. Yet, I don't want
to have to think about registers. So, move the register conversion
a little later.
No impact on shader-db. Suggested by Jason Ekstrand.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
Fixes building error due to dependency on nir generated headers
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Annoyingly, SPIR-V lets you specify all of these fields in either the
TCS or TES, which means that we need to be able to store all of them
for either shader stage. Putting them in a union won't work.
Combining both is an easy solution, and given that the TCS struct only
had a single field, it's pretty inexpensive.
This patch renames the combined struct to "tess" to indicate that it's
for tessellation in general, not one of the two stages.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want vue_map->num_slots to be one more than the final slot.
When assigning fixed slots, built-in slots, and non-SSO user varyings,
we do slot++. This leaves "slot" as one past the most recently assigned
slot. But for SSO user varyings, we computed slot based on the varying
location value...and left it at that slot value.
To work around this inconsistency, I made num_slots be "slot + 1" if
separate and "slot" otherwise. The problem is...if there are no user
varyings in SSO mode...then we would have done slot++ when assigning
built-ins, so it would be off by one. This resulted in loops from 0
to vue_map->num_slots hitting a bonus BRW_VARYING_SLOT_PAD at the end.
This used to break the SIMD8 VS/TES backends, but I fixed that in
commit 480d6c1653713dcae617ac523b2ca5deee01c845. It's probably safe
at this point, but we should fix it anyway.
To fix this, do slot++ in all cases. For SSO mode, we overwrite slot
for every varying, so this increment only matters on the last varying.
Because we process varyings in order, this will set slot to 1 more
than the highest assigned slot.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes broken depth texturing after:
commit 22639a6e19f95902aef23474ad672bf489231ea7
Author: Timothy Arceri <[email protected]>
Date: Mon Nov 21 00:29:29 2016 +1100
st/mesa: get Version from gl_program rather than gl_shader_program
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, input_reads was a bitmap tracking which vertex input locations
were being used.
In OpenGL, an attribute bigger than a vec4 (like a dvec3 or dvec4)
consumes just one location, any other small attribute. So we mark the
proper bit in inputs_read, and also the same bit in double_inputs_read
if the attribute is a dvec3/dvec4.
But in Vulkan, this is slightly different: a dvec3/dvec4 attribute
consumes two locations, not just one. And hence two bits would be marked
in inputs_read for the same vertex input attribute.
To avoid handling two different situations in NIR, we just choose the
latest one: in OpenGL, when creating NIR from GLSL/IR, any dvec3/dvec4
vertex input attribute is marked with two bits in the inputs_read bitmap
(and also in the double_inputs_read), and following attributes are
adjusted accordingly.
As example, if in our GLSL/IR shader we have three attributes:
layout(location = 0) vec3 attr0;
layout(location = 1) dvec4 attr1;
layout(location = 2) dvec3 attr2;
then in our NIR shader we put attr0 in location 0, attr1 in locations 1
and 2, and attr2 in location 3 and 4.
Checking carefully, basically we are using slots rather than locations
in NIR.
When emitting the vertices, we do a inverse map to know the
corresponding location for each slot.
v2 (Jason):
- use two slots from inputs_read for dvec3/dvec4 NIR from GLSL/IR.
v3 (Jason):
- Fix commit log error.
- Use ladder ifs and fix braces.
- elements_double is divisible by 2, don't need DIV_ROUND_UP().
- Use if ladder instead of a switch.
- Add comment about hardware restriction in 64bit vertex attributes.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we do this only in the fallback code (when tiled memcpy
version failed) but it needs to be done always so that we have
correct read and write buffer in place. No regressions seen in CI.
Fixes:
dEQP-EGL.functional.buffer_age.*
Signed-off-by: Tapani Pälli <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98330
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
We no longer need anything from gl_linked_shader.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
We no longer need anything from gl_linked_shader.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
We now get everything we need from the gl_program param.
Reviewed-by: Nicolai Hähnle <[email protected]>
|