Mode 1 keeps subnormal inputs and flushes a result below 2^-126 to a
zero of its sign; mode 2 flushes subnormal inputs and rounds a subnormal
result in the f32 round mode, as measured on RDNA2 (gfx1030) in every
f32 round mode at IEEE=0 and IEEE=1. Both modes threw before.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
v_cmp_X_f32 and v_cmpx_X_f32 flush their denormal inputs by bit 0 of the
FLOAT_MODE f32 denormal field, as measured on RDNA2 (gfx1030): mode 1
keeps them and mode 2 flushes them. Both modes threw before.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A write-back stored on the GPU over memory outside the write watch left its
units without saved guest bytes (only the CPU path saved them), so the next
store of results landing there threw (#5711), and every refresh re-uploaded
the image. The stored ranges are now copied from the retile scratch into a
host-visible buffer behind the store and become the saved bytes when the
batch completes; a store or refresh that needs them first syncs that batch.
Units without a write generation pending when their range leaves the watch
save their bytes there too.
The second-store fixture waits for the GPU before its surface is freed on
every return, as #5790 does for the other cases.
With libSceNet sockets on ordinary descriptor numbers (#4391), poll on a
libSceNet socket threw "neither a socket nor a pipe": poll only knew
libkernel sockets and pipes, while select already asks libSceNet through
its poller. libSceNet now lends libkernel the host socket behind a
descriptor, together with an owner that keeps it open, so poll puts it in
the same WSAPoll or poll call as libkernel sockets. ProsperoLight
(PPSA99002) stopped here on Linux and now reaches its PC list.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01EvDbpwUPTa78oCAJqe7m9K
v_cubeid_f32, v_cubesc_f32, v_cubetc_f32 and v_cubema_f32 refused any
output modifier with "VOP3 source modifiers are not implemented";
PPSA11386 stops there on v_cubeid_f32 v, v, -v, -v div:2.
On RDNA2 (gfx1036), over 2048 inputs in every combination of IEEE mode,
the four f32 denormal values and f16/f64 denormals flushed or kept, with
round to nearest even, the four instructions apply mul:2, mul:4 and
div:2 whenever IEEE mode is off, also with f32 output denormals kept,
where v_mul_f32_e64 in the same kernels ignores them, and ignore them
with IEEE mode on. Where applied, the result is the existing bit-level
f32 output modifier result, and clamp is applied after it.
The decoder accepts the modifier on the four instructions. floatCube
applies the shared f32 scaling, now scaleF32Result, in those modes and
writes with the modifier cleared, so clamp is still applied after it.
With IEEE mode on the signaling NaN quieting applies and the modifier is
ignored; with it off the quieting does nothing and the modifier is
applied. agc_driver_vop3_cube_clamp checks each instruction with each
modifier against tables captured on gfx1036.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Fnrk5Dazjb2tLooVSpdRQq
OpenOrbis modules keep read-only data after their code, as executables
do. The syscall scan of sce_module modules decoded it, and the module of
the OpenOrbis library sample (libExample.prx) failed with "Forbidden
syscall instruction". For modules with a PT_SCE_DYNLIBDATA segment, the
scan now stops at the end of the PLT after the last unwind function,
found by FindSceCodeEnd as for executables.
The same modules begin their executable segment with the
/libexec/ld-elf.so.1 string but have no PT_INTERP header, so code
analysis decoded the string and failed with "Unsupported Windows guest
TLS instruction (bytes: 64 2d 65 6c 66 2e)", which is the text "d-elf.".
When no PT_INTERP header covers the start of a PS4 code segment, code
analysis now starts after that exact string.
Add the PS4 functions sceVideoOutSetBufferAttribute and
sceVideoOutRegisterBuffers on top of the existing registration. The PS4
call uses the first free attribute set and returns its index. It
accepts linear A8R8G8B8_SRGB and A8B8G8R8_SRGB buffers, which map to the
PS5 B8G8R8A8 and R8G8B8A8 formats. It throws for tiled buffers, whose
PS4 layout differs from the PS5 one. Linear PS4 buffers may be 4 KiB
aligned: the OpenOrbis graphics sample places its second 1920x1080
buffer 8,294,400 bytes after the first. PS5 buffers keep the 64 KiB
rule. A handle with PS4 buffers writes the PS4 flip status (64 bytes)
and vblank status (32 bytes). Writing the 128-byte PS5 flip status into
the sample's stack structure overwrote its saved frame pointer.
An s_swappc_b64 whose target is not resolved compiles to a faulting call
only at the fallback the table-call linker emits; the linker lists those
calls in the request (GuestContext::linkedCallFallbacks), and every other
computed call is refused at compile time again, as on main. The new
agc_driver_compute_table_calls test runs a linked two-record table on
Vulkan in wave32 and wave64, with SCC 0 and 1 reaching the callee, and a
record past the table reporting the UnlinkedCall fault.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
An s_swappc_b64 whose target pair comes from an s_buffer_load of a buffer
whose descriptor is loaded from user data now calls the targets that buffer
holds: at dispatch the driver reads the buffer, links one copy of each
distinct callee after the caller and rewrites the call into a compare chain
that s_call_b64s the matching copy. A target that matches no copy, and any
other computed call, records an UnlinkedCall fault that the driver reports,
instead of failing the shader at compile time.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Decode and Flush let FFmpeg crop every picture to its display size, so a
1080p H.264 stream came out as 1920x1080 with the chroma after 1080 luma
rows. The console reports and writes the coded picture: EVO-PLAYER-PS5's
hardware run of a 1080p H.264 IDR returned 1920x1088 with pitch 2048 and
the chroma after the 1088 luma rows, and ProsperoLight rejects a 1080p
H.264 or HEVC picture whose height is not 1088. FFmpeg's cropping is now
off, so the frame size, the chroma offset and the sizes in the AVC
picture info are those of the coded picture. The pitch is unchanged, and
the frame size QueryDecoderMemoryInfo reports, which aligns the maximum
height to 32 rows, still holds a picture coded within the maximum and the
macroblock-padded H.264 picture of a maximum given as the display size.
libSceVdecsw derived its crop offsets from the difference between that
size and the macroblock grid, which is now zero. It takes the crop FFmpeg
exports for the picture from libSceVideodec2 instead.
The H.264 fixture is coded at 64x48 with frame_crop_bottom_offset 4: its
pictures are checked at 64x48 and the crop through Vdecsw. The HEVC and
VP9 fixtures are coded at 64x40 and keep their hashes. The new hashes come
from FFmpeg 8.1 decoding with apply_cropping 0, hashed as the tests do;
the same method reproduces every previous H.264, HEVC and VP9 hash.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
A 3D image access bound to a 1D T# matched no runtime image mode and threw
"image descriptor is incompatible with the static runtime image interface"
(SONIC SUPERSTARS, PPSA06888, which reads a 1x1 1D T# as 3D with a plain
image_sample and an image_load). Add a 1D mode for 3D accesses whose only
uses are image_sample_lz, plain image_sample or mip-less image_load.
Measured on RDNA1 (RX 5700 XT, gfx1010) with the hardware oracle:
image_sample_lz reads the texel u selects and ignores v and r with every
addressing mode; a plain image_sample takes its texel and LOD from u alone;
image_load reads the x texel for any y when z is 0 and returns zero for any
other z, as the 3D-on-2D load measured in #2023 does.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QQNVXyqeecpyneonkYL6H1
fcntl on a guest socket handled F_GETFL and F_SETFL only and failed every other command with EINVAL, so libcurl's fcntl(fd, F_SETFD, FD_CLOEXEC) on a new socket failed (ProsperoRadio PPSA99001, traced by screamm on #4796). Record FD_CLOEXEC per socket descriptor: F_SETFD sets or clears it, F_GETFD reads it, SOCK_CLOEXEC sets it at creation, and dup, dup2 and close start without it, as FreeBSD's kern_fcntl and kern_dup do.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Since registered shaders are prepared in the background, a draw whose shader
was registered just before could wait seconds for its preparation inside the
queue worker. Under CPU load Goat Simulator 3's first submissions took ~3.7 s;
the title treated the GPU as hung, stopped submitting, and its 10 s garbage
collection timeout crashed it on every launch. Driver::Submit now waits for
the preparations queued before it, on the submitting thread, before the
commands reach the GPU.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The NID RvID8BVeg+g, declared as sceSaveDataUnknown_RvID8BVeg for
Minecraft (PPSA17221), hashes to sceSaveDataPrepareForTransferring. The
name is not in aerolib; it was found by combining words from the
libSceSaveData names that are. Behaviour is unchanged: it still throws,
now naming the real function.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_017WeVmjnnPPKdxVTpr2Vjtw
lstat of a Windows symbolic link threw, although symlink creates links
with relative targets on Windows and readlink reads them. Report such a
link as S_IFLNK with its own identity and times and the length of its
target as st_size, through the reparse reader readlink already used,
now shared from libkernel. Links with absolute targets, junctions and
other reparse points still throw, as for readlink.
The trace summary line keeps `trace_dropped` as before: true when any
thread lost a slice, any thread's totals table was full, or the gpu
track was full. When it is true, the line now also carries
`trace_dropped_threads`, one entry per affected thread name, so the reader
can tell which thread lost data and how much. Threads that share a
name, such as the shader prepare threads, share one entry: losses are
summed, the earliest fill is kept and totals_full is true if any is.
Each entry has `events_full_after_s`, the seconds from the first
present of the window to the start of the first lost slice. It is
absent for `gpu` and in every summary line (windowed frames/seconds
and APS5_TRACE_SUMMARY_EVERY) whenever the first lost slice starts
outside the line's span of presents, including a slice whose scope
began before the window opened or one lost after the last present.
`events_lost` is the number of slices not recorded and is absent when
0; in interval lines it counts the buffer's losses since it started.
`totals_full` is true when the thread's totals table overflowed, which
makes the summary numbers incomplete; a thread with only `events_lost`
has complete totals.
The Chrome trace gets a `trace buffer full` instant event on a thread
at the point where its buffer filled.
BUILD.md documents the new fields and the event.
`trace_dropped` is unchanged, and when nothing drops the default output
is byte-identical to before.
Refs #5786
Depends on #5808
PPSA09030's Media/Plugins/psvr2.prx imports sceHmd2ReprojectionGetStatus
from libSceHmd2 and sceVrTracker2GetCoordinateSystem and
sceVrTracker2GetPlayAreaBoundaryGeometry from libSceVrTracker2, so the
title does not start with the plugin loaded (discussion #4680). Declare
the three as throwing exports, like the earlier PS VR2 imports of
PPSA29866. The names resolve from the NIDs 8GkaY2B7opM, Y-3JCiU9bbU
and SCph4ZbkqzU with tools/nid_names.py; no reference gives their
signatures.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
