SplitImmediateAddend peeled a single immediate operand off a T# dword's
scalar offset. A title that loads a 32-byte record with two
s_load_dwordx4, the second at soffset (first soffset + 16) where the
first is (key << 5) + C, left IAdd32(key << 5, C) as the base of dwords
4-7, which never matched dword 0's base, and the image failed with
"GetImageResource dword 0 is not a valid runtime value".
Peel immediate IAdd32 operands until none is left and sum them modulo
2^32, as the scalar adds do. The chained offsets then reach the existing
folded-addend path. verifyChainedTableOffset is the pointer table offset
carry shader with the second offset chained off the first.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Main's #6402 runs image stores through an image table, so a T# keyed
per lane keeps its table with a supported image_store and an
unsupported mark for the other operations.
Main's #7101 reads a key buffer's words in one call where this branch
names the reason a narrowing is skipped. Keep main's bulk read and
count both of its unmapped-page skips as unmapped.
The generated evaluation stage writes the provoking vertex's flat values
at every corner of the patch, so the host's provoking vertex no longer
changes what the pixel shader reads and VK_EXT_provoking_vertex is not
needed for these draws.
A kqueue descriptor is readable while one of its events is triggered and
is never writable or exceptional, as FreeBSD's kqueue_poll answers, on
both hosts. On Windows select threw for it, and on Linux its /dev/null
placeholder was reported readable and writable.
A descriptor that stops being a socket, a kqueue or a pipe during the
wait now fails the call with EBADF when it was closed and is selected
again with the rest of the timeout when its number was reused, as
FreeBSD's kern_select looks every descriptor up again in each pass,
instead of throwing. On Windows a host descriptor that is not a pipe
throws when select starts, before waiting.
Depends on #7139.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
select takes descriptors 0 to 2 as a console title's terminal with no input: 0 is never readable and 1 and 2 are always writable. poll threw for them unless the host happened to attach a pipe, so the same title could select on its standard streams but not poll them. poll now gives the same answer, with POLLOUT, the one bit ttydev_poll reports for a writable terminal, for 1 and 2 and nothing for 0.
selscan asks a descriptor once, with the flags of every set it is in (POLLRDNORM for the read set, POLLWRNORM for the write set, POLLRDBAND for the exception set, plus POLLHUP and POLLERR), and marks each set whose flags the answer shares. A seeded random device's randomdev_poll narrows a request with POLLRDNORM to that bit and returns any other request whole, so in the read set it is readable and in no other set, and otherwise it is in each write and exception set it was asked in; select reported it readable and writable together and never exceptional. A regular file or directory went to the host poll, which on Windows threw; vop_stdpoll makes it readable and writable and never exceptional, which select now answers in process on every host, as poll does.
poll threw for /dev/random and /dev/urandom, which select already treats as ready. FreeBSD 11.4's randomdev_poll, once the device is seeded, narrows a request that has POLLIN or POLLRDNORM to those bits and returns any other request whole, POLLOUT and the band bits included. poll now answers that, and the test that relied on the random device throwing uses a kqueue descriptor, which poll still does not support.
poll threw for any descriptor that is neither a socket nor a pipe, so a title polling a file it also reads stopped there. FreeBSD 11.4 hands a vnode to VOP_POLL, and both vop_stdpoll and vop_nopoll return POLLIN, POLLRDNORM and POLLOUT of the requested events for every event poll accepts and never POLLPRI, POLLRDBAND or POLLWRBAND. A file, a directory or a file read from app0.zar now answers that without a host call. File::IsVnode tells such a descriptor apart from the host file type without throwing, so a host socket lent by libSceNet still reaches its own path.
Covers a thread-pointer read (FS and GS form) after the store with a movable
instruction before it, and the fallback to the following access when there is
no other neighbour.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
A 256-bit store is 4 bytes, so its stub window takes a neighbouring
instruction to make room for the jump. The window took the following
instruction first even when it was a guest TLS access (an FS or GS prefix).
The macOS writer cannot rewrite a TLS access inside a stub and refuses the
module with "AMD-only instruction is also a guest TLS access".
The window now tries the following and the preceding instruction without a
segment prefix first, and falls back to the old order only when neither
works, so outputs that can keep the access in the stub do not change.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
A triangle list without primitive restart whose pixel shader emulates
barycentrics draws through the generated tessellation stages when the
device has tessellation but no geometry shaders, as on MoltenVK. The
pipeline uses a three-point patch list for it, keeps it out of pipeline
libraries and validates the generated stages' modes and interface.
On a device without geometry shaders, each triangle becomes a three-point
patch at tessellation level 1. The evaluation stage takes the corner
gl_TessCoord points at as its vertex and writes it as the weights, and
passes every vertex's parameters for raw reads. The vertex clip distances
are forwarded, so MoltenVK's stage interface matches the vertex output.
A short TLS access followed by a near branch with an operand-size prefix
decided the branch was relative from its flow kind and opcode alone, then
re-encoded it to the fall-through address or wrote its rel32 over the prefix
and opcode. Such a branch now counts as one that cannot move.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016TFMtUC4L4wMS4eeEqaNSR
The case drew 0.5 green, which lies halfway between two UNORM8 codes, so a
device that rounds 127.5 up (llvmpipe, LLVM 20.1.2) failed the half-code
tolerance with red and blue correctly swapped. It now draws 64, 128 and 32
of 255 from its own pixel program and names the loaded and expected codes
when a sample differs.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On a PS5 (firmware 12.70), of the values 0, 1, 2 and -1,
pthread_condattr_setpshared accepts only 0 and leaves the attribute
unchanged otherwise. pthread_condattr_getpshared reports 0 and returns
EINVAL for a null, uninitialized or destroyed attribute, also with a
null output. With an initialized attribute a null output crashes the
console; here it throws.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Measured on a PS5 (firmware 12.70): the getter reports 0, and of the
values 0, 1, 2 and -1 the setter accepts only 0 and checks the value
before the attribute. A null or uninitialized attribute, or a null
output, crashes the console; here it throws.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On a PS5 (firmware 12.70), of the values 0, 1, 2 and -1,
pthread_spin_init, pthread_barrierattr_setpshared and
pthread_mutexattr_setpshared accept only PTHREAD_PROCESS_PRIVATE (0);
1, 2 and -1 return EINVAL and leave the attribute unchanged.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PPSA34015 (EA SPORTS FC 27) registers EVFILT_READ for descriptor 0 in a
new kqueue at start-up, ignores the result, and stopped with "kevent:
EVFILT_READ on a non-socket descriptor not implemented". A read event on
the host stream on descriptor 0 is now accepted and never triggers, as
select never reports descriptor 0 readable.
Shader registration and the shader ABI resolves run on the title's own
threads, which never bound a trace buffer, so their Shader.Register and
Shader.Resolve* scopes were missing from every trace and summary. Those
entry points now bind the calling thread as `title` with the 32,768-event
buffer the shader preparation threads use.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
