This change implements support for compute programs in the Direct3D 11
driver. The compute renderer doesn't work for me yet; my NVIDIA GTX 970
and Intel GPUs both display corrupted output and hangs.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, transformed images would take up as much atlas
texture space to fit them. However, we can easily run out of space for
large images or images with large scaling applied.
This change limits transformed images to their rendered bounds which is
the window size in the worst case.
Updates gio#219 (fixes the chat kitchen example)
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A follow-up change will cause some transformed images to render outside
their allocated atlas bounds. This change uses the GPU viewport to clip
them so they won't overwrite other atlas content.
Updates gio#219
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change allows atlas packer clients to start with large maximum
atlas dimensions, then shrink the maximum once the underlying atlas has
been allocated.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Previously, the packer optimized for the smalles space where the image
fits. Empirically, smaller atlases can be achieved by greedily picking the
smallest total area.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
On my Fedora Intel GPU, issuing a glBufferSubData immediately after a
glBufferData with no data may leave the buffer cleared.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There's no meaningful reason to have them separate. The intention was to
enable rendering concurrent with other processing, but that's gaining
framerate at the expense of input latency and complicating ImageOp
semantics.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
One staging buffer is enough because BeginFrame waits for the completion
of the staging operatoins from the previous frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Changes to the gioui.org/shader module are generally breaking changes,
which means that a particular version of gioui.org must be build with a
particular version of gioui.org/shader. Until now, the gpu package
checked the module version against an expected version and would fail at
runtime if there's a mismatch.
This change replaces all that complexity with a simple procedural
change: bump the module major version of gioui.org/shader at each such
incompatible change. It doesn't matter that we'll eventually reach
gioui.org/v1234/shader; the module is internal and won't break clients.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
OpenGL ES 2.0 doesn't support glBlitFramebuffer, but does support
glCopyTexSubImage2D. Fortunately, we don't need the extra features of
glBlitFramebuffer anyway.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The OpenGL (ES) implementations on Apple platforms are deprecated and
don't support GPU compute programs. This change adds support for the
replacement, the Metal GPU API.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Metal (and presumably the D3D11) backend doesn't support transformed
framebuffer blits. The only caller doesn't need it either, so drop that
capability from the driver abstraction.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Modern API such as Metal and Vulkan want clients to compile expensive
state changes into pipeline objects. Change our GPU driver abstraction
to match, thereby paving the way for future drivers.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The opengl example has a screenshot functionality that renders to a
non-sRGB texture, whereas window rendering is to a sRGB capable EGL
surface. The opengl driver detects the switch from an sRGB capable
output to a non-sRGB capable output, but not the switch back. This
change releases the emulation framebuffer on the switch back.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The default renderer tracks opaque rectangle draw operations and render
them front-to-back with a z-buffer to omit overdraw. However,
- Overlapping opaque rectangles are rare in a GUI, and the most common
instance, a solid window background, is already optimized to a glClear.
- A z-buffer is memory heavy.
- We conservatively assume a 16-bit depth buffer, which limits the
number of drawing operations to 64k (#127).
- Depth buffer support makes GPU ports more complex, especially for
upcoming ports (Metal, Vulkan).
- The compute renderer doesn't use z-buffers.
This change removes the optimization; a follow-up removes GPU backend
support.
Fixes gio#127
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The only reason for separate files is Objective-C callbacks into Go,
or when the Go side is common, yet the Objective-C side differs from
macOS to iOS.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Both the OpenGL and the Direct3D API are stateful and gpu.GPU renders to
the render target current when Frame is called.
Modern GPU API such as Metal don't have a concept of a current render
target, and the target even changes each frame.
Add RenderTarget and add an explicit target argument to GPU.Frame as
well as the underlying driver.Device.BeginFrame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change avoids the hard dependency on GPU support for sRGB encoded
textures in the compute renderer.
With this change and the previously added CPU fallback, Gio no longer
rely on any GPU functionality outside the OpenGL ES 2.0 level.
Fixes gio#49
Fixes gio#154
Fixes gio#97
Fixes gio#36
Fixes gio#172
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur