Builder ffmpeg64-solaris10-i386 Build #12304

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg64-solaris10-i386' triggered this build

Steps and Logfiles:

1. git update ( 6 secs )
   1. stdio
2. shell 'gsed -i ...' ( 1 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 6 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_64.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Niklas Haas

   gitohnoyoudont@haasn.dev

Timing:

All Changes:

:

1. Change #237393

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sun 22 Jun 2025 12:13:09
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	27590d86534b0c94f12b9a206410f475fb008e72

   Comments

   avutil/hwcontext_vulkan: disable host transfers if ReBAR is disabled
   This feature fundamentally relies on host-visible VRAM, which restricts the
   set of available memory types to (typically) host-visible device-local ones.
   
   When resizable BAR is disabled, this memory type is usually limited to
   e.g. 256 MiB in size, which is just plain insufficient for allocation of
   general purpose GPU images, causing OOM errors on even the simplest of
   commands.
   
   The easiest solution is to disable host transfers entirely on machines
   without host-addressable VRAM. In theory, we could try and recover the use
   of host transfers for images which are *not* restricted to device-local
   memory types, but this is rarely the case in practice, and the effort
   required would exceed the benefit, especially since ReBAR is a standard
   feature on all platforms recent enough to have Vulkan drivers, and only
   occasionally disabled in the UEFI for by default for some hare-brained
   notion of "backwards compatibiility" with ancient software.

   Changed files

   • libavutil/hwcontext_vulkan.c