alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
Stary has quit [Ping timeout: 260 seconds]
nerdboy has quit [Ping timeout: 268 seconds]
megi has quit [Ping timeout: 240 seconds]
Stary has joined #panfrost
vstehle has quit [Ping timeout: 240 seconds]
chewitt has joined #panfrost
nerdboy has joined #panfrost
chewitt has quit [Quit: Zzz..]
nerdboy has quit [Ping timeout: 240 seconds]
chewitt has joined #panfrost
vstehle has joined #panfrost
davidlt has joined #panfrost
nerdboy has joined #panfrost
icecrea105 has joined #panfrost
icecream95 has quit [Ping timeout: 240 seconds]
dcastagna has quit [Remote host closed the connection]
icecream95 has joined #panfrost
icecrea105 has quit [Ping timeout: 240 seconds]
chewitt has quit [Quit: Zzz..]
pH5 has joined #panfrost
robmur01_ has joined #panfrost
<daniels> icecream95: I wonder if 0x22 is one of the ASTC formats perhaps?
<robmur01_> so judging by that the same case was happening before, it just wasn't being screamed about
<robmur01_> what I don't know is whether RGBA formats are expected to have a sampler key, whether it's a mistake that we ever call into that at all for such formats, or whether the message is entirely spurious :/
<tomeu> alyssa: btw, I'm looking at a gles3 crash due to we not having a layer stride per level in 3d textures
<tomeu> that could explain some flip-flops, as some texture memory might be overwritten later
<robmur01_> re texture formats: I think those are configurable based on licensing, so beware that the "same" GPU on different SoCs (or potentially even different variants of one SoC) may have differing support. No idea about discoverability though :(
icecream95 has quit [Ping timeout: 268 seconds]
chewitt has joined #panfrost
robmur01_ has quit [Ping timeout: 260 seconds]
megi has joined #panfrost
BenG83 has joined #panfrost
klaxa has quit [Ping timeout: 252 seconds]
rcf has quit [Quit: WeeChat 2.5]
rcf has joined #panfrost
_whitelogger has joined #panfrost
abordado has joined #panfrost
_whitelogger has joined #panfrost
abordado has quit [Quit: Leaving]
raster has joined #panfrost
abordado has joined #panfrost
jolan has quit [Quit: leaving]
jolan has joined #panfrost
megi has quit [Ping timeout: 240 seconds]
megi has joined #panfrost
stikonas has joined #panfrost
<tomeu> alyssa: have pushed some more gles3 crash fixes to https://gitlab.freedesktop.org/tomeu/mesa/commits/panfrost-deqp-gles3
<tomeu> first one for tomorrow:
<tomeu> Test case 'dEQP-GLES3.functional.fragment_ops.blend.fbo_srgb.rgb_func_alpha_func.dst.one_minus_dst_alpha_constant_alpha'..
<tomeu> deqp-gles3: ../mesa/src/gallium/drivers/panfrost/pan_context.c:1039: panfrost_emit_for_draw: Assertion `!(is_srgb && blend[i].is_shader)' failed.
abordado has quit [Read error: Connection reset by peer]
abordado has joined #panfrost
chewitt has quit [Quit: Zzz..]
<alyssa> icecream95: It doesn't make sense that R32_SNORM and RG32_SNORM would ever not be supported, those are ~core formats needed for ES3.0
klaxa has joined #panfrost
<anarsoul> R32?
<alyssa> anarsoul: Integer formats
<alyssa> tomeu: Ah, nice
<alyssa> And yeah, I never got around to implementing sRGB blend shaders
<anarsoul> I see
pH5 has quit [Quit: bye]
stikonas has quit [Remote host closed the connection]
buzzmarshall has joined #panfrost
buzzmarshall has quit [Quit: Leaving]
buzzmarshall has joined #panfrost
pH5 has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
leinax has quit [Remote host closed the connection]
buzzmarshall has quit [Remote host closed the connection]
icecream95 has joined #panfrost
davidlt has quit [Ping timeout: 260 seconds]
icecream95 has quit [Ping timeout: 240 seconds]
cowsay_ has joined #panfrost
cowsay has quit [Ping timeout: 258 seconds]
icecream95 has joined #panfrost
<icecream95> It seems like *all* of the *32 formats and most of the *16 formats are broken, but maybe I'm doing something wrong...
<icecream95> Maybe we need to change one of the unknown fields in mali_texture_format to get them to work
<icecream95> Uh oh... I got this from dmesg: Fixing recursive fault but reboot is needed!
<alyssa> icecream95: Oops.
<alyssa> I don't suppose anyone has a T760 board + 64-bit blob handy?
<anarsoul> do these even exist? :)
<icecream95> Well yes, the kernel did panic with an Oops about 75 seconds later... :)
<alyssa> anarsoul: Unclear.
<icecream95> Why would it need to be T760? I only mentioned that because that's all I have...
<icecream95> I have the test program I used at https://gitlab.freedesktop.org/snippets/775
<alyssa> icecream95: I mean, on T860, the various *32 and *16 formats are for the most part working
<alyssa> So I'm assuming it's something specific to T760
<icecream95> It could be a problem with my test program, though. Could someone on T860 try it and see if formats like 0x65 work?
<alyssa> T860 is my main focus (and I expect the next big panfrost update will be ES3.0 for T860 only, other chips to follow)
<alyssa> anarsoul: They do exist, I think
<alyssa> Exynos 5433 looks like t760 + armv8
<alyssa> Exynos 7420 as well
<alyssa> (just looking at wikipedia)
leinax has joined #panfrost
<alyssa> icecream95: I'll take a peak in a moment
<icecream95> But do they run a 64-bit userspace...?
<alyssa> Let's find out..
<icecream95> Make sure the pixels are actually changing to random values and not just in a loop of two or three frames...
<alyssa> Maybe reviving 32-bit support for pandecode would be worthwhile but *shrug*
<alyssa> That's not something I'm able to support at the moment but we'll see what happens :)
<alyssa> Anyway, formats, let's see
<alyssa> icecream95: Could you explain how your test program works a bit?
<icecream95> The description of the snippet has some information
<icecream95> The texture is drawn in the top-left corner and is randomly updated
<icecream95> If you uncomment the SDL_RenderClear call it becomes a bit clearer
<alyssa> How can you tell if a format is working/notworking?
<icecream95> If the pixels are randomly updating and not in a loop, it's probably working. :)
* alyssa tries to build
<icecream95> The snippet has a small script for getting the hex values of the formats in panfrost-job.h to compare against.
<alyssa> /usr/bin/ld: main.c:(.text+0x48): undefined reference to `SDL_CreateWindow'
<alyssa> (etc for more SDL_* functions)
<icecream95> Are you linking it to SDL2?
<alyssa> Probably? -lSDL2
<icecream95> Maybe the -lSDL2 needs to be at the end
<alyssa> That did it
<alyssa> Black magic.
<alyssa> icecream95: Wow, watching this is mesmerising
* alyssa blinky
<alyssa> Anyway checking which format?
<alyssa> oh, you said 0x65
<alyssa> icecream95: oh.
<alyssa> That's a bug in your test methodology, sorry
<alyssa> If you trace it -- PAN_MESA_DEBUG=trace ./prog
<alyssa> and grep for XXX you'll see we spit out an error
<alyssa> linear // XXX: invalid components accessed
<alyssa> .bgr1: 640x480
<alyssa> .rgba r32_snorm // XXX: invalid components accessed
<alyssa> So the problem is that r32_snorm (0x65) only defines a single channel, but the swizzle we're providing accesses all four channels (since the driver thinks it's RGBA, since that's what it is except for this stealthy change of format code at the 11th hour)
<alyssa> Up to you how you want to resolve that, but you have access to both swizzles right where you do the format switcharoo :)
<alyssa> Next up, I guess, will be sRGB blend shaders so tomeu is unblocked
<icecream95> Making both swizzles just PIPE_SWIZZLE_X*4 doesn't change anything (except making everything greyscale)
<alyssa> Hm.
<alyssa> What about, like, X000?
* alyssa isn't confident about the exact hw requirements here
<icecream95> That doesn't help either...
<alyssa> Hrm.
<icecream95> Now I need to reboot again because of a recursive fault...
<alyssa> Do you mind sending the patch (with the swizzle)? I can take a look
stikonas has joined #panfrost
<icecream95> The 0x{6..}7 formats cause a null deref in drm_mm_takedown when quitting...
* alyssa blinks
<alyssa> That one's not on me I swear
NeuroScr has joined #panfrost
<alyssa> Okay, this is interesting
<alyssa> ld_color_buffer_u8_as_fp16 does sRGB->RGB conversion implicitly if necessary
<alyssa> But we have to do the RGB->sRGB conversion explicitly ourselves
<alyssa> Using a pair of ldst_op_09 opcodes I guess
<alyssa> tomeu: This could take some time
<alyssa> Oddly, this seems backwards from the behaviour I mention in the NIR comments, um
<alyssa> Lowering to ALU ops is an option in the interim, nir_format_linear_to_srgb looks like it'll do what we need and that hooks in nicely with nir_lower_framebuffer
BenG83 has joined #panfrost
pH5 has quit [Ping timeout: 260 seconds]
pH5 has joined #panfrost
stikonas has quit [Remote host closed the connection]
abordado has quit [Read error: Connection reset by peer]
BenG83 has quit [Quit: Leaving]