| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
update_single_program_texture() never returns NULL.
Signed-off-by: Miklós Máté <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
v2: - add dependency on dispatch.h generator (which this test needs)
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]> (v1)
|
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
This confused the with_dri flag which is meant to control Direct
Rendering Infrastructure, not classic drivers
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d80cbbeaff9329fdc78ae3d97097c1e65dfcdd61.
It turns out that formats do matter - the framebuffer's miptree has an
sRGB format, and the one we created did not. This broke rendering when
using KWin compositing, GNOME Terminal Fedora (with a transparent
background), and Qt menu rendering in general, to name a few.
It's been a month and this hasn't been fixed, and I'm sick of reverting
this patch or applying NAK'd hacks and restarting various programs at
random times every day, multiple times a day, to keep my desktop
environment functional.
The only benefit of this patch was to prepare the way for modifiers,
which AFAIK aren't finished yet anyway, so there's really no downside
to reverting it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 32fcced7b479 ("meta: Unset the textures_used_by_txf bitfield.")
added a dependency in libmesa_dricore to NIR headers, but failed to add
libmesa_nir as a dependency resulting in a build error:
In file included from external/mesa3d/src/mesa/drivers/common/meta.c:90:
external/mesa3d/src/compiler/nir/nir.h:48:10: fatal error: 'nir_opcodes.h' file not found
Add libmesa_nir as a static library dependency to libmesa_dricore.
Fixes: 32fcced7b479 ("meta: Unset the textures_used_by_txf bitfield.")
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
|
|
|
|
|
|
|
|
| |
We know that we will only ever need to lookup an external handle and so
can defer adding a bo to the external ht until it is ever exported or
imported, keeping that hashtable compact.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This was a leftover from i915. The one caller in i965 always passes in
false so there's no point in having the parameter.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
We already have a pointer to the texture object. Use it here.
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
| |
This really makes more sense in the intel_batchbuffer struct.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
fast_clear_op is leftover from the meta-fast-clear days.
No idea what the other thing was for, but it isn't used now.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 731ba6924a2ed6cdf47a78fd637a91a19ddcf9ed
"expose RGBA visuals only on Android" replaced
ARRAY_SIZE(formats) by num_formats, but there are
3 loops which add configs, and only one was updated
to num_formats.
Also update loops for configs with accumulation buffer
and multisample configs.
Fixes: 731ba6924a2 "i965: expose RGBA visuals only on Android"
Signed-off-by: Mario Kleiner <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Build i915 with meson. More or less copied from i965, with all
the unneeded cruft removed, and the libdrm_intel dependency added.
Cc: Dylan Baker <[email protected]>
Cc: Eric Anholt <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is a lot more natural than special casing it all over the place.
We still have to do a bit of special-casing in assign_constant_locations
but it's not special-cased quite as bad as it was before.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Now that everything is nicely ralloc'd, we can allocate the pull_param
array in assign_constant_locations instead of higher up. We can also
re-allocate the param array so that it's exactly the needed size. This
should save us some memory because we're not allocating the total needed
param space for both push and pull.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we're always growing the param array as-needed, we can
allocate the param array in common code and stop repeating the
allocation everywere. In order to keep things sane, we ralloc the
[pull_]param array off of the compile context and then steal it back
to a NULL context later. This doesn't get us all the way to where
prog_data::[pull_]param is purely an out parameter of the back-end
compiler but it gets us a lot closer.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Instead of requiring the caller of brw_compile_vs to figure it out, just
grow the param array on-demand.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Instead of making the caller of brw_compile_cs add something to the
param array for thread_local_id_index, just add it on-demand in
brw_nir_intrinsics and grow the array. This is now safe to do because
everyone is now using ralloc for prog_data::param.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
We haven't needed this ever since we started using NIR for lowering
rectangle textures.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, in the ARB program case _mesa_add_state_reference may grow
the parameter array which will cause brw_nir_setup_arb_uniforms to write
past the end of the param array because it only looks at the parameter
list length but the parma array is allocated based on nir->num_uniforms.
The only reason this hasn't caused us problems is because we are padding
out the param array for fragment programs unnecessarily.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The Vulkan driver does not support pull constants. It simply limits
things such that we can always push everything. Previously, we were
determining whether or not to push things based on whether or not the
prog_data::pull_param array is non-null. This is rather hackish and
about to stop working.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This burns an extra 10k of memory or so in the case where you don't have
any images. However, if you have several shaders which use images, this
should be much less memory. It also gets rid of a part of prog_data
that really has nothing to do with the compiler.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This should be just as good as looking in prog_data but removes our one
state setup dependency on brw_stage_prog_data::nr_image_param.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves us away to the array of pointers model and onto a model where
each param is represented by a generic uint32_t handle. We reserve 2^16
of these handles for builtins that get generated by somewhere inside the
compiler and have well-defined meanings. Generic params have handles
whose meanings are defined by the driver.
The primary downside to this new approach is that it moves a little bit
of the work that we would normally do at compile time to draw time. On
my laptop this hurts OglBatch6 by no more than 1% and doesn't seem to
have any measurable affect on OglBatch7. So, while this may come back
to bite us, it doesn't look too bad.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The only thing it was handling was push constants. We pull the actual
constant upload code into gen6_constant_state.c and the atoms into
genX_state_upload.c.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
There's no reason why that tiny bit of memory needs to be on the heap.
We always put blob_reader on the stack, so why not do the same with the
writable blob.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
We're going to want to use the blob for Vulkan pipeline caching so it
makes sense to have it in libcompiler not libglsl.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As all users of brw_blorp_miptree_download() must emit a full pipeline
and cache flush when targetting a user PBO (as that PBO may then be
subsequently bound or *be* bound anywhere and outside of the driver
dirty tracking) move that flush into brw_blorp_miptree_download()
itself.
v2 (Ken): Rebase without userptr stuff so it can land sooner.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This improves the FillTex benchmark in GLBench 2.7 by 30% on my Broxton.
On Ken's Broxton which only has single-channel ram, it improves by 210%.
v2 (Ken): Check mt->aux_usage == ISL_AUX_USAGE_CCS_E rather than using
intel_miptree_is_lossless_compressed().
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v1 (Topi Pohjolainen): original patch.
v2 (Topi Pohjolainen):
- Fix return value (s/MESA_FORMAT_NONE/false/) (Anuj)
- Move _mesa_tex_format_from_format_and_type() just
in the end avoiding additional if-block (Anuj)
- Explain better the array alignment restriction (Anuj)
- Do not bail out in case of gl_pixelstore_attrib::ImageHeight,
it is handled by _mesa_image_offset() automatically (Ken).
- Support 1D_ARRAY by flipping depth, width and y, z (Ken).
v3 (Topi Pohjolainen):
- Contrary to v2, do not try to handle
gl_pixelstore_attrib::ImageHeight. Currently there are no
tests in piglit or cts for it. One could possibly copy or
modify tests/texturing/texsubimage.c. There, however, seems
to be number of corner cases to consider. Moreover, current
meta path applies the packing height for both source and
targets when determining the offset. This would probably
require re-visiting also.
v4 (Topi Pohjolainen): Rebased on top of merged drm-bacon
v5 (Jason Ekstrand):
- Move to brw_blorp.c
- Significant refactoring
- Fixed 1-D array textures
- Simplified handling of PBOs vs. CPU data.
- Handle gl_pixelstore_attrib::ImageHeight. It turns out there are
piglit tests that cover this. The original version was failing them
because of an error in the way it handled 1-D array textures.
- Add support for texture download
v6 (Kenneth Graunke): Rebase fixes:
- Use intel_miptree_check_level_layer instead of deleted fields
- Update for mesa_format_supports_render[] rename.
- Pass 'false' (read-only) to intel_bufferobj_buffer
v7 (Kenneth Graunke):
- Fix brw_blorp_download_miptree to pass 'false' (not read only) for
the destination buffer (caught by Chris Wilson).
- Fix blorp_get_client_bo to pass intel_bufferobj_buffer !read_only
for the 'writable' parameter instead of 'false' (caught by Jason).
- Support GL_BGR, GL_BGRA, GL_BGRA_INTEGER, GL_BGR_INTEGER, allowing
us to use this for ReadPixels on the window system buffer (caught
by Chris Wilson).
- Fix y-flipping bugs in download path (exposed by BGRA support).
- Fix false vs. NULL return value in blorp_get_client_bo.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
| |
I want to reuse it for the BLORP download path.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Framebuffer access includes framebuffer reads so we need to invalidate
the texture cache. We do not, however, need to flush the depth cache
because you cannot do bind a depth texture as an image.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Texture uploads and downloads may go through the render pipe which may
result in texturing from or rendering to the texture or the PBO. We
need to flush accordingly.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GL_EXT_texture_sRGB_decode spec says:
"The conversion of sRGB color space components to linear color space is
always performed if the texel lookup function is one of the texelFetch
builtin functions.
Otherwise, if the texel lookup function is one of the texture builtin
functions or one of the texture gather functions, the conversion of sRGB
color space components to linear color space is controlled by the
TEXTURE_SRGB_DECODE_EXT parameter.
If the TEXTURE_SRGB_DECODE_EXT parameter is DECODE_EXT, the conversion
of sRGB color space components to linear color space is performed.
If the TEXTURE_SRGB_DECODE_EXT parameter is SKIP_DECODE_EXT, the value
is returned without decoding. However, if the texture is also accessed
with a texelFetch function, then the result of texture builtin functions
and/or texture gather functions may be returned with decoding or without
decoding."
This patch makes i965 force sRGB decoding for any textures accessed via
texelFetch(). If textures are accessed via texelFetch() and a regular
texture access function, this will affect the other ones too - which is
fine - it's undefined according to the last paragraph quoted.
We could make both work, but we'd have to emit multiple SURFACE_STATEs,
and have two binding table sections, like we do for texture gather hacks
on older platforms.
Fixes the following Android O CTS test:
dEQP-GLES31.functional.srgb_texture_decode.skip_decode.srgba8.texel_fetch
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Drivers that use Meta are happily using blitting data using texelFetch
and GL_SKIP_DECODE_EXT, but the GL_EXT_texture_sRGB spec unfortunately
makes GL_SKIP_DECODE_EXT not necessarily work with texelFetch.
As a hack, just unset the texture_used_by_txf bitfield so we can
continue with the old desired behavior.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
I'd like to put this sort of metadata in the shader_info structure,
rather than adding more things to gl_program.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When I realigned the bufferobj code, I didn't see the getters
were different, realign the getters to work the same as ssbo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103214
Fixes: 65d3ef7cd (mesa: align atomic buffer handling code with ubo/ssbo (v1.1))
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Mark Janes <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Sure, you'd think that the combination of GL_OES_texture_half_float and
GL_EXT_texture_rg would mean that GL_RG16F exists, but it doesn't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103227
Fixes: c16a7443e999 ("mesa: Expose GL_OES_required_internalformat on GLES contexts.")
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
It's not used -- DFRACEXP gets array indexes of its exponent out-parameter
lowered earlier -- and it wouldn't have worked correctly anyway when both
dst and dst1 use relative addressing.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Replace the undefined destination by a new temporary register.
Cleanup merge_two_dsts while we're at it.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure we actually allocate two adjacent TGSI temporaries. The
current code fails e.g. when an arithmetic operation has two
operands with indirect accesses.
I will send out a new piglit test
(arb_gpu_shader_int64/execution/indirect-array-two-accesses.shader_test)
Cc: [email protected]
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
It's not used, and the assignment for the TGSI case was incorrect
for sampler arrays.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|