- Apr 13, 2023
-
-
buffer_offset_size was almost correct, but didn't calculate the size correctly. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22449>
-
The old code was kinda bogus as we mapped at (0, 0, 0), but then didn't take the origin into account when specifiying the size of the access. Just offset properly instead. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <!22449>
-
We kinda need three things: 1. offset of a point in linear memory 2. size of access for a region 3. a mix of both Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <!22449>
-
This optimization causes some MTL tests to run forever. Not yet sure why. Disabling optimization until we have a fix. Reviewed-by:
Mark Janes <markjanes@swizzler.org> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22373>
-
Rendering is still fine, stable checksum for the last 3 runs. Part-of: <mesa/mesa!22348>
-
Fixes timeouts in CI for spec@glsl-1.50@execution@interface-blocks-api-access-members where we've got a GS with SO outputs and no vars declared, by asserting that something has gone horribly wrong instead. Part-of: <mesa/mesa!22348>
-
Add more system values for XFB. This should be good enough for lowering GL3.1 + transform_feedback2 + transform_feedback3. More will probably be needed for geom/tess but that will be easier to work with when I'm actually bringing up geom/tess. At any rate, we're splitting out XFB from the rasterization pipeline and since XFB happens only in the last shader pre-rasterization stage, VS+XFB is an orthogonal problem from e.g. VS+GS+XFB. Yeah, the combinatorics suck. These will be used by Asahi, and hopefully eventually Panfrost. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Acked-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <!22123>
-
Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Suggested-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!22383>
-
Verified by hand to produce the same results. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by:
Emma Anholt <emma@anholt.net> Part-of: <mesa/mesa!22383>
-
The Mali sample positions are the standard sample positions. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by:
Emma Anholt <emma@anholt.net> Part-of: <!22383>
-
Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by:
Emma Anholt <emma@anholt.net> Part-of: <mesa/mesa!22383>
-
ctx->get_sample_position doesn't change what it returns based on the programmed positions, it's just supposed to return the defaults. For most (all?) hardware, those are the Vulkan standard sample positions. In bf9a1e0a ("zink: add a pipe_context::get_sample_position hook"), Mike wondered why there wasn't a common implementation. So here's one to fix that :~) Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by:
Emma Anholt <emma@anholt.net> Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <!22383>
-
Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
Saves some bytes when Xe kmd fields are added and makes easier to spot places that are misusing i915 variables. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
The comment to initialize screen earlier not valid anymore so we can initialize it with the rest of batch fields. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22172>
-
Signed-off-by:
xurui <xurui@kylinos.cn> Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!22328>
-
With the on_demand shaders feature, meta pipelines are only created when they are used, otherwise they are NULL. Though, inside secondary cmdbuffers, the graphics pipeline might be also NULL. In this specific case, radv_is_{dcc,fmask}_decompress_pipeline() would return TRUE because these pipelines are NULL too... This fixes flakes with tests that use secondary cmdbuffers with TC-compat images. Cc: mesa-stable Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!22440>
-
Signed-off-by:
Eric Engestrom <eric@engestrom.ch> Part-of: <mesa/mesa!22455>
-
Signed-off-by:
Eric Engestrom <eric@engestrom.ch> Part-of: <mesa/mesa!22455>
-
To simplify both llvm and aco backend and remove unnecessary workaround code where prim count is known to be not zero. Reviewed-by:
Timur Kristóf <timur.kristof@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Part-of: <mesa/mesa!22381>
-
Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <!22437>
-
Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!22437>
-
rustfmt has some magic that follows files (I'm guessing), making files get checked multiple times with `*.rs`, so let's limit ourselves to `lib.rs`. Part-of: <mesa/mesa!22321>
-
Per [1], arm is for 32-bit. For an upcoming change, we need to detect AArch64 specifically. Specifying arm in the cross file will result in the wrong build script behavior. [1]: https://mesonbuild.com/Reference-tables.html#cpu-families Reviewed-by:
Helen Koike <helen.koike@collabora.com> Reviewed-by:
Emma Anholt <emma@anholt.net> Part-of: <mesa/mesa!22418>
-
Part-of: <mesa/mesa!22453>
-
For the CL spec it really matters how a program object was created. We never really cared all that much, but it didn't support the corner case of having an empty string as the OpenCL C source code. Enums feel like the more Rust way to do this kind of stuff anyway. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
The code wasn't all the same, but the build version was wrong, e.g. the compile flags specified need to be stored even on error. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Closes: mesa/mesa#8771 Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!22280>
-
We want to validate the actual passed in SPIR-V, but we can only report errors back on build/compile time. So instead of storing the initial IL in the devices `ProgramBuild` objects, just store it on the Program instead. This also simplifies setting spec constants as this is only valid on program directly created from IL and not e.g. linked ones. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!22280>
-
I moved to many things to radv_pipeline_graphics.c without checking. Fixes: 7783b7f6 ("radv: split radv_pipeline.c into radv_pipeline_{compute,graphics}.c") Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!22441>
-
Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
Vitaliy Triang3l Kuzmin <triang3l@yandex.ru> Part-of: <mesa/mesa!22384>
-