primordic/IssueDupesLite huggingface dataset:
Repository: JuliaGPU/CUDA.jl

Issue #1372: CUSPARSE: Adding a value to the diagonal
Created: 2022-02-14T23:06:58Z
I cannot figure out how to add a value to the diagonal, and it's showing some missing dispatches.
using CUDA
CUDA.allowscalar(false)
W = cu(sprand(100,100,0.1))
J = cu(sprand(100,100,0.1))
idxs = diagind(W)
λ = 1.0
@. @view(W[idxs]) = @view(W[idxs]) + λ # Scalar indexing

Base.:+(A::CUSPARSE.CuSparseMatrix,I::UniformScaling) = A + Diagonal(CuArray(ones(size(A,1))))
Base.:-(A::CUSPARSE.CuSparseMatrix,I::UniformScaling) = A - Diagonal(CuArray(ones(size(A,1))))

@show typeof(W + λ*I) # CuArray not sparse :(
W .= W + λ*I # Scalar index
This is the last piece to finish SciML/OrdinaryDiffEq.jl#1566 I think.

Duplicate issue #79: CuSparseMatrixCSC missing lu and interactions with UniformScaling
Created: 2020-05-16T19:02:22Z
using CuArrays, LinearAlgebra, SparseArrays, CuArrays.CUSPARSE
CuArrays.allowscalar(false)
nx = 1024
K = Tridiagonal(ones(nx-1), -2*ones(nx), ones(nx-1))
mK = CuSparseMatrixCSC(SparseMatrixCSC{Float32, Int32}(-K));
lu(mK)
mK + I
Xref: SciML/OrdinaryDiffEq.jl#1136

Closing comment (2022-02-16T19:52:12Z): mK+I does not.

That requires a proper broadcast, because it can change the structure.
I guess this is also a dup of #1372 then?
Repository: JuliaGPU/CUDA.jl

Issue #974: Int128 support
Created: 2021-06-14T07:04:17Z
CUDA GPUs do not natively support Int128 operations. LLVM supports lowering code that works with Int128, https://reviews.llvm.org/rGb9fc48da832654a2b486adaa790ceaa6dba94455, but requires compiler intrinsics for many operations:
julia> using CUDA

julia> x = widen.(CuArray(rand(Int64, 10)))
10-element CuArray{Int128, 1}:
  ...

julia> .÷(x, x)
ERROR: LLVM error: Undefined external symbol "__divti3"
With https://reviews.llvm.org/D34708, it should be possible to resolve those intrinsics in the current module, so we can just add them to our runtime library.

Duplicate issue #2675: CUDA.jl does not support tuples of UInt128
Created: 2025-02-28T21:55:51Z
Defining CUDA Array  with tuples of UInt128 makes Julia crash
Minimal Example:
u = (UInt128(0), UInt128(0))
CUDA.fill(u, 1)
CUDA normally handles UInt128, as the following example shows:
function testkernel(M)
    M[1] += 1
    return
end
M = cu([UInt128(0)])
kernel = @cuda launch = false testkernel(M)
kernel(M; threads=1, blocks=1)
Versions Infos
CUDA.versioninfo()

CUDA runtime 12.6, artifact installation
CUDA driver 12.6
NVIDIA driver 550.120.0

CUDA libraries: 
- CUBLAS: 12.6.4
- CURAND: 10.3.7
- CUFFT: 11.3.0
- CUSOLVER: 11.7.1
- CUSPARSE: 12.5.4
- CUPTI: 2024.3.2 (API 24.0.0)
- NVML: 12.0.0+550.120

Julia packages: 
- CUDA: 5.6.1
- CUDA_Driver_jll: 0.10.4+0
- CUDA_Runtime_jll: 0.15.5+0

Toolchain:
- Julia: 1.11.3
- LLVM: 16.0.6

versioninfo()

Julia Version 1.11.3
Commit d63adeda50d (2025-01-21 19:42 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 22 × Intel(R) Core(TM) Ultra 7 165H
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 22 virtual cores)

Closing comment (2025-03-03T09:31:37Z): julia> CUDA.fill(u, 1)
Promotion is not suitable for scalars of size larger than 64-bits
UNREACHABLE executed at /workspace/srcdir/llvm-project/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp:222!

Dup of #974
Repository: JuliaGPU/CUDA.jl

Issue #2484: Support for creating a CuSparseMatrixCSC from a CuSparseVector
Created: 2024-09-04T19:50:12Z
Multiplying a CuSparseMatrixCSC and a CuSparseVector vector returns a CuArray, instead of a  CuSparseVector.
using CUDA
using CUDA.CUSPARSE
using Random
using SparseArrays
Random.seed!(123)

N = 100
q = CuSparseVector(sprand(n,0.2))
M = sprand(Float64, N, N, 0.2)
M = CUSPARSE.CuSparseMatrixCSC(CuVector(M.colptr), CuVector(M.rowval), CuVector(M.nzval), (N, N))
M*q+q


Will get an error broadcast with sparse arrays is currently only implemented for CSR and CSC matrices
Is there a way to handle these operations? An obvious one is to convert the CuArray to a CuSparseVector again and proceed with the code. I am not sure if this is what we are expected to do.

Duplicate issue #2484: Support for creating a CuSparseMatrixCSC from a CuSparseVector
Created: 2024-09-04T19:50:12Z
Multiplying a CuSparseMatrixCSC and a CuSparseVector vector returns a CuArray, instead of a  CuSparseVector.
using CUDA
using CUDA.CUSPARSE
using Random
using SparseArrays
Random.seed!(123)

N = 100
q = CuSparseVector(sprand(n,0.2))
M = sprand(Float64, N, N, 0.2)
M = CUSPARSE.CuSparseMatrixCSC(CuVector(M.colptr), CuVector(M.rowval), CuVector(M.nzval), (N, N))
M*q+q


Will get an error broadcast with sparse arrays is currently only implemented for CSR and CSC matrices
Is there a way to handle these operations? An obvious one is to convert the CuArray to a CuSparseVector again and proceed with the code. I am not sure if this is what we are expected to do.

Closing comment (2024-09-11T07:35:50Z): We can reuse this trick:
https://github.com/JuliaGPU/CUDA.jl/blob/master/lib/cusparse/extra.jl#L84

That's the same as #2484 (comment), right? It should use a single column, Julia being column major.

Yes,  but you add an additional layer of transformation if you use CSC matrices.
Julia is column major but many CUSPARSE routines are just implemented for sparse CSR matrices.
Sparse matrix * matrix is one example of CUDA routine only implemented for CSR * CSR.
If something is working with CSC matrices (like sparse triangular solves or sparse CSC * CSC), it's because we use the relation between A and A' for CSC / CSR formats.
https://github.com/JuliaGPU/CUDA.jl/blob/master/lib/cusparse/generic.jl#L567
Repository: JuliaPlots/Plots.jl

Issue #1392: png creation broken in GR backend
Created: 2018-02-14T08:55:49Z
julia> using Plots

julia> x = linspace(-1,1,100);

julia> @gif for k=1:10
           plot(x,cos.(k*x))
       end
ERROR: failed process: Process(`ffmpeg -v 0 -i /var/folders/tt/c5pb_r2131d25c9f_b2z7jrc0000gp/T/tmpv0AyOy/%06d.png -vf palettegen=stats_mode=diff -y /var/folders/tt/c5pb_r2131d25c9f_b2z7jrc0000gp/T/tmpv0AyOy/palette.bmp`, ProcessExited(1)) [1]
Stacktrace:
 [1] pipeline_error(::Base.Process) at ./process.jl:682
 [2] run(::Cmd) at ./process.jl:651
 [3] #buildanimation#288(::Int64, ::Int64, ::Bool, ::Function, ::String, ::String, ::Bool) at /Users/solver/.julia/v0.6/Plots/src/animation.jl:81
 [4] #gif#285(::Array{Any,1}, ::Function, ::Plots.Animation, ::String) at /Users/solver/.julia/v0.6/Plots/src/animation.jl:63
 [5] gif(::Plots.Animation) at /Users/solver/.julia/v0.6/Plots/src/animation.jl:63
 [6] macro expansion at /Users/solver/.julia/v0.6/Plots/src/animation.jl:153 [inlined]
 [7] anonymous at ./<missing>:?

julia> versioninfo()
Julia Version 0.6.2
Commit d386e40c17 (2017-12-13 18:08 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin17.3.0)
  CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libgfortblas
  LAPACK: liblapack
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, broadwell)

Duplicate issue #1404: Issues using Plots to make gif
Created: 2018-02-21T19:34:07Z
Im running Julia 0.6 and I am trying to make a gif. This is the code I've run. Everything runs fine until the last line gif(anim).
using Plots
pyplot(size=(300,200))
p = plot([sin,cos], 0, π, lab=[:sin :cos])
scatter!(1, lab="")
anim = @animate for x in 0:0.1:π
 p[3] = [x,x], [sin(x),cos(x)]
end
gif(anim)
It produces the error

Ive tried everything that I can think of, updating packages etc. but it won't work.
I also tried this bit of code 
using Plots
pyplot(size=(300,200))
p = plot([sin,cos], 0, π, lab=[:sin :cos])
scatter!(1, lab="")
anim = @animate for x in 0:0.1:π
  p[3] = [x,x], [sin(x),cos(x)]
end
gif(anim)
It produces the same error.

Closing comment (2018-02-21T20:09:37Z): Do you have ffmpeg installed?
This might also be a dup of #1392
Repository: JuliaPlots/Plots.jl

Issue #4766: aspect_ratio not working expectedly with PGFPlotsX
Created: 2023-06-08T01:28:34Z
Details
When plotting heatmap with PGFPlotsX backend, I want to have aspect_ratio = 1. The following script
using Plots
pgfplotsx()

heatmap([1, 2, 3, 4], [1, 2, 3, 4], [1 2 1 0 ; 1  3 4 5; 1 0 0 1; 1 9 0 8], aspect_ratio = :equal)  
gives the following figure:

The x axis of this plot is of course too wide; but then, the following script aimed to solve the problem by fixing the x range eliminates the effect of aspect_ratio = :equal:
using Plots
pgfplotsx()

heatmap([1, 2, 3, 4], [1, 2, 3, 4], [1 2 1 0 ; 1  3 4 5; 1 0 0 1; 1 9 0 8], 
aspect_ratio = :equal, xlim=(0.5, 4.5))

By inspecting the LaTeX code generated, the problem seems to be that heatmap, when asked to generate a figure with aspect_ratio = :equal, simply adjusts the scale of the x axis so that the main body of the heatmap becomes a square; but this is not what is intuitively expected: there is an axis equal image option for the axis environment in tikz, and, IMHO, this is what should be invoked when the aspect_ratio = :equal option is used.
Backends
This bug occurs on ( insert x below )



Backend
yes
no
untested




gr (default)





pythonplot





plotlyjs





pgfplotsx
x




unicodeplots





inspectdr





gaston






Versions
Plots.jl version: [91a5bcdd] Plots v1.36.1
Backend  version (]st -m <backend(s)>): [8314cec4] PGFPlotsX v1.5.1
Output of versioninfo():
Julia Version 1.7.3
Commit 742b9abb4d (2022-05-06 12:58 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, tigerlake)

Duplicate issue #4835: [BUG] `aspect_ratio` in conflict with `xlims` for PGFPlotsX
Created: 2023-10-22T14:50:30Z
Details
When aspect_ratio and xlims are used together, the former will be ignored by the PGFPlotsX backend.
using Plots
pgfplotsx()

let xs = 1:0.1:10
    plot(xs, xs.^2, xlims = (0, 10), aspect_ratio = :equal)
end
gives

which is the same as the case without aspect_ratio = :equal.
The problem doesn't exist with GR backend.
Backends
This bug occurs on ( insert x below )



Backend
yes
no
untested




gr (default)





pythonplot





plotlyjs





pgfplotsx
x




unicodeplots





inspectdr





gaston






Versions
Plots.jl version: 1.39.0
Backend  version (]st -m <backend(s)>): 1.6.0
Output of versioninfo():
Julia Version 1.9.3
Commit bed2cd540a (2023-08-24 14:43 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, tigerlake)
  Threads: 1 on 8 virtual cores
Environment:
  JULIA_EDITOR = code
  JULIA_NUM_THREADS =

Closing comment (2023-10-22T14:53:49Z): I realized this is a duplicate of #4766. The problem can be worked around by exactly the same way mentioned there.
Repository: JuliaPlots/Plots.jl

Issue #2129: support scalars for hline! and vline!
Created: 2019-08-07T09:26:36Z
It would be nice to have hline!(0.73) working instead of hline!([0.73]). The same goes for vline!.
Currently for floats it errors with No user recipe defined for Float64.
For Ints on the other hand I get a BoundsError attempt to access 0-element Array{Float64,1} at index [1].
I am 70 percent sure this worked about four weeks ago but if not then consider this a feature request :)

Duplicate issue #3898: [FR] Consider adding a method for vline and hline with single scalar
Created: 2021-10-24T18:03:51Z
This answer on Discourse is getting so much votes:
https://discourse.julialang.org/t/what-is-the-syntax-for-vline-in-plots-jl/1718/5?u=juliohm
It means that users are encountering this issue more often than what one would expect. Can you please consider adding a method for vline an hline that works with scalars? vline(1.0) for example. I don't know if this method exists as of today, but if it doesn't, it should probably be added? It will improve user experience.

Closing comment (2021-10-25T07:01:34Z): duplicate of #2129
Repository: JuliaPlots/Plots.jl

Issue #1869: Subplots do not scale correctly when using plotlyjs() with Plots.jl
Created: 2018-12-17T06:04:54Z
** Description **
The second subplot seems to scale correctly, but the first one scales through the whole figure. See attached image.
This issue only occurs when using plotlyjs(). If that is replaced by plotly(), everything seems to work fine. Please also refer to previous discussion in issue in PlotlyJS , which concluded in that the issue is with Plots.jl.
Minimum working example:
using Plots
plotlyjs()
p1=plot(1:10,1:10)
p2=plot(10:20,10:20)
plot(p1,p2,layout=(2,1))

Version info
Julia Version 1.0.2
Commit d789231e99 (2018-11-08 20:11 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, haswell)

** Pkg status **
  Status `~/.julia/environments/v1.0/Project.toml`
  [ad839575] Blink v0.9.0
  [336ed68f] CSV v0.4.3
  [e2554f3b] Clp v0.5.1
  [acd19e82] ClustAnalysis v0.1.0 [`../../dev/ClustAnalysis`]
  [fd0f8501] ClustForOpt_priv v0.0.0 [`~/.julia/dev/ClustForOpt_priv`]
  [aaaa29a8] Clustering v0.12.1
  [944b1d66] CodecZlib v0.5.1
  [a93c6f00] DataFrames v0.15.1
  [b4f34e82] Distances v0.7.3
  [5789e2e9] FileIO v1.0.4
  [2e9cd046] Gurobi v0.5.7
  [033835bb] JLD2 v0.1.2
  [4076af6c] JuMP v0.18.5
  [47be7bcc] ORCA v0.2.0
  [f0f68f2c] PlotlyJS v0.12.1
  [91a5bcdd] Plots v0.22.0
  [d330b81b] PyPlot v2.6.3
  [60ddc479] StatPlots v0.8.2
  [37e2e46d] LinearAlgebra 
  [10745b16] Statistics 
  [8dfed614] Test

Duplicate issue #1957: Layout bug using PlotlyJS backend
Created: 2019-03-17T15:53:30Z
I think there's a bug with the PlotlyJS backend when using a layout. Doing this:
# create a 4x1 grid, and map each of the 4 series to one of the subplots
plot(rand(100, 4), layout = (4, 1))
...results in this:

Closing comment (2019-08-07T21:04:59Z): dup of #1869
Repository: JuliaPlots/Plots.jl

Issue #1321: contour and contourf gives 3D plots with pgfplots(), ignore levels
Created: 2017-12-17T11:58:59Z
While on other backends contour and contourf are 2D, on pgfplots they are 3D and also ignore levels.
using Plots; pgfplots()
x = y = linspace(0,1,100)
plot(contour(x, y, +; levels = collect(linspace(0,1,5))),
     contourf(x, y, +; levels = collect(linspace(0,1,5))),
     size = (800, 400))
savefig("/tmp/fig.svg") # PNG file uploaded because Github does not take SVG

Duplicate issue #1478: contour with pgfplots() is actually contour3d
Created: 2018-04-08T17:43:14Z
Is there a way to get just contours?

Closing comment (2018-04-12T17:14:10Z): Thanks!
Closing as dup of #1321.
Repository: JuliaPlots/Plots.jl

Issue #3469: [BUG] `tickfontcolor` does not allow symbolic color
Created: 2021-05-04T07:25:41Z
Details
using Plots
plot(1:20, randn(20); size=(400, 300), tickfontcolor=:red)
The above code produces MethodError: MethodError: no method matching alpha(::Symbol).
However, if we specify the color with
plot(1:20, randn(20); size=(400, 300), tickfontcolor=colorant"red")
then it works as expected.
Backends
GR
This bug occurs on ( insert x below )



Backend
yes
no
untested




gr (default)
x




pyplot


x


plotly


x


plotlyjs


x


pgfplotsx


x


inspectdr


x



Versions
Plots.jl version: v1.13.2
Backend  version (]st -m):  GR v0.57.4
Output of versioninfo():
Julia Version 1.6.0
Commit f9720dc2eb (2021-03-24 12:55 UTC)
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: AMD Ryzen 9 5950X 16-Core Processor
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-11.0.1 (ORCJIT, generic)

Duplicate issue #3531: [BUG] GR: ticks options seem to be broken
Created: 2021-06-02T11:16:19Z
tickfontcolor throws an error related to alpha:

julia > plot(rand(10), fillrange=0, c=2, tickfontcolor=:white)

Error showing value of type Plots.Plot{Plots.GRBackend}:
ERROR: MethodError: no method matching alpha(::Symbol)
Closest candidates are:
  alpha(::RGB24) at C:\xxx\.julia\packages\ColorTypes\6m8P7\src\traits.jl:9
  alpha(::Color) at C:\xxx\.julia\packages\ColorTypes\6m8P7\src\traits.jl:8
  alpha(::ARGB32) at C:\xxx\.julia\packages\ColorTypes\6m8P7\src\traits.jl:10

the tickfontrotation changes the size instead of the angle

plot(rand(10), fillrange=0, c=2, tickfontrotation=40)

Backends: gr
This bug occurs on ( insert x below )



Backend
yes
no
untested




gr (default)
x




pgfplotsx

x




Versions
Plots.jl version:
[91a5bcdd] Plots v1.13.2

Backend  version (]st -m):
[8314cec4] PGFPlotsX v1.2.10

Output of versioninfo():
Julia Version 1.6.0
Commit f9720dc2eb (2021-03-24 12:55 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, skylake)
Environment:
  JULIA_EDITOR = code
  JULIA_NUM_THREADS =

Closing comment (2021-06-02T11:32:43Z): duplicates #3469
duplicates #1740
Repository: JuliaPlots/Plots.jl

Issue #889: For GR, `yflip` also flips the color bar
Created: 2017-06-05T20:30:54Z
using Plots; gr()
scatter(1:10, 1:10, marker_z = randn(10), yflip = true)

Arose here: JuliaPlots/PlotReferenceImages.jl#2
cc @jheinen

Duplicate issue #961: Colorbar label is flipped when yflip=true
Created: 2017-07-02T03:35:11Z
To reproduce the issue:
using Plots

X = rand(100,100)
heatmap(X, yflip=true)

Closing comment (2017-07-10T11:30:36Z): I think this issue only happens with the GR backend, right? And this is a duplicate of #889.
Repository: JuliaPlots/Plots.jl

Issue #2129: support scalars for hline! and vline!
Created: 2019-08-07T09:26:36Z
It would be nice to have hline!(0.73) working instead of hline!([0.73]). The same goes for vline!.
Currently for floats it errors with No user recipe defined for Float64.
For Ints on the other hand I get a BoundsError attempt to access 0-element Array{Float64,1} at index [1].
I am 70 percent sure this worked about four weeks ago but if not then consider this a feature request :)

Duplicate issue #3792: [BUG] Scatter has problems with scalar data
Created: 2021-09-03T15:03:08Z
Details
For some reason, I may need to plot some scalar data using scatter in 2D and 3D.
However, with the following examples I get either an empty plot or a failure.
using Plots
scatter(1,2,3) # <-- shows and empty plot with 3 legends
scatter(1.,2.,3.) # <-- fails with message "ERROR: Cannot convert Float64 to series data for plotting"
scatter([1],[2],[3]) # <-- works as expected (but is cumbersome)
This seem to lie before backend action.
Backends
This bug occurs on ( insert x below )



Backend
yes
no
untested




gr (default)
x




pyplot


x


plotly


x


plotlyjs


x


pgfplotsx


x


inspectdr


x



Versions
Plots.jl version: 1.21.3
Backend  version (]st -m <backend(s)>): N/A
Output of versioninfo():

Julia Version 1.6.2
Commit 1b93d53fc4 (2021-07-14 15:36 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-11.0.1 (ORCJIT, tigerlake)

Closing comment (2021-09-10T10:56:55Z): Same as #2129
Repository: KhronosGroup/MoltenVK

Issue #594: Dota: [MTLRenderPipelineDescriptorInternal validateWithDevice:]:2697: failed assertion `Pipeline rasterSampleCount (8) is greater than 1 but the pipeline vertex function is writing to render_target_array_index.'
Created: 2019-05-08T12:34:10Z
We shipped an update to Dota 2 last night and on some Macs (Macbook Pro 2018, Macbook Pro 2013 GT 650M) we are getting a crash when you click on a user profile.  Before the crash there is a Metal error:
[MTLRenderPipelineDescriptorInternal validateWithDevice:]:2697: failed assertion `Pipeline rasterSampleCount (8) is greater than 1 but the pipeline vertex function is writing to render_target_array_index.'
I'm going to probably ship a build that locally disables layeredRendering on macOS like I already do on iOS because of #579 .  This can be repro'd on public Dota by clicking on your user profile in the lower left of the screen.

Duplicate issue #579: MTLFeatureSet_iOS_GPUFamily5_v1 layeredRendering causes corruption
Created: 2019-04-24T18:17:31Z
I'm seeing corruption on MTLFeatureSet_iOS_GPUFamily5_v1 such as the iPhone XR.  I've narrowed it down to the fact that if I disable layeredRendering in MVKDevice.mm the problem goes away:
	if ( [_mtlDevice supportsFeatureSet: MTLFeatureSet_iOS_GPUFamily5_v1] ) {
		_metalFeatures.layeredRendering = false;
	}

As far as I can tell from the Metal GPU Frame Debugger, even though my vertex shader does not output [[render_target_array_index]] and my framebuffer was created with VkFramebufferCreateInfo.layers = 1, the Metal implementation appears to render two copies of my geometry, one outside the scissor/viewport I'm rendering to.  This causes corruption in the depth buffer.  There are no Metal Validation errors so it's not clear to me if this is a MoltenVK or driver bug.
I'm not sure of a simple workaround either.  If I try setting my VkFramebufferCreateInfo.layers = 0, then I get a Metal Validation error when it does a clear with the VS writing [[render_target_array_index].  For now I can workaround it by disabling layeredRendering (which I don't use anyway), but would like to understand the bug.
@cdavis5e @billhollings

Closing comment (2019-05-15T16:37:46Z): No longer considered a duplicate of #594. This is a different issue and was not resolved by #603.
Repository: KhronosGroup/MoltenVK

Issue #1765: Explore use of Metal Binary Archives for Vulkan pipeline caching
Created: 2022-11-10T20:16:09Z
At present, Vulkan pipeline caching (and external streaming of it) in MoltenVK supports recording MSL source code, to avoid having to convert SPIR-V to MSL for the shaders used by cached pipelines. This was built before Metal supported native pipeline caching.
With the introduction of Metal Binary Archives, it should be possible to properly support not only cached shaders, but cached Metal pipeline objects, which is expected to improve the performance of Vulkan pipeline caching in MoltenVK.
CTS makes extensive use of Vulkan pipeline cache streaming, so making this available should speed up CTS test runs.

Duplicate issue #1824: Support for VK_EXT_pipeline_creation_cache_control
Created: 2023-01-17T20:14:44Z
This extension is particularly useful for asynchronous pipeline compilation systems and will improve the experience for emulator users like Cemu and Citra. It can also reduce draw time hitching in applications by making vkCreateGraphicsPipeline calls predictable. Most desktop drivers support it nowadays so it would be nice to see it implemented in MoltenVK as well.

Closing comment (2023-03-06T17:39:20Z): Implemented by #1847. Please evaluate with latest MoltenVK code, and close this enhancement request if it meets needs.
With that PR, a cache hit is determined by finding MSL in the pipeline cache, even though the pipeline still requires compiling. Remaining activity includes using Metal Binary Archives to further reduce pipeline compilation times from the pipeline cache, as tracked in #1765.
Repository: KhronosGroup/MoltenVK

Issue #1657: Add line width support as optional compilation macro
Created: 2022-07-23T21:49:16Z
Hello, I'm trying to play No Man's Sky through Crossover and it says, "Does not support Wide Line". Does Metal 3 allow the use of Wide Lines or is it still not possible to implement?

Duplicate issue #1625: [mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkCreateDevice(): Requested feature is not available on this device.
Created: 2022-06-18T00:05:31Z
This error shows up for Mac when running a game through Crossover. I'm not much knowledgeable in this area but I've read somewhere that this is not supported on Mac, I think it's related to "wide lines". Could metal 3 potentially support wide lines, or is it still not possible?

Closing comment (2022-07-27T22:05:16Z): Closing as duplicate of #1657.
Repository: KhronosGroup/MoltenVK

Issue #56: Request for tesselation support
Created: 2018-02-26T14:26:24Z
just noticed MoltenVK has gone finally open source!
so just posting here request..
related to:
KhronosGroup/SPIRV-Cross#120

Duplicate issue #501: Is there any plan for Tessellation support in MoltenVK?
Created: 2019-02-18T09:46:31Z
It is understandable that geometry shaders are not supported in MoltenVK as this feature is not implemented in Metal2, but Tessellation is available.  Is this on the roadmap for future versions?

Closing comment (2019-02-18T22:31:31Z): Duplicate of #56.
Repository: KhronosGroup/MoltenVK

Issue #808: Maximizing the window makes the app run very slow
Created: 2019-12-31T20:40:33Z
For some reason, maximizing the application to full screen makes it run very slow. When the window is maximized but not full screen, it runs fine. When it is maximized and the title bar is shown, it also runs fine. The cube demo from the SDK runs fine.
Tested with 1.1.130.0 SDK on MacOS 10.15.
https://www.dropbox.com/s/6p9qrd4dnsvb8nc/Tutorial02_Cube.app.zip?dl=0
The app needs to be started from the command line so that the loader is able to find the dylib.

Duplicate issue #742: [MacOS] Very low performance with VulkanSDK 1.1.121
Created: 2019-09-20T09:02:15Z
Hi,
I am writing my own engine on C# using .Net core 3 and I wrapped macOS window to output my triangle demo there and it actually render, BUT....
I receive only ~140 FPS. I investigate a little and found out that calls to
vkCmdEndRenderPass(), vkEndCommandBuffer() and vkQueueSubmi﻿t()
takes toooo long and I have no idea why, but this is not the end.
Most interesting thing start when I swipe to another virtual screen on my mac and right after that FPS becomes ~5000 (which is actually it should be always)
And when I come back to screen where my window renders, FPS again becomes 120-140.
I dig here a little and found issues #486 and #602
Seems I faced with the same issues and one more thing I can say that I tested with presentWithCommandBuffer = false and synchronousQueueSubmits = false and in tyhis case there is no performance improvements, but during window resizing my windows gets closed sporadically and in output I see message that application was exit with code 11. I have no idea what it means, but when both values set to true, this happens much less often, but happens anyways sooner or later.
Can you please confirm that I am correct in my assumptions?

Closing comment (2020-01-06T15:44:16Z): @QuantumDeveloper @dimi309
Possible duplicate of #808?
Can you confirm that you were also using 2 swapchain images and that moving to 3 swapchain images fixes this?
Repository: KhronosGroup/MoltenVK

Issue #1209: Performance regession on Macbook Air (M1, 2020)
Created: 2021-01-20T21:09:29Z
I've bisected a perf regression of approximately ~4ms in Dota on Macbook Air (M1, 2020) at 1440x900 to 4440a64
I also confirmed that setting MVK_CONFIG_FAST_MATH_ENABLED=1 fixes the performance regression.
It's plausibe to me that this is the correct default for conformance, but I wanted to make it known that this was a significant perf regression on macOS.
Please let me know how you want to resolve this, I'm willing to turn on this feature in Source 2 if we want to keep MoltenVK the way it is.

Duplicate issue #1208: Performance regression
Created: 2021-01-20T13:14:03Z
We are observing that our app's on iOS run significantly slower with the current MoltenVK version, e.g. version ( 1.1.2, spec version 30 ) compared to a previous release ( 1.1.1 spec version 29 ).
Looking at the code differences, I can't see what is causing it, besides the new 'tileBasedDeferredRendering' feature.
Any idea why the latest MoltenVK is so much slower?

Closing comment (2021-01-29T20:58:18Z): Closing this as a duplicate of #1209.
Repository: KhronosGroup/MoltenVK

Issue #175: Support permanently open vkMapMemory() on coherent image memory
Created: 2018-06-08T20:35:17Z
Texture memory is not coherent on Metal. This means that when a texture is bound to a VkDeviceMemory that is coherent, it is not possible to leave vkMapMemory() open and have CPU updates to the memory automatically applied to that texture. In such cases, a vkUnmapMemory() call is needed to trigger the texture update...which MoltenVK detects and updates the texture.
Investigate whether coherent textures could be supported by:

Limiting coherent images to only a linear layout where only transfer operations are permitted (as per Vulkan spec)
Implement this simple linear texture using an underlying MTLBuffer instead of a MTLTexture
Internally...use Metal copy-to-and-from-buffer instead of copy-to-and-from-texture for these coherent images.
Limit the size of coherent images to the max size of a MTLBuffer...which is less than the max size of a MTLTexture.

Duplicate issue #377: Binding memory to an object after mapping results in an invalid mapped pointer
Created: 2018-12-09T17:33:09Z
I began experiencing strange memory corruption and crashes when dealing with host-visible mapped memory after updating MoltenVK on code that has no validation errors and no issues with Nvidia and Intel on Linux and Windows.  After building MoltenVK with the address sanitizer enabled I discovered the cause:
My application maps host-visible memory immediately after allocation but before it's bound to a buffer, the underlying behavior of which was changed in commit 958f56f inside MVKDeviceMemory.mm. Calling vkMapMemory() on an allocated chunk of host visible memory that has not yet been bound to a buffer results in an internal call to ensureHostMemory(), which allocates memory with posix_memalign() and returns the pointer.  When this memory is later bound to a buffer object via a call to vkBindBufferMemory(), MVK internally calls ensureMTLBuffer(), which frees the previously allocated memory and leaves the calling application that mapped the memory with a pointer that points to freed memory.
Basic repro steps:

Create a buffer object //vkCreateBuffer()
Get the buffer memory requirements //vkGetBufferMemoryRequirements()
Allocate host visible memory for the buffer //vkAllocateMemory()
Map and get a pointer to the host visible memory //vkMapMemory()
Bind the memory to the buffer //vkBindBufferMemory()
The pointer to the memory mapped in step 4 is now invalid and writing to it causes undefined behavior.

Closing comment (2018-12-10T02:11:43Z): It sounds like this is related to #175...but with VkBuffer instead of VkImage.
Since you are binding to a buffer instead of an image...this can probably be fixed by having vkMapMemory create a MTLBuffer instead of raw host memory...if the memory allocation is less than the max size of a MTLBuffer. When the VkBuffer is bound to the device memory...the existing MTLBuffer could be connected to it...instead of being copied into it.
Repository: KhronosGroup/glTF

Issue #9: converter should propagate original IDs from COLLADA files
Created: 2013-03-19T18:04:03Z

Duplicate issue #77: bug - wrong node id 
Created: 2013-04-26T03:17:36Z
here's collada:
       <visual_scene id="VisualSceneNode" name="untitled">
            <node id="LOD3sp" name="LOD3sp">
                <rotate...../rotate>
                <instance_geometry url="#LOD3spShape-lib">
                    <bind_material>
                        <technique_common>
                            <instance_material symbol="blinn3SG" target="#blinn3">
                                <bind_vertex_input semantic="TEX0" input_semantic="TEXCOORD" input_set="0"/>
                            </instance_material>
                        </technique_common>
                    </bind_material>
                </instance_geometry>
            </node>

here's gltf
 "nodes": {
        "node_0": {
            "children": [],
            "matrix": [

            ],
            "meshes": [
                "LOD3spShape-lib"
            ],
            "name": "LOD3sp"
        },

it should be:
 "nodes": {
        "LOD3sp": {
            "children": [],
            "matrix": [

            ],
            "meshes": [
                "LOD3spShape-lib"
            ],
            "name": "LOD3sp"
        },

Closing comment (2013-05-28T18:26:27Z): closing as a dup of #9
Repository: KhronosGroup/glTF

Issue #244: Converter generates incorrect rotation key frames
Created: 2014-02-26T20:58:48Z
A COLLADA model with the following animation (hand edited at this point) has five keyframes:
        <animation id="Geometry-mesh097_rotation098Z.ANGLE">
            <source id="Geometry-mesh097_rotation098Z.ANGLE-input">
                <float_array id="Geometry-mesh097_rotation098Z.ANGLE-input-array" count="5">0 0.5 1.0 1.5 2.0</float_array>
                <technique_common>
                    <accessor count="5" source="#Geometry-mesh097_rotation098Z.ANGLE-input-array" stride="1">
                        <param name="TIME" type="float" />
                    </accessor>
                </technique_common>
            </source>
            <source id="Geometry-mesh097_rotation098Z.ANGLE-output">
                <float_array id="Geometry-mesh097_rotation098Z.ANGLE-output-array" count="5">0 90 180 270 360</float_array>
                <technique_common>
                    <accessor count="5" source="#Geometry-mesh097_rotation098Z.ANGLE-output-array" stride="1">
                        <param name="ANGLE" type="float" />
                    </accessor>
                </technique_common>
            </source>
            <source id="Geometry-mesh097_rotation098Z.ANGLE-interpolations">
                <Name_array id="Geometry-mesh097_rotation098Z.ANGLE-interpolations-array" count="5">LINEAR LINEAR LINEAR LINEAR LINEAR</Name_array>
                <technique_common>
                    <accessor count="5" source="#Geometry-mesh097_rotation098Z.ANGLE-interpolations-array" stride="1">
                        <param name="INTERPOLATION" type="Name" />
                    </accessor>
                </technique_common>
            </source>
            <sampler id="Geometry-mesh097_rotation098Z.ANGLE-sampler">
                <input semantic="INPUT" source="#Geometry-mesh097_rotation098Z.ANGLE-input" />
                <input semantic="OUTPUT" source="#Geometry-mesh097_rotation098Z.ANGLE-output" />
                <input semantic="INTERPOLATION" source="#Geometry-mesh097_rotation098Z.ANGLE-interpolations" />
            </sampler>
            <channel source="#Geometry-mesh097_rotation098Z.ANGLE-sampler" target="Geometry-mesh097Node/rotation098Z.ANGLE" />
        </animation>
The rotation angles around Z are simply 0 90 180 270 360.  However, the converter generates the following axis-angle rotations, which include an axis flip:
[1, 0, 0, 0]
[0, 0, 1, 1.5707963705062866]
[0, 0, 1, 3.1415927410125732]
[0, 0, -1, 1.5707963705062866]
[0, 0, -1, 0]

Adding more keyframes (with shorter deltas between the rotation angles) does not fix the problem nor does changing the domain from [0, 360] to [-180, 180].

Duplicate issue #264: problem animation conversion
Created: 2014-04-08T23:48:00Z
The animation of this model, cat-skin.dae, doesn't work properly once converted.
https://github.com/amd/rest3d/tree/master/static/models/cat

Closing comment (2014-04-24T06:51:42Z): must be a dup of #244
Repository: KhronosGroup/glTF

Issue #339: Trouble converting Agisoft PhotoScan model
Created: 2014-11-30T23:28:23Z
PhotoScan exports a valid collada model that can be viewed in meshlab.  The converted glTF model isn't viewable in Cesium or glTF-webgl-viewer.  I'll send through the model to @fabrobinet.

Duplicate issue #342: Parts of a model disappear because blending is enabled
Created: 2014-12-31T13:31:40Z
I believe this is because the model was exported from SketchUp.  See the attached kmz (rename to zip) here: https://groups.google.com/forum/#!topic/cesium-dev/snu7ZhSNuwI
To get this model to display, I removed state 3042 from technique0 and technique1.
@fabrobinet do you have time to take a quick look at this?  I can send you a very simple model to reproduce this?

Closing comment (2015-01-01T23:12:00Z): @pjcozzi this is a duplicate of #339
You can verify that tranparency is 0 in the model you sent me. So the converter is behaving correctly.
Preview on OSX can display the model because they probably work-around by checking the sketchup version , as for a long time time, models exported with sketchup had inverted transparency... We'll probably add such check too but I have to figure out which sketchup version provides correct transparency.
Repository: KhronosGroup/glTF

Issue #154: handle case when no material is specified in mesh
Created: 2013-10-21T03:38:05Z
that's a converter issue, need to create a default material

Duplicate issue #194: Model created without material
Created: 2013-11-26T15:50:25Z
@fabrobinet I will send you the COLLADA model.
A simple skinned COLLADA model exported from blender is converted with collada2gltf without warning, but it does not generate any shaders nor does it include a material:
    "materials": {},
    "meshes": {
        "Cube-mesh": {
            "name": "Cube",
            "primitives": [
                {
                    "attributes": {
                        "JOINT": "attribute_40",
                        "NORMAL": "attribute_20",
                        "POSITION": "attribute_18",
                        "WEIGHT": "attribute_37"
                    },
                    "indices": "indices_16",
                    "material": "",
                    "primitive": 4
                }
            ]
        }
    },
Even if this is an issue with the Blender exporter, we need to handle this reasonably.

Closing comment (2013-11-28T21:39:14Z): That's a dup of #154 but this new issue got more info, so we'll keep it.
Repository: KhronosGroup/glTF

Issue #944: MIME Type & File Extension For Binary Buffers
Created: 2017-05-06T15:51:09Z
glTF 2.0 spec states that buffers with binary data must have .bin file extension and application/octet-stream MIME Type.
The latter applies both to external files (e.g., when they're served over HTTP) and Data URI-embedded buffers (because Data URI syntax requires specifying MIME type when it isn't text/plain).
Despite that glTF binary buffer is useless without JSON description, usage of such generic MIME Type (application/octet-stream) and file extension (.bin) could be sub-optimal:

lack of specific MIME Type complicates network data transfer, e.g., in cases when server wants to use transport-level compression (gzip-over-HTTP);
lack of specific file extension complicates server's configuration for such cases;
lack of specific file extension prevents desktop environments from recognizing such files (e.g., to show non-generic icon) because glTF buffers don't have any magic value at the beginning.

Proposal: register a new MIME Type for glTF binary buffers and use it instead of application/octet-stream. Also, optionally replace .bin file extension with a new one.
According to RFC 6838, Section 4.2.5, application/ top-level type seems to be the right place:

4.2.5.  Application Media Types
The "application" top-level type is to be used for discrete data that
do not fit under any of the other type names, and particularly for
data to be processed by some type of application program.  This is
information that must be processed by an application before it is
viewable or usable by a user.
...
The subtype of "application" will often either be the name or include
part of the name of the application for which the data are intended.

I think that it seems quite consistent to propose application/gltf-buffer.
Thoughts?
CC @pjcozzi @sbtron @bghgary

Duplicate issue #1323: Clarification needed for embedded buffer mimetypes
Created: 2018-04-23T19:07:20Z
I think there needs to be some clarification on acceptable mimetypes for embedded buffer base64 data.
On the one hand there's the actual spec and 32 out of 34 samples from glTF-Sample-Models that seems to imply the use of : data:application/octet-stream;base64
On the other hand is the the Picture diagram (colored boxes) and 2 out of 34 samples that seems to imply the use of : "data:application/gltf-buffer;base64
Which one is correct?

Closing comment (2018-06-01T15:58:50Z): Closing as duplicate. #944 tracks IANA approval process.
Repository: KhronosGroup/glTF

Issue #39: Add scene to spec
Created: 2013-03-22T12:31:47Z
I'd like to add scene to the spec.  Should we allow a glTF asset to contain multiple scenes?  Or is this something that should be negotiated  via a REST API?
I'm somewhat on the fence, but I believe the flexibility allowed by multiple scenes and the potential it brings to reduce the total number of round trips, makes it valuable compared to its downside, which is a slight increase in complexity.
Thoughts?

Duplicate issue #94: scene is missing the SPEC
Created: 2013-06-02T06:03:52Z

Closing comment (2013-06-15T01:01:54Z): dup of #39
Repository: KhronosGroup/glTF

Issue #1390: KHR_materials_unlit references baseColorTerm that does not exist in the spec
Created: 2018-07-16T16:17:00Z
At least not in the section where KHR_materials_unlit links, and I can't find it with Ctrl+F.

Duplicate issue #1391: Should a material using KHR_materials_unlit still use emissive?
Created: 2018-07-16T21:01:04Z
When present, the extension indicates that a material should be unlit and use available baseColor values, alpha values, and vertex colors while ignoring all properties of the default PBR model related to lighting or color
Emissive is not under pbrMetallicRoughness. Does this imply that the final color should really be baseColor + emissiveColor?

Closing comment (2018-07-16T21:40:12Z): Emissive should be ignored (and occlusion, for that matter). While they're not under pbrMetallicRoughness they are meant to be part of the default glTF PBR material. I'd rather list all of the properties unlit materials do use, rather than being exhaustive about what they don't (which may change if new properties are added), so related to #1390 perhaps this extension should list out each of the baseColor properties along with alpha-related properties?
Repository: KhronosGroup/glTF

Issue #424: Common Materials Extension
Created: 2015-10-06T17:02:07Z
https://github.com/KhronosGroup/glTF/tree/KHR_materials_common/extensions/Khronos/KHR_materials_common
Comments:

The JSON examples are inconsistent.  Both 1 and 1.0 are used.  Arrays are sometimes on the same line and sometimes one element per line.
index_of_refraction -> indexOfRefraction.  glTF uses camel case for property names.

Same for constant_attenuation, linear_attenuation, falloff_angle, and falloff_exponent.


Are we sure CONSTANT needs all those properties?  How is each used?
FLOAT_VEC4 or SAMPLER_2D -> In glTF, what is sampler 2D?  Shouldn't this be a string (texture id)?  We need to precisely define where the texture coordinates come from, e.g., if both diffuse and specular are texures, do they use the same or different set of texture coordinates?
technique - why does this have a default?  Perhaps it should be required.  We should also make this separate from the table and say the table is for the values object.
"relective": "texture_envmap" - glTF does not support cube maps.
This needs to include the equations.
This needs to include some discussion on how vertex attributes use semantics to map material inputs, e.g., normals, texture coordinates, etc.


To-do: Patrick need schema for each of the material types... can you help?

Maybe, but I did to finish the core spec reference doc first.  Will let you know later this week.

Duplicate issue #409: Directional and Spot lights need a direction vector
Created: 2015-09-15T21:35:21Z
If we're going to have lights at all-- which I think we should-- then we need a more complete spec for these two light types. They need a direction vector.

Closing comment (2015-10-08T00:40:20Z): Closing, moved to common materials extension. Duplicate of #424
Repository: KhronosGroup/glTF

Issue #2049: Consistent JSON schema version for core and extensions
Created: 2021-09-29T15:56:14Z
The JSON Schema version of the core specification has been updated from draft-04 to draft/2020-12 (via #2031 and #2034).
This raises some questions about the consistency of the specification. The core specification now uses draft/2020-12, whereas the extensions usually use draft-04. Without any guidelines or further actions, this could cause considerable fragmentation and inconsistencies.
Will the existing extension specifications be updated to also use draft/2020-12? (Who will do that, and how?)
Is there any guideline for the schema versions that extension specifications should use? (The section at https://github.com/KhronosGroup/glTF/tree/main/extensions#creating-extensions does not say anything).

Duplicate issue #2184: Different JSON schema versions in KHR extensions
Created: 2022-07-07T08:42:58Z
The glTF schema uses version 2020-12 while the KHR extensions use version Draft 4.
Would it make sense to update the extensions to the same version?
There are some differences between the schemas:

exclusiveMinimum, exclusiveMaximum are boolean in Draft 4, but numbers in newer versions. (This is used in e.g. the light extension)
in Draft 4 the required field must contain at least one string
Draft 4 only specifies "uri" as value for "format", newer version additionally support "uri-reference"

These are some more changes, but I think the exclusiveMinimum/Maximum rule is the only one where the extensions schemas needed to be changed.

Closing comment (2022-07-07T11:00:40Z): Although the title is the exact opposite, I think this is already tracked in #2049 , so I think it's OK to close this. (Drop me a note if not)
Repository: KhronosGroup/glTF

Issue #1822: glTF camera with parent scale
Created: 2020-06-05T16:50:50Z
A question come up recently with glTF camera with parent nodes that have scale. The spec doesn't explicitly say.

Cameras are contained in nodes and thus can be transformed.

Do we expect the scale of parent nodes of a camera to affect the camera's matrix?
See these two thread for some context (first one is not completely glTF related, but good for context):
https://forum.babylonjs.com/t/camera-minz-and-maxz-do-not-work-properly-when-camera-parent-is-scaled/11267
https://forum.babylonjs.com/t/camera-animation-messed-up-using-gltf-from-blender/11426

Duplicate issue #2217: What should clients do "When the provided camera's aspect ratio does not match the aspect ratio of the viewport"?
Created: 2022-10-14T18:25:18Z
The spec says this about perspective and orthographic cameras:

When the provided camera's aspect ratio does not match the aspect ratio of the viewport, client implementations SHOULD NOT crop or perform non-uniform scaling ("stretching") to fill the viewport.

https://github.com/KhronosGroup/glTF/blob/8e798b02d254cea97659a333cfcb20875b62bdd4/specification/2.0/Specification.adoc#3103-projection-matrices
So… What should be done instead?
I personally interpret this to implicitly specific either letterboxing or "zooming out" to fit the entire specified camera frame. But it should probably be made explicit I guess.
Currently Babyon and Three both seem to stretch, while the Khronos reference viewer doesn't.
EDIT: It appears this may have been left deliberately open for the application to choose: #2053 (comment)

Closing comment (2022-10-15T12:22:14Z): This is not the same as, but in some ways strongly related to #1822
In that context, I created a test asset with different camera configurations. The attached ZIP contains the asset, a short README describing the asset, and screenshots from three.js and babylon.js with the different configurations. In this example, the cameras always have an aspect ratio of 1.0, but the viewers already showed different behaviors.
Khronos Camera Scaling 2021-06-30.zip
(Note that this was created >1 year ago - things might have changed in the viewers, although that seems unlikely...)
Repository: KieronQuinn/TapTap

Issue #86: Battery drainage
Created: 2020-08-03T10:23:06Z
Samsung Galaxy S9, Lineage OS 17.1
no gates configured, app takes 10% CPU
I disabled the gates of both screen on and off in order to utilize it in different scenarios
I suppose that as a mitigation you could allow Tasker "to turn the app" on and off in certain situations that Tasker will define, this way the app will work in a certain use cases, - in other words is to allow Tasker become a gate or a tasker action to set it on and off
Keep up the great work!

Duplicate issue #122: Battery issues
Created: 2020-08-06T11:47:29Z
The app works perfectly, only issue is the battery drain. I've re enabled battery optimization for the app and noticed less battery drain when screen is off, but when the screen is on battery is draining a bit too fast and even charging is taking much more time (yes I've uninstalled the app and compared).
I'm on redmi note 7 pro

Closing comment (2020-08-06T17:11:39Z): @shivangchopra22 Duplicate of #86 Why not keep a common thread for battery issues than one for each device or person?