Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jmoguillansky/meson windows master #4

Open
wants to merge 388 commits into
base: master
Choose a base branch
from

Conversation

jmoguillansky-gpsw
Copy link
Owner

No description provided.

mbouron and others added 30 commits October 6, 2020 15:55
Ensures that when a node rtt draw ends, we restore the previous
rendertarget without discarding its attachments.
Precision qualifiers apply only to floating point, integer and opaque types.
It was used by the player widget.
While it makes sense to observe the resources of a tree at a given time,
having a playback that run a subprocess 60 times per second is not
exactly practicable. The feature was present because the feature was
shared with the widget player, but the complexity added by this real
time system is not worth the maintenance burden.
It's a now fake clock that shouldn't be needed outside of the graph
view. The class should be inlined within the GraphView one at some
point, or at least renamed in the future.
Previously we were binding (and clearing) the rendertarget before
drawing the subgraph. This leads to the folowing scenario (with
performance issues):

             (RTT 1)
               / \
              /   \
             /     \
         (RTT 2)  (Render)

Where we:

- started the renderpass of RTT 1 with a clear
- started the renderpass of RTT 2 with a clear
- resumed the renderpass of RTT 1 with a draw call, which has
  performance implications because the renderpass needs to reload
  the previous content of its attachments

This commit addresses this issue by binding/clearing at the right time.

The same scenario now perform the following steps:
- starts the renderpass of RTT 2
- starts the renderpass of RTT 1, clear attachments and perform a draw
  call
The pipeline API should only be about creating and binding a pipeline.
Resources binding and draw calls (draw, draw indexed, dispatch)
should belong to separate modules.

This commit is a first step in this direction as it decouples the
graphics resources binding from the pipeline initialization.

Signed-off-by: Matthieu Bouron <[email protected]>
These fields are specific to the OpenGL backend.
The RTT node will stop inheriting from the parent clear color, thus, we
need to specify it where it is needed.
The RTT node will stop inheriting from the parent clear color, thus, we
need to specify it where it is needed.
Makes the rtt clear color default to (0, 0, 0, 0).
This feature is currently not used and tested.
jmoguillansky-gpsw and others added 30 commits December 10, 2020 10:59
This is useful for doing binary I/O on non-UNIX environments.
sxplayer 9.7.0 has MSVC support.
This directory can be shared for other potential external dependencies.
Remove "WINAPI" declaration due to various compile errors
With MSVC the symbols are hidden by default, so we need a mechanism
similar to what we do with GNU and Apple linkers to export them. The
simplest way to achieve that is to use some ifdefery to set some
specific import/export attributes.

On Windows, this implies that users will be required to set a special
compilation flag for their static build. To make this transparent for
the users, the specific flag is exposed through pkg-config if the build
is configured for static. pkg-config is arguably not well supported on
Windows, but this is better than nothing. For DLL users, nothing
specific is required since it's the preferred and default build
configuration.

As a side effect, the linker scripts for GNU and Apple are not required
anymore. The meson gnu_symbol_visibility option also works with Apple
Clang/LLVM toolchain.
Don't hardcode python.exe
Update wslpath command
Resolves compile error "No target architecture"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants