bnieuwenhuizen has quit [Ping timeout: 250 seconds]
raster has joined #panfrost
kaichi has quit [Quit: Leaving]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
<tomeu>
alyssa: wonder if we shouldn't store the sampler info in a gpu-independent way in panfrost_sampler_view, and then upload the right descriptors at draw time
<tomeu>
it's not that they are that big, and as long as we follow the rules about writing to uncached memory, should be fine
buzzmarshall has joined #panfrost
tbueno has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
cwabbott has quit [Remote host closed the connection]
cwabbott has joined #panfrost
<alyssa>
daniels: Alternatively, CL demands that the implementation is correct, and GL just does a big *shrug* and waves you through the CTS
<alyssa>
;P
<alyssa>
tomeu: Hmm? What's the benefit of doing it that way?
<tomeu>
alyssa: so the differences between midgard, bifrost, etc are more contained
<alyssa>
I'm not sure how that would help, though?
<alyssa>
In a perfect world, I'd think there would be a panfrost_create_sampler_midg and panfrost_create_sampler_bi pair of routines in root panfrost
<alyssa>
and then the CSO has union { midg; bi; }
<alyssa>
where would GPU independent sampler_view help? If you need to reference properties, that's already in the .base we keep :-)
<tomeu>
I'm just fearing having to debug state leaks in those descriptors if they are kept around and we have more than one version of them
<daniels>
alyssa: heh :) though you may note CL's native_* functions
<alyssa>
tomeu: I don't think that would be a big problem... at least, no worse than what we have now
<alyssa>
Those descriptors should be *immutable*
<alyssa>
once emitted, they should not be modified whatsoever
<alyssa>
in the rare case that you do something like switch on AFBC, the whole descriptor should be regenerated from ground up
<alyssa>
so no state to leak
<raster>
alyssa: any reason nir_native_to_shader() should need a special converter and not just use c_native ?
<raster>
ooh i missed a spot
<raster>
for PIPE_FORMAT_B5G6R5_UNORM i mean above
<alyssa>
raster: On chip, B5G6R5 is stored as a 16-bit field
<alyssa>
In the shader, when you read/write from it, you get 4x 32-bit floats (or fp16)
<alyssa>
So you need a routine to convert from packed 16-bit to unpacked floats
<raster>
interesting as nir_native_to_shader() and nir_shader_to_native() are not very symetrical in format handling
<alyssa>
yes, the file is very incomplete / minimal optimizations / probably broken
<alyssa>
Kinda hard to get right w/o ISA docs.
<raster>
aaah thats why i'm a bit confused
<raster>
so like PIPE_FORMAT_B5G5R5A1_UNORM is handled in nir_shader_to_native but seemingly not in nir_native_to_shader() as it wouldn't have homogeneous bits... and not util_format_is_unorm8()
<alyssa>
Yeah, incomplete
<raster>
got it
<alyssa>
Enough to write out rgb555a1 but not enough to read it
<alyssa>
(This is all for blend shaders, BTW.)
<raster>
yeah
<raster>
now it's making sense - i just kind of went "ok c_native is a special read/write that knows a set of common texture formats inside"
<raster>
i didnt hunt more
<raster>
like a native texture format :)
<raster>
got it
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
<raster>
oooh that be some rendering bugs
<raster>
thar be... i mean. pirate-like
nerdboy has joined #panfrost
cwabbott has quit [Ping timeout: 246 seconds]
cwabbott has joined #panfrost
nerdboy has quit [Ping timeout: 260 seconds]
<alyssa>
yarr harr, fiddle-dee-dee. do whatcha ya want..
cwabbott has quit [Quit: cwabbott]
nerdboy has joined #panfrost
nerdboy has quit [Ping timeout: 256 seconds]
bnieuwenhuizen has joined #panfrost
cwabbott has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 265 seconds]
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #panfrost
nerdboy has joined #panfrost
icecream95 has joined #panfrost
buzzmarshall has joined #panfrost
<mixfix41>
i was really having trouble with a arm bug in firefox browser did you guys experience it on armv7?
<mixfix41>
since panfrost enhances firefox so well and all that
<mixfix41>
but 72.0b2 gets it done though i think arch linux has not been experience this i would guess
<alyssa>
?
<mixfix41>
something where firefox ran only as root
<mixfix41>
and would seg fault as non root
<mixfix41>
so i was really absorbed since i launched firefox as root not knowing and was wondering how it ran from when i encountered the update
<HdkR>
Is it an ARM bug or just a permissions problem from having run it as root?
<HdkR>
strace it as the user to see if it tries accessing something and fails?
<mixfix41>
i might have those recorded.. i was doing that but to new to strace and the debug symbols are hard to complete a build
<mixfix41>
yea
<mixfix41>
if i changed Xauthority to root
<mixfix41>
it would launch with sudo
<mixfix41>
something hard coded
<mixfix41>
and simple(sp?)_ it felt
<mixfix41>
i came upon a bunch of threads yes its just armv7 32bit i think but i was wondering since the official precompiled package did this from slackware it would be more noted i guess