vivijim has quit [Read error: Connection reset by peer]
mattrope has quit [Read error: Connection reset by peer]
jessica_24 has quit [Quit: Connection closed for inactivity]
gpoo has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
slattann has joined #dri-devel
<imirkin_>
erm ... why is textureGrad(sampler1DShadow) specified to take a vec3 "P" arg? seems like it should be a vec2, no? mesa and spec agree on vec3 though
Company has quit [Quit: Leaving]
orbea1 has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
orbea1 has quit []
orbea has joined #dri-devel
Duke`` has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
<pq>
haasn, I don't understand what you're trying to say. What I'm saying is, if you byteswap any 565 format, the result is not an existing pixel format at all.
<haasn>
and I'm telling you I don't byteswap any 565 formats
<haasn>
so I'm not sure why you keep bringing it up
<haasn>
as far as I'm concerned my problem was solved 3 days ago and your comments feel very out of place
<pq>
haasn, I'm bringing it up all the time, because byteswap is equivalent to switching between array-of-byte and bits-of-word conventions, and you sounded like you got that wrong.
<pq>
haasn, the problem in particular is that you said rgb565 and bgr565 were somehow confused with each other.
<haasn>
confusing "rgb" and "bgr" does not imply a byteswap
<pq>
haasn, sorry if you feel that way.
<haasn>
my point is entirely about the _TERMINOLOGY_
pochu has quit [Ping timeout: 480 seconds]
<haasn>
you can take the EXACT SAME format and either choose to call it "rgb" or "bgr"
<haasn>
this is essentially arbitrary
<haasn>
you're reading too much into it
<haasn>
if you can find a bug, patches welcome
<haasn>
otherwise I'll leave my code as is until I can observe any issues
<pq>
but you never make such arbitrary choices yourself, or are you creating a new formats definition?
<haasn>
yes to the latter
<pq>
oh!
<haasn>
and I use the drm convention but in the other channel order
<haasn>
which is endian independent
<pq>
drm formats are endian independent already. So you are listing channels from LSB to MSB, where DRM is listing them from MSB to LSB?
<pq>
...in bits, not bytes.
<haasn>
yes
<pq>
okay, and this has nothing to do with the array-of-bytes convention?
<haasn>
it does have something to do with the array-of-bytes convention because my convention is equal to array-of-bytes for byte-aligned formats, whereas DRM's is the other way around
<pq>
right
<haasn>
this is why e.g. for vulkan (which uses array-of-bytes sometimes and packed formats sometimes) you get e.g. drm rgb565 = vulkan rgb565 but drm rgba8 = vulkan bgra8
<haasn>
my convention (which calls drm rgb565 my bgr565 and drm rgba8 my bgra8) is consistent with vulkan for both types of formats
<haasn>
err, I mean it's consistent with both types of schemes
<pq>
cool
<haasn>
obviously my bgr565 is vulkan rgb565
<pq>
now I understand where you're coming from, thanks! :-)
<haasn>
tbh I personally hate dealing with format identifiers and always use format descriptors
<haasn>
e.g. when mapping from AVFrame to GPU formats I compare the actual channel masks
<pq>
do you do yuv formats too?
<haasn>
my API-agnostic GPU format descriptor struct essentially treats memory as a little endian bitstream (so in each 8-bit word, the LSB comes first)
<haasn>
and then a description of rgb565 would be "5 bits red, 6 bits green, 5 bits blue" in that order
<pq>
I see, you take little-endian down to the level of ordering bits in a byte conceptually.
<haasn>
for bgr565 to make sense even on a big endian platform you have to draw your bytes like (MSB...blue... green...red...LSB)
<haasn>
yes exactly, but that's entirely by convention because there's no hardware interpretation
<pq>
yeah
<haasn>
I always order my memory from LSB to MSB conceptually, whether dealing with bits, or bytes, it all just makes sense on a little endian platform
<haasn>
I don't do yuv formats, yet, no
<haasn>
mostly for... lack of a real motivating use case
<pq>
pixman is funny there, it has some <8 bpc formats where it actually reverses the bit order in a byte depending on the machine endianess :-)
<haasn>
even hardware decoders give you packed nv12 usually
<haasn>
yuv formats only exist for, like, interleaved YUVU or w/e it's called and I've never really come across it in the wild
<pq>
packed nv12? isn't nv12 defined as two planes?
<haasn>
well, it's usually called semiplanar
<haasn>
to distinguishe from planar YV12
<haasn>
though in that sense "packed NV12" is redundant, of course
danvet has joined #dri-devel
<haasn>
my point is that nv12 is not conceptually a YUV format, it's conceptually an r8 plane and an rg8 plane
frieder has joined #dri-devel
<pq>
um, by yuv, I mean the color model with often sub-sampled u and v. Sub-sampling being the main point, wondering how you'd represent that with a mask if it's a single-plane format.
<pq>
you'd have one "block mask" representing more than one pixel - do you do that?
frieder has quit [Remote host closed the connection]
<pq>
if you always have a plane per sampling density, then of course no problem.
frieder has joined #dri-devel
<haasn>
the latter, rather than trying to use masks here I probably would treat subsampled packed formats as opaque and use tables
<haasn>
or maybe come up with a struct solely for describing subsampled formats
<haasn>
since it's a rather odd case and most of the time I'd want to exclude them
<pq>
ok
<haasn>
something I'm actually wondering about, and can't find solid info on
<haasn>
What is the output of vkGetPhysicalDeviceVideoFormatPropertiesKHR on a supported driver?
<haasn>
Seems only nvidia proprietary supports it and vulkan.gpuinfo.org does not list those properties
<pq>
sorry, I'm really ignorant on Vulkan matters
Lucretia has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
mbrost has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
tarceri has quit [Read error: No route to host]
tarceri has joined #dri-devel
pcercuei has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
<DrNick>
I get the probably unfounded impression that AMD doesn't so much have documentation internally as commented Verilog/VHDL/etc.
<alyssa>
DrNick: Why would the VHDL be commented?
<DrNick>
to generate the poorly formatted PDFs
<alyssa>
Why would anybody need PDFs? 😉
<imirkin>
alyssa: yeah, the VHDL should just be self-explanatory
<alyssa>
imirkin: Exactly.
<Sachiel>
you need comments so that they get stale when someone changes the code without updating them
<alyssa>
Ah yes
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: wasn't there an option to dump the llvm ir in llvmpipe?
<danvet>
alyssa, yeah pretty all locking is broken, it's just a question of how badly
<danvet>
and usually "I'll fix this by (adding another lock|using atomics|using rcu| ...) just makes it all worse if you don't instead start with reworking your data structures
<karolherbst>
danvet: that was the suggestion I got for nouveau: just add locks, duh
<karolherbst>
but global state is really annoying
<imirkin>
karolherbst: pretty sure i warned you away from the "just add locks" approach...
<karolherbst>
imirkin: but you also warned me away from per context pushbuffers :p
<imirkin>
and i continue to think they're a bad idea
<karolherbst>
well, how to do that without locks
<imirkin>
well you need _some_ locks somewhere
<karolherbst>
so it's "just add locks" then :p
<imirkin>
but per-context pushbufs lead to the problems that you ended up with
<imirkin>
with unflushed things, things coming in out of order, etc
<karolherbst>
well, we don't have to
<imirkin>
so it's the same problem.
<karolherbst>
if we rework state tracking
<karolherbst>
we could always push the state we care about
<karolherbst>
and submit in one go
<karolherbst>
then we have an approach more like batches and won't need to lock
<danvet>
karolherbst, I think I really should type that blog post series
<danvet>
atm it's a multi-page rant on some internal doc
<karolherbst>
danvet: do it :p
jhli has joined #dri-devel
<danvet>
and very unstructured
<zmike>
sounds like it could use some locks
<karolherbst>
but we can be smarter and _save_ the old state and do some minimal locking on reading the current state and diffing it, which allows parallelism in building pushbuffers
<karolherbst>
which I have a prototype for
<karolherbst>
anyway.. this entire state tracking thing we have is very single threaded centric
<karolherbst>
best would be to just replace it with something entirely new
camus has quit [Remote host closed the connection]
<karolherbst>
it's not the hw which is the problem here, but our architecture
camus has joined #dri-devel
<karolherbst>
which was the point danvet was making all along here :)
<alyssa>
danvet: kernel in general seems extremely lock-y compared to userspace.
<karolherbst>
alyssa: yeah.. that as well
<alyssa>
otoh my userspace is just extremely race-y compared to kernel....
<karolherbst>
yeah well..
<danvet>
alyssa, on reason for that is that you have to deal with different contexts like interrupts vs threads vs async workers
<karolherbst>
worst case the process crashes
<karolherbst>
yeah..and you can't always "wait" or schedule your thing away
<alyssa>
danvet: nod.
<danvet>
so maybe a mutex for the thing overall, but then a spinlock to hand it over to workers and another spinlock to coordinate with the interrupt handler
<alyssa>
why can't I find the kernel version of MIN2
<karolherbst>
and some structures are inherently racy
<karolherbst>
like queues
<karolherbst>
although I think you _can_ make a queue without locks?
<danvet>
alyssa, min_t
<alyssa>
danvet: thanks
<alyssa>
annoyingly different than mesa
<karolherbst>
*differen than all other C
<danvet>
the other thing is that the kernel's job is about keepin track of everything and doing the occasional request on userspace's behalf, and almost never about doing anything useful
<karolherbst>
:D
<karolherbst>
true
<danvet>
so the ratio of "code that coordinates access" vs "code that does stuck" is seriously out of whack compared to userspace
<danvet>
*does stufff
<alyssa>
danvet: min_t vs min uhh
<danvet>
and if you do it right, code that does stuff should have no need for any locking at all
<alyssa>
can't tell if mesa's utils make more sense or I'm just drinking koolaid
<alyssa>
probably the latter
<karolherbst>
both
<karolherbst>
also, people have opinions on those topics
<danvet>
the typed thing is to avoid accidental integer type conversion, which often leads to some neat security bug
<karolherbst>
we also have no functional hashtable impl in the kernel ¯\_(ツ)_/¯
<karolherbst>
guess nobody needed it
<danvet>
integer ids with xarray
<karolherbst>
uhhh
<karolherbst>
I needed a hashset for stuff
<karolherbst>
did lists instead then
<karolherbst>
it was just for debugging anyway
<alyssa>
danvet: oof
<alyssa>
aside-- single most annoying part of kernel dev so far has been include/ being separate from src
pochu has joined #dri-devel
<danvet>
alyssa, doesn't need to be for your own driver, that include/ should only be for stuff shared across areas
<danvet>
like include/drm has the driver interface
<danvet>
and drivers/gpu/drm/drm*.h has various internal things
<alyssa>
danvet: right, I mean to find details about interface for DRM or whatever
<alyssa>
lot more jumping around
<danvet>
git grep and cscope or your lost anyway
<danvet>
I frankly have no idea where most stuff is :-)
Moiman has joined #dri-devel
<alyssa>
Fair.
<alyssa>
Mesa is a lot easier to keep in head
<danvet>
well I also have no idea where stuff in mesa is :-)
<alyssa>
:)
<alyssa>
the lack of unit testing in kernel space, ik
* alyssa
copies some kernel code and writes the unit test in userspace
jessica_24 has quit [Quit: Connection closed for inactivity]
iive has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
pochu has quit [Ping timeout: 480 seconds]
rib_ has joined #dri-devel
lemonzest has quit [Quit: Quitting]
unrelentingtech has quit [Ping timeout: 480 seconds]
unrelentingtech has joined #dri-devel
rib has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pnowack has quit [Quit: pnowack]
sylware has quit [Quit: sylware]
frieder has quit [Remote host closed the connection]
DPA has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
pnowack has joined #dri-devel
shfil has joined #dri-devel
jessica_24 has joined #dri-devel
<danvet>
alyssa, kunit is a think
<imirkin>
there's also kselftest?
<danvet>
also, we added selftests in drm with igt wrappers, but they're not yet converted to kunit
<imirkin>
a couple of options depending on what one needs i think
<danvet>
imirkin, those are not unit tests, but tests that run in userspace
<danvet>
like igt
<danvet>
unit-tests you need to link to get at all the internals
<danvet>
kunit is the thing for that, and for a fresh start probably the right thing
<danvet>
for drm and i915 we simply started before kunit was a thing so had to hand-roll
<danvet>
iirc kunit builds a full kernel and then runs that under uml in userspace to run your unit test
<danvet>
so that you don't have to scaffold the entire kernel lib/ infrastructure and everything else
<alyssa>
danvet: kunit, hmm
dogukan has quit [Quit: Konversation terminated!]
xexaxo_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<airlied>
ajax: I did dream about making vk sw path be more like dri3 using multiple mit-shm and xshmfences
<ajax>
yes please
<ajax>
drisw too please
<airlied>
drisw is harder, because how many layers can you put in one place :-P
<airlied>
but vk sw should at least be good to validate the idea
<ajax>
the more we make sw and dri3 buffer management look the same, the less code needs to care about the difference
* airlied
will see if your nerd snipe is successful later :-P
<ajax>
unrelated: can anyone think of a good reason you shouldn't be able to override renderbuffer attachments for the default framebuffer, at least for the non-front-or-back buffers?
<ajax>
like: please can i use a non-depth-stencil fbconfig and then only attach them if a rendering pass starts to need them
jhli has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
rando25892 has quit [Ping timeout: 480 seconds]
jhli has joined #dri-devel
rando25892 has joined #dri-devel
<imirkin>
what ext added layout(location=X) to e.g. VS outputs?