In the last few commits, a second patch was added to the LLVM toolchain,
and it no longer uses our binutils patch. This commit changes the CI
cache keys accordingly, in order to prevent unnecessary rebuilds of both
toolchains when only one is changed.
The Clang toolchain's cache now only takes into account patches that
begin with `llvm`, and the GNU toolchain excludes those from the hash
calculation. We now also hash the two CMake cache files that we use for
building LLVM and its runtime libraries.
We erroneously appended ".so" after the base name for the library,
so we ended up checking for the existence of e.g. `libc.so.so`,
which obviously didn't exist, so we overwrote the existing libraries
when we rebuilt the toolchain.
Our build of LLVM's objcopy now supports the single missing feature
(--update-section) that previously forced us to use the one from GNU
Binutils. This means that there is no reason anymore to build Binutils
alongside LLVM's tools.
This commit backports the LLVM commit that adds support for the
`--update-section` flag to llvm-objcopy. We use this feature of GNU
objcopy to embed the symbol map in the kernel.
The corresponding LLVM Phabricator Differential Revision can be found
here: https://reviews.llvm.org/D112116
This patch is identical to the upstream commit, except for two hunks
that had to be changed as they didn't apply cleanly.
This removes the shlib hack from the install step, which repackaged the
static library as the shared one. It also has the benefit of making the
port work with the Clang toolchain :^).
Context parameters are LibGL's way of centrally defining all parameters
that can be retrieved through `glGetBoolean*`, `glGetInteger*`, etc.
The spec describes that capabilities such as `GL_LIGHTING` can also be
retrieved through these methods, but it should not be possible to
retrieve random boolean parameters through `glIsEnabled`. For example,
`GL_UNPACK_LSB_FIRST` can only be retrieved through `glGet*`.
This moves reading of capabilities to `::get_context_parameter` and
implements its use in `::gl_is_enabled`.
Instead of using plain objects as Iterator records, causes confusion
about the object itself actually being its [[Iterator]] slot, and
requires non-standard type conversion shenanigans fpr the [[NextValue]]
and [[Done]] internal slots, implement a proper Iterator record struct
and use it throughout.
Also annotate the remaining Iterator AOs with spec comments while we're
here.
The `--allow-shlib-undefined` option is a bit of a misnomer. It actually
controls whether we should be allowed to have undefined references after
symbols from all dependencies have been resolved, so it applies both to
shared libraries and executables.
LLD defaults to allowing undefined references in shared libraries, but
not in executables. Previously, we had to disable this check for
executables too, as it caused a build failure due to the
LibC-LibPthread-libc++ and the LibCore-LibCrypto circular dependencies.
Now that those have been resolved, we can enable this warning, in the
hopes that it will prevent us from introducing circular libraries and
missing dependencies that might cause unexpected breakage.
Change the parent of the WizardDialog to that of the Spreadsheet window.
Previously the WizardDialog was using the open file dialog as the
parent resulting in the csv import dialog
Using a WeakPtr to keep a reference to the active layer caused it to
be destroyed when the last tab was closed, which made the
m_layer == layer check in set_layer() return early since it was
already null. Because of this the LayerPropertiesWidget was never
disabled.
After closing the last open ImageEditor, selecting a color would try to
dereference it causing a crash. Instead make set_image_editor() take a
pointer to it and set it to nullptr when closing the last tab like we
do with LayerListWidget and LayerPropertiesWidget.
The name `scissor_box_to_window_coordinates` was wildy inaccurate since
we are actually transforming window coordinates into whatever the
coordinate space of the backing bitmap is.
Previously the scroll position would not reset when loading a new
page. This caused various problems such as opening the page at the
previous pages scroll position and in some instances not even
showing the new page at all.
This was broken in commit 0a1b34c753 / PR #11687 since the buffer
descriptor list size was not page-aligned, and the new
`MM.allocate_dma_buffer_pages` expects a page-aligned size.
Discord user aesophor pointed out that the GCC toolchain fails to build
on macOS, and traced the issue back to 41ea37f2, which is the latest
change to `gcc.patch`. Similarly, when I tried to run BuildIt.sh in the
`--dev` mode, `git apply` complained about the patch being malformed.
I regenerated the patch by manually applying the changes of 41ea37f2 on
top of a known good GCC source tree, and I sent the new file to them.
They reported that this fixed the build issue they were having.
This adds a half pixel offset to the edge value calculation in order to
sample the triangle at pixel centers. This is in line with actual OpenGL
rasterization rules and generates correctly interpolated vertex
attributes including texture coordinates.
With the RASTERIZER_BLOCK_SIZE gone we can now render to any size, even
odd ones. We have to be careful to not generate out of bounds accesses
when calculating the render target and depth buffer pointers. Thus we
check the coverage mask and generate nullptrs for pixels that will not
be updated. This also masks out pixels that would touch the triangle but
are outside the render target/scissor rect bounds.
Since the alpha blend configuration should not change between most calls
of draw_primitives it makes no sense to reinitialize the blend factors
for every rasterized triangle.
The alpha blend factors are now set up whenever the device config
changes. The blend factors are stored in struct AlphaBlendFactors.
This adds member functions Device::rasterize_triangle() and
Device::shade_fragments(). They were free standing functions/lambdas
previously which led to a lot of parameters being passed around.
This adds a counter to the debug overlay that displays the average
percentage of SIMD lane utilization.
This number represents the number of pixels that were output for each
quad. A utilization of 100% means that all 4 SIMD lanes were used and
no pixels were masked out before being written to the color buffer.
