ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
shashanks has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
turol has quit [Ping timeout: 480 seconds]
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
turol has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
JuliaTatz[m] has joined #dri-devel
JuliaTatz[m] is now known as jtatz[m]
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
ayaka_ has joined #dri-devel
yyds has joined #dri-devel
DemiMarie has left #dri-devel [#dri-devel]
yyds has quit []
yyds has joined #dri-devel
youmukonpaku133 has quit [Ping timeout: 480 seconds]
Mary2 has joined #dri-devel
crabbedhaloablut has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
yyds has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
tristan has joined #dri-devel
sassefa has joined #dri-devel
tristan is now known as Guest876
ayaka_ has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
sassefa has quit [Quit: sassefa]
yyds has joined #dri-devel
maniacs has joined #dri-devel
<maniacs>
It is actually exactly meant that way, so where event loop is being polled DMA packets flow control the devices. https://thenumb.at/cpp-course/sdl2/06/06.html , it should be nothing but complex paradigm for any random programmers profile and not at all any headache for medium size maintenance team, it goes as fast as possible. I think dcbaker might merge his efforts to something like this instead of doing mindless work, i can spot some depression he
<maniacs>
has, same here i also do not want to do pointless work.
bmodem has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
junaid has joined #dri-devel
<maniacs>
So Cornell people also implemented the dma compute machine on chips that lack enough dma channels, like microchip that has no bus master ...however they called it, it only has 4system used channels, but this hack was also known to me, so on such chips the io uses slightly different ways, but those are microcontrollers, i am not aware of devices other than that totalling below 8 channels.
aravind has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
Duke`` has joined #dri-devel
ayaka_ has joined #dri-devel
sukrutb has joined #dri-devel
<Venemo>
Hey guys
<Venemo>
what happened to freedesktop gitlab? is it still down?
<emersion>
yes
<maniacs>
We run on those chipsets, an improved version slightly, dma controllers job is to print variables in the answer set and make gpio, so if you have 1024 intermediate answers, it can without enough dma channels use a bytemask on the offsets and decrement and increment, so it ends up being still very fast, cpu lifts it back to 32bit representation, cause with big numbers dma would delay otherwise, that happens only on some microchip controllers that are
<maniacs>
not GX or up enumerated.
maniacs was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
mvlad has joined #dri-devel
sima has joined #dri-devel
sumits has joined #dri-devel
An0num0us has joined #dri-devel
fab has quit [Quit: fab]
bmodem has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
bmodem has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
oneforall2 has joined #dri-devel
guru_ has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
vliaskov has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
sgruszka has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
pcercuei has joined #dri-devel
frieder has joined #dri-devel
konstantin_ is now known as konstantin
yyds has quit [Quit: Lost terminal]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
yyds has joined #dri-devel
Mary2 has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
Guest876 has quit [Ping timeout: 480 seconds]
Leopold_ has quit []
youmukonpaku133 has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest892
Guest892 has quit [Remote host closed the connection]
Ndfkjhw4 has quit []
Ndfkjhw4 has joined #dri-devel
sukrutb has quit []
Company has quit [Quit: Leaving]
ayaka_ has joined #dri-devel
thellstrom has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
<pq>
Lynne, I have so much FUD and paranoia about being legally tainted by dolby vision, that I'm hesitant to even want to know anything about it.
Ndfkjhw4 has quit []
lemonzest has quit [Quit: WeeChat 4.0.4]
lemonzest has joined #dri-devel
Ndfkjhw4 has joined #dri-devel
Ndfkjhw4 has quit []
Ndfkjhw4 has joined #dri-devel
hansg has joined #dri-devel
Ndfkjhw4 has quit []
aravind has quit [Ping timeout: 480 seconds]
Ndfkjhw4 has joined #dri-devel
<karolherbst>
maybe we have to work on a proper solution on how to deal with such proprietary technology like that, like in a more general sense and see if there is a way to move forward, even if that means not supporting such techs on a case by case basis. If we want the linux desktop to succeed, we also kinda need a solution for those problems and I'm wondering what we could do here to also protect developers getting involved with such IP heavy techs
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #dri-devel
cmichael has joined #dri-devel
rasterman has joined #dri-devel
slattann has joined #dri-devel
<slattann>
Test Mesg
frieder has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
frieder has joined #dri-devel
heat has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
bddvlpr has joined #dri-devel
<bddvlpr>
Hey, any updates on the GitLab downtime? Are there any available mirrors atm?
hansg has quit [Quit: Leaving]
bddvlpr has quit []
bddvlpr has joined #dri-devel
Ahuj has joined #dri-devel
<emersion>
you can join #freedesktop to follow along the latest updates, bddvlpr
rasterman has quit [Quit: Gettin' stinky!]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
maniacs has quit []
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
<Lynne>
pq: what it means is that you don't have to worry about it that much
<Lynne>
the blu-ray profile carries regular HDR with its main 4k stream, it's only when combining the extra stream that you need dovi processing
<Lynne>
as for the streaming profile, you can just let some other library optionally convert it to regular hdr
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<Lynne>
it's not going to light up the Dolby™ light on the TV or receiver, but if done properly, no one would miss it
<Lynne>
reminds me of the issue with ac3/spidf passthrough, even though hdmi supports uncompressed PCM, some users reported the dolby light does not come on unless ac3 is sent instead
<karolherbst>
if all those proprietary stuff could be dealt with inside userspace that would be very helpful indeed. Does something like that already exist and are the drawbacks known?
bddvlpr has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Quit: Quit]
youmukonpaku1337 has joined #dri-devel
youmukonpaku1337 is now known as youmukonpaku133
youmukonpaku133 has quit []
youmukonpaku1337 has joined #dri-devel
youmukonpaku1337 has quit []
youmukonpaku1337 has joined #dri-devel
yyds has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
<Lynne>
yeah, libplacebo supports the streaming profile (profile 7)
<Lynne>
drawback-wise, I guess if the target HDR colorspace is a subset of what the TV supports, and the TV has a better knowledge of what it supports such that it can better convert the dovi source into its own native colorspace
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Lynne>
but with displays these days needing dithering to get 10ish bits out of an 8-bit panel, not sure if that could happen
<pq>
I'm sure it can happen, as display metadata (EDID etc.) seems to be unwilling to tell what the display actually supports.
<pq>
as in, true hardware capabilities, rather than legacy colorimetry or desired signal properties
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
<gfxstrand>
zmike: Trying to become a moderator on all the channels? :P
<zmike>
no, I don't want to do it
<haasn>
yeah the whole point of dovi is for the dovi special chip inside the TV to do custom tone-mapping based on the known display characteristics
<haasn>
taking into account peak luminance at different window sizes
<haasn>
and power limits etc.
<haasn>
we can't replicate that in software without knowing all those details about the hardware
<haasn>
good luck
flynnjiang has joined #dri-devel
slattann has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
An0num0us has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
bddvlpr has joined #dri-devel
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
junaid has joined #dri-devel
fab has quit [Quit: fab]
An0num0us has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
kts has quit []
kts has joined #dri-devel
Haaninjo has joined #dri-devel
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
ap51 has joined #dri-devel
yyds has joined #dri-devel
ap51 has quit [Quit: leaving]
<karolherbst>
that's fair I guess, though something we can consider being a viable fallback or something
sgruszka has quit [Ping timeout: 480 seconds]
<pq>
If one is legally allowed to simply pass through dovi data, then that could be done if the dovi content is fullscreen and guaranteed exclusive.
<karolherbst>
I have by no mense actual knowledge about the HDR stuff here, I'm just trying to approach this issue from a consumer/user perspective. And if users/consumer want to have this all supported from an upstream kernel, I'm wondering how we can find a solution here to make it work for everybody.
greenjustin has joined #dri-devel
<pq>
The problem is that such pass through interface likely becomes dovi specific and useless for anything else, and I wouldn't know if that's ok.
<karolherbst>
could there be other proprietary formats like it? Maybe we need such an interface for formats where we just hand wave on the actual result and the hardware just does what it thinks is right
<karolherbst>
it's a pain issue, but I suspect there are users wanting to use that (or something similiar) today or in the near future
<Lynne>
I remember hearing from some company (plex, I think) that they were told that if they only pass the dovi data without processing it, they don't have to license anything, but I'm not a lawyer (especially not one of those super-paranoid layers who thinks it's okay to cut aac decode features from a library and still say it's compliant)
<pq>
or we need to make the open solution good enough, that dovi loses its appeal
<zamundaaa[m]>
pq: That is my biggest problem with it. Maybe in embedded use cases only playing HDR video well in fullscreen is fine, but I don't think it's something that would be good on desktop systems
<karolherbst>
Lynne: might help to have that in writing
<pq>
and for that I have big wishes for SBTM
<karolherbst>
yeah.. just annoying if you don't have the hardware for fancy new replacements
<pq>
I don't have any dovi supporting hw that I recall either
<karolherbst>
yeah well.. but random users might
Ahuj has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe it's also an non issue and it only matters for downstream/vendors/whoever
<pq>
I shall invest my time making open stuff better.
<karolherbst>
fair, and I don't think anybody expects that you specifical help implement all that stuff. And if nobody from the maintainers want to accept it, then that will be the end of this feature
<karolherbst>
but then we should be clear we don't want it so nobody wastes their time trying to upstream it
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. then no idea. Is it listed with clinfo at least?
<DavidHeidelberg[m]>
karolherbst: not listed: cmd: RUSTICL_FEATURES=fp16 RUSTICL_DEVICE_TYPE=gpu RUSTICL_ENABLE=radeonsi clinfo
<karolherbst>
mhhh
<karolherbst>
DavidHeidelberg[m]: mind debugging si_get_shader_param with PIPE_SHADER_CAP_FP16 inside si_get.c ?
<DavidHeidelberg[m]>
nvm, oops, I see it's not nightly :/
<karolherbst>
heh
<DavidHeidelberg[m]>
23.1.6-1 debian probably downgraded as FDO was down
<karolherbst>
might also be that radeonsi disables it by default
<karolherbst>
there is this `return sscreen->info.gfx_level >= GFX8 && sscreen->options.fp16;` check
<karolherbst>
and fp16 defaults to off
<karolherbst>
uhm.. false
<DavidHeidelberg[m]>
hmm, that's only for INT16
<karolherbst>
and PIPE_SHADER_CAP_FP16
<DavidHeidelberg[m]>
(ignore me, right falltrough)
<karolherbst>
fp64/fp16 is basically untested :)
<DavidHeidelberg[m]>
with LLM I think that's not going to be problem soon after people start playing with it
<karolherbst>
yeah... also LLM won't run into the broken parts
<karolherbst>
though if somebody gives me a non painful tutorial on how to do LLM stuff, I might even make sure it properly works and stuff
<karolherbst>
but...
<DavidHeidelberg[m]>
btw. I overriden the check in the program and it works
<DavidHeidelberg[m]>
(at least it seems)
<karolherbst>
yeah.. it should
<karolherbst>
the biggest issue are just denorms + missing libclc builtins
Dr_Who has quit []
<DavidHeidelberg[m]>
and we still don't talk about bf16 which isn't even in OpenCL spec :'(
<karolherbst>
no idea if anybody even works on it
djbw has joined #dri-devel
vliaskov has quit []
<karolherbst>
but supporting bf16 in mesa will be pain
<DavidHeidelberg[m]>
No mention anywhere, so it would be nice if secretly it'll show and everyone instantly supports it, but I'm too old to believe in fairy tales :D
<karolherbst>
it's going to be quite a bit of work sadly
<karolherbst>
or mhhh
<karolherbst>
is bf16 supposed to be faster than fp32 in terms of processing or just reducing memory bandwidth?
<karolherbst>
I'm sure we could just treat is as fp32 and only store /load16 bits....
<karolherbst>
unless there are GPUs supporting it natively
yyds has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
I assume it's mostly reducing memory consumption, if you have large LLM, it make sense to have a bit lower precision and more nodes?
<karolherbst>
ohh. I'm more wondering about alu speed, because on modern GPUs fp16 is twice as fast as fp32
<karolherbst>
if that's not the case with bf16, then it's fairly trivial to support
<DavidHeidelberg[m]>
btw. updated to nightly mesa-opencl-icd (as FDO is up now) and now rusticl works much better
* DavidHeidelberg[m]
quietly selling the debian nightly repo :D
idr has joined #dri-devel
<DavidHeidelberg[m]>
airlied: tinygrad producing reasonably quickly output on AMD XT 6800, first time. thou from 13.G now 15.7/16.3G ram is gone and MBytes disappearing quickly. I think more than one complex question won't fit into 16G :D
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
.. and it does some cleanup time to time, so maybe it'll work. Also while it not producing totally stupid things, I wouldn't let it to recommend me realiable BMW engine :D
<DavidHeidelberg[m]>
*VRAM cleanup
<mareko>
karolherbst: only RDNA 3 has BF16 and only for fdot and the cooperative matrix ops
lynxeye has quit [Quit: Leaving.]
<mareko>
BF16 for all FP ops is unlikely
junaid has joined #dri-devel
<mareko>
karolherbst: FP16 isn't 2x faster. It can be faster in marketing specs, but the reality is more complicated. RDNA 3 should have equal FP32, FP16, and Int16 performance in Wave64. Wave32 is more complicated and perf is compiler-dependent. RDNA 2 has half the theoretical ALU perf of RDNA 3. You can get 2x FP16 and Int16 perf on RDNA 2, but you have to generate vec2 16 ops to get close to what RDNA 3 has,
<mareko>
otherwise you're out of luck.
<Lynne>
do the matrix units support f16 or are they bf16 only?
<karolherbst>
mareko: sure, but nvidia claims being able to do twice as many fp16 ops than fp32, but I never actually checked
<karolherbst>
but yeah... I think we should probably model bf16 as fp32 in nir, otherwise it's going to be pain
<karolherbst>
and have instructions doing bf16 stuff that eat fp32? dunno...
<karolherbst>
or we use fp16..., but then float operations are going to be a mess
<mareko>
all marketing "claims" for FP32 and FP16 are only for fma16 and fma32 under ideal circumstances
<HdkR>
karolherbst: Make sure to fuzz which fp16 operations your hardware is missing :P
<karolherbst>
seems like nvidia only claims it for turing anyway
<mareko>
the problem with using fma to market GFLOPS is that fma is the only instruction that can do 2 ops per issue (mul+add), so it's at least 2x the performance of all other instructions
rsalvaterra has quit []
<karolherbst>
yeah, fair
<mareko>
even mov is 2x slower than fma, so 1/2 GLOPS for mov
<mareko>
*GFLOPS
jkrzyszt has quit [Remote host closed the connection]
rsalvaterra has joined #dri-devel
alyssa has joined #dri-devel
alyssa has quit []
smaeul_ has quit []
<karolherbst>
right, but this was about fp32 vs fp16, not fma vs anything else
siqueira_ is now known as siqueira
<mareko>
it's about the same perf on RDNA 3
<karolherbst>
okay, so the win is realy just less memory bandwidth
<mareko>
and register usage
<karolherbst>
yeah, in the optimal case
<mareko>
RDNA 3 can source half a GPR
<mareko>
and can select the low or high half
<mareko>
RDNA 2 must use vec2 to save registers
<mareko>
while RDNA 3 can just do register allocation at 16-bit granularity
eukara has quit []
mocoo has quit [Ping timeout: 480 seconds]
smaeul has joined #dri-devel
<mareko>
Lynne: they support fp16, bf16, i8, u8, i4, u4
smaeul has quit [Quit: Down for maintenance...]
smaeul has joined #dri-devel
eukara has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<Lynne>
ah, ok, I was wondering how the coop matrix extension would work, since vulkan doesn't make a distinction
<DavidHeidelberg[m]>
karolherbst: btw. iris also doesn't show fp16
mocoo has joined #dri-devel
<karolherbst>
yeah.. iris doens't support fp16 at all
<tnt>
What happens when you ask for a fp16 texture then ? It just uses fp32 ?
gouchi has joined #dri-devel
V has quit [Remote host closed the connection]
iive has joined #dri-devel
<Kayden>
your textures can be in whatever format you want, but when you request data from the sampler, it returns it as float32/sint32/uint32
<Kayden>
there is hardware support for fp16 send/return messages these days, and we ought to use it, but don't yet
<Kayden>
not as much as we should
<Kayden>
it got put on the backburner quite a bit because fp16 support was kind of mixed, in that there were a variety of painful restrictions, and performance was originally not really better, or in many cases not better - again, kinda complicated
<Kayden>
I think it's worth using these days
Haaninjo has quit [Quit: Ex-Chat]
oneforall2 has quit [Remote host closed the connection]
<karolherbst>
at least fp16 in CL is really just the alu stuff, and maybe that wouldn't be too hard to wire up
<karolherbst>
but it's kinda pointless without proper libclc support
oneforall2 has joined #dri-devel
junaid has quit [Remote host closed the connection]
V has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
youmukonpaku1337 has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fab has quit [Quit: fab]
mocoo has left #dri-devel ["Bye!"]
mvlad has quit [Remote host closed the connection]
crabbedhaloablut has quit []
V has joined #dri-devel
Dark-Show has joined #dri-devel
Dark-Show has quit [Quit: Leaving]
JohnnyonFlame has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
gouchi has quit [Remote host closed the connection]
pq has quit [Ping timeout: 480 seconds]
pq has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
bgs has quit [Remote host closed the connection]
konstantin has joined #dri-devel
Zopolis4 has joined #dri-devel
konstantin_ has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
An0num0us has quit [Quit: WeeChat 3.5]
<bnieuwenhuizen>
Lynne: the vulkan extension doesn't support bf16 and i4/iu :(
iive has quit [Quit: They came for me...]
<Lynne>
eh, you only need bf16 if you're doing NN stuff without taking care of normalization, there's plenty you can do with f16
urja has quit [Read error: Connection reset by peer]
<Lynne>
16x16 is a large block, you can implement a DCT or some other transform in just a matrix multiply
urja has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<Lynne>
as long as it's possible to justify the loading/storing overhead in case you need to gather samples
vsyrjala_ has joined #dri-devel
vsyrjala has quit [Ping timeout: 480 seconds]
shashanks_ has joined #dri-devel
kzd has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
Company has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
Zopolis4 has quit [Quit: Connection closed for inactivity]