#Why is eng.displaydata an invalid image? (line 43 wgpu-native code)

65 messages · Page 1 of 1 (latest)

neat prism
austere sundial
#

your texture is bgra8 (4 u8s), but you then proceed as if it's 3 u8s (your Color is 3 u8s)

neat prism
#

Is it because the texture isn't being rendered?

austere sundial
#

i32(len(eng.displaydata)) is wrong too, that should be *3'ed from the looks of it, it should be amount of bytes not amount of rgb

#

afaik your shader codeSize is wrong too, that should be bytes too, this is u32s

neat prism
austere sundial
#

oh

neat prism
#

vulkan as well

austere sundial
#

well, stb doesn't at least

neat prism
#

Because compiled shaders are always a multiple of 4 byte length

#

for spirv at least

neat prism
#

after multiplying the length

austere sundial
#

in queuewritetexture slice.size(eng.displaydata[:]) is also wrong

austere sundial
#

just kidding

#

i think

#

yeah that should be bytes so it's fine

neat prism
#

Oh wait sorry, You were talking about the image array length

#

I'll change that

#

still errored

#

I found the issue though

#

displayimage is nil

#

the one that's image.load_from_memory

austere sundial
#

and you fixed the len you give that right

neat prism
#

do you think transmuting it is the issue?

austere sundial
#

try a fmt.println(image.failure_reason())

#

after trying to load

#

it probably wants an image file header or something

#

not even sure why you try to use an image loader when you are creating white pixels on your own and not actually using an image you need to load in

neat prism
#

The error is unknown image type

austere sundial
neat prism
#

let's stay on topic though

austere sundial
#

you already have decoded pixels, you don't have an image to load, you already have pixels

#

this is on topic, this is your issue 😆

austere sundial
#

Just a eng.displayImage = raw_data(slice.reinterpret([]u8, eng.displaydata)) should do it, no need for an image loader if you already have the pixel data

#

image loader takes a png, jpg etc. and decodes it into those pixels

neat prism
neat prism
#

@austere sundial

wgpu.CommandEncoderCopyBufferToTexture(command_encoder,&{
        buffer = eng.displaybuffer,
        layout = {
            bytesPerRow = 4*eng.config.width,
            rowsPerImage = eng.config.height
        }
    },&{
        texture = eng.displaytexture,
        mipLevel = 0,
        origin = {},
        aspect = .All,
    },
    &{
        width = eng.config.width, 
        height = eng.config.height, 
        depthOrArrayLayers = 1
    })

" In wgpuCommandEncoderCopyBufferToTexture
Copy error
Copy of 0..2073600 would end up overrunning the bounds of the Source buffer of size 8"

neat prism
#

Issue fixed, I was using datatyped instead of dataslice

neat prism
#

@austere sundial What do I need to do to constantly feed wgpu textures with different sizes?

#

as in the frames

neat prism
#

As displaydata's size changes, it gives size validation errors.

neat prism
#

@austere sundial

austere sundial
#

Recreate the texture with the size you need

#

Idk

#

If I knew a 100% answer I would have responded the first time you tagged me

neat prism
#

That's probably the answer

#

Didn't work, i'll look for a new one

#

I assume it's done via var<storage>

#

But for some reason that errors naga

austere sundial
#

Recreating the texture will work, there is no reason for it not to

#

You literally create a new texture, nothing to go wrong

#

Or not work

neat prism
#

Here's essentially what I do currently:

wgpu.QueueWriteBuffer(eng.queue,eng.displaybuffer,0,raw_data(eng.displaydata),uint(slice.size(eng.displaydata[:])))
    wgpu.CommandEncoderCopyBufferToTexture(command_encoder,&{
        buffer = eng.displaybuffer,
        layout = {
            bytesPerRow = 4*eng.config.width,
            rowsPerImage = eng.config.height
        }
    },&{
        texture = eng.displaytexture,
        aspect = .All,
    },&{
        width = eng.config.width, 
        height = eng.config.height, 
        depthOrArrayLayers = 1
    })
#

I feel as though learn-wgpu's implementation is wrong at least if you want to use it in a frame by frame basis, and you should just use writetexture instead

#

yeah, works just fine. how odd.