Commit 158f2f0f authored by Connor Abbott's avatar Connor Abbott

Fix fragment job offset

Unlike the vertex/tiler jobs, which are different on 32-bit and 64-bit,
the fragment payload is simple enough that it's the same, so there's an
extra 32 bits of padding after the next-job pointer on 32-bit.
Previously, that padding was hard-coded into the payload structure, but
we don't want it to exist on 64-bit, since then the payload structure
would have to be different on 32 and 64 bit for no good reason. Just
make the decoder adjust the padding itself.
parent 30c873c1
......@@ -595,9 +595,6 @@ struct mali_unknown6 {
#define MALI_COORDINATE_TO_TILE_MAX(W, H) MALI_COORDINATE_TO_TILE(W, H, 1)
struct mali_payload_fragment {
/* XXX: WTF? */
u32 zero;
u32 min_tile_coord;
u32 max_tile_coord;
mali_ptr framebuffer;
......
......@@ -986,9 +986,6 @@ static int panwrap_replay_fragment_job(const struct panwrap_mapped_memory *mem,
panwrap_log("struct mali_payload_fragment payload_%d = {\n", job_no);
panwrap_indent++;
if (s->zero)
panwrap_msg("ZT\n");
/* See the comments by the macro definitions for mathematical context
* on why this is so weird */
......@@ -1038,7 +1035,12 @@ int panwrap_replay_jc(mali_ptr jc_gpu_va, bool bifrost)
h = PANWRAP_PTR(mem, jc_gpu_va, typeof(*h));
int offset = h->job_descriptor_size == MALI_JOB_32 ? 4 : 0;
/* On Midgard, for 32-bit jobs except for fragment jobs, the
* high 32-bits of the 64-bit pointer are reused to store
* something else.
*/
int offset = h->job_descriptor_size == MALI_JOB_32 &&
h->job_type != JOB_TYPE_FRAGMENT ? 4 : 0;
mali_ptr payload_ptr = jc_gpu_va + sizeof(*h) - offset;
payload = panwrap_fetch_gpu_mem(mem, payload_ptr,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment