daniels has quit [Read error: Connection reset by peer]
daniels has joined #etnaviv
_whitelogger has joined #etnaviv
_whitelogger has joined #etnaviv
_whitelogger has joined #etnaviv
_whitelogger has joined #etnaviv
<wumpus>
dv_: yes, I remember that too, at least for R8. RGB8 never surprised me 24-bit render targets are extremely uncommon.
<austriancoder>
dv_: r8 works starting with halti5 and r8g8 starts with halti2 - what gpu are you working with?
<wumpus>
oh rg88 sorry
<dv_>
austriancoder: GC7000NanoUltra
<dv_>
also, I was wrong apparently. renderbuffers with R8 / RG88 EGLImages didn't work as color attachments. but 2d textures with R8 / RG88 EGLImages did.
<dv_>
so it ain't a GPU limitation, unless this is a false positive.
<dv_>
btw. is v4l2 mem2mem the next best thing we have in mainline for providing userspace access to 2D graphics cores on embedded devices?
<dv_>
like the viv pixelengine
lrusak__ has joined #etnaviv
lrusak_ has quit [Read error: Connection reset by peer]
pcercuei has joined #etnaviv
_whitelogger has joined #etnaviv
<marex>
dv_: thats gc600, so pre-halti, no ?
<marex>
or maybe gc600 already has some basic gles3 support in hardware ?
cphealy_ has joined #etnaviv
<dv_>
hmm ... it seems that it doesn't support R8 / RG88 after all
Chewi has quit [Ping timeout: 260 seconds]
<dv_>
that is, for output
Chewi has joined #etnaviv
<marex>
dv_: which SoC is that, MX8MM ?
<dv_>
yea
<dv_>
what I am trying to do is an RGB -> NV12 conversion
<dv_>
G2D cannot output NV12, and the imx8mm has no IPU that could do that
<dv_>
so I figured I could do this with GLES shaders instead
<dv_>
but since R8 and RG88 do not seem to be available for output, I'll have to do some tricks with XRGB8888 , for example, writing 4 Y values at once etc.
<dv_>
IIRC, the viv GPUs can do YUV -> RGB internally, but not the other way round?
<cphealy_>
The Vivante GPUs can do YUV -> RGB in the texture sampler IF the YUV format is packed, meaning YUY2/YUYV.
<cphealy_>
If it's a semi-planar or fully planar YUV format, the GPU will have to do the conversion using the shader.
<cphealy_>
With YUY2/YUYV, the CSC from YUV to RGB is basically free. With NV12 being done in the shader, this is not free and comes with an increased per-pixel shader cost.
<cphealy_>
dv: Which Vivante GPUs are you working with? Different GPUs support different render targets.
<dv_>
GC7000NanoUltra
<cphealy_>
Hmm, interestingly, I see reference to YUV resolve formats with the i.MX6qp (GC3000) but not with either of the i.MX8M (GC7000Lite) or i.MX8MM (GC7000NanoUltra).
<cphealy_>
This is from the associated reference manuals.
<cphealy_>
In the case of the i.MX6qp (GC3000), only packed YUV formats are supported for destination.
<cphealy_>
The 2D GPU definitely appears to support taking RGB output from the 3D GPU as an input and converting it to a YUV destination.
<cphealy_>
From what I recall, Pengutronix submitted some patches for upstream that used the 2D GPU in the i.MX6 to do a YUV to RGB conversion when importing video to the 3D GPU. Perhaps some of this code could be used as a starting point for extending the 3D GPU capabilities of the i.MX8MM such that the GC7000NanoUltra can advertise YUV as a supported render target?
<dv_>
well, currently, I use G2D for compositing a frame with the 2d core
<dv_>
problem is, I also need to encode these frames, and the encoder only supports NV12 from what I can see
<dv_>
but this may be a G2D limitation, not one of the GPU's pixel engine
<dv_>
so if anybody knows whether or not the 2D hw itself actually _can_ output NV12, please let me know
<cphealy_>
I may not be fully understanding what you are asking but when I look at Table 14-3 of the NXP i.MX8MM reference manual, I see that packed YUV (YUYV and UYVY) are supported destination formats AND in the section for the Hantro H1 encoder, it seems that not only are these same formats supported but also the Hantro H1 encoder has a "pre-processor" that can convert from RGB to the necessary YUY formats. As such, it seems to me
<cphealy_>
that there are two different paths available to achive the desired goal of encoding the GPU output: 1) have the 2D GPU do the RGB to YUV conversion before giving it to the Hantro H1 encoder 2) Have the GPU give the Hantro G1 RGB and the Hantro does the RGB to YUV conversion in it's pre-processor.
<dv_>
right. forgot to explain. I am currently using an imx8mm, but the target hw is an imx8qm. I am going to receive imx8qm hardware, but I dont have it atm.
<dv_>
so I am trying to target imx8qm capabilities as good as I can.
<dv_>
what also doesn't help is that there is no publicly available imx8qm reference manual for some mysterious reason, so I had to deduce from the imx-kernel sources that the encoder on the imx8qm (which is not a hantro one) can only do NV12.
<cphealy_>
Ohh, the 8 Quad Max, that's definitely different... Let me take a look a that as the Hantro H1 obviously does not apply there.
<marex>
cphealy_: the MX8MM is GC600, it is nowhere near the GC2000/GC3000
<marex>
cphealy_: those two could do YUV sampling, although the performance was meh
<marex>
dv_: why do you even need to render to NV12 ?
<marex>
oh, because you evaluate for completely different hardware, I see
<marex>
cant you use MRT on the MX8QM with gc7000l to generate the nv12 planes ?
<marex>
basically render stuff into buffers with offsets ...
<dv_>
I've been working on that, yes
<dv_>
if however the hw has dedicated support for this, I'd prefer that
<dv_>
getting CSC to work correctly EGL+opengles+dmabuf (for zerocopy) is a nontrivial amount of work, and many things can get subtly wrong
<dv_>
marex: also, R8 and RG88 do not work as output rendertargets
<dv_>
so I have to do some trick: fool the hw into thinking that this is ABGR8888, and in the shader, write the values of 4 pixels in a row at once
<dv_>
this works .... kind of
<dv_>
it would be quite simpler and more robust with proper R8 / RG88 output support though
<cphealy_>
marex: MX8QM has the big GC7000, not the GC7000l. Perhaps you are confusing the MX8QM for the MX8MQ? (Thank you NXP for making things so obvious!) ;-)
<dv_>
it also has opengl ES 3.0 support IIRC, so it can output to multiple drawbuffers at once
<dv_>
right now I need to do multipass, which of course eats bandwidth
<cphealy_>
marex: I see what you are saying in the wiki article. I think it's a little deceiving. I'm looking at a presentation that says the following: i.MX8MNano - GC7000Ultralite i.MX8MMini GCNanoUltra i.MX8MQ - GC7000Lite i.MX8QuadMax - GC7000XSVX
<marex>
dv_: if you git grep for VPU_PF_, it seems the malone can at least do YUYV sampling
<marex>
dv_: and then some tiled format too, probably for direct output from the GPU without detiling pass
<dv_>
I only see YUYV in that vpu_b0.h header
<dv_>
wonderful, crystal clear filenames btw
<marex>
cphealy_: ideally someone would just run etnaviv on MX8Q and read out the registers, then we know for sure
<dv_>
NV12 however appears in multiple places in .c files
<cphealy_>
ack
<marex>
dv_: well, maybe you need to patch the driver slightly, or do more work and help getting it upstream proper
<dv_>
based on what specification? :)
<dv_>
its all behind NDAs
<dv_>
it would be awesome if malone could do YUYV though
<dv_>
or YUY2
<dv_>
easier to do in shaders & would work as rendertarget with the pixelengine
<marex>
dv_: it seems the hardware might even be able to do that, hint is above
<dv_>
yup
<dv_>
however, since that hw is not here yet, I can't rely on such speculations atm
<dv_>
I do however have an imx8m non-mini. that is, an imx8mq.
<dv_>
I'll see what I can do with its GPU.
<dv_>
hm, interesting. newest imx-kernel also mentions a "windsor" encoder. also from amphion I suppose.
<marex>
dv_: I'd say, read the datasheet, look at that specific YUYV bit, and then you will know
JohnnyonF has quit [Read error: Connection reset by peer]