ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
columbarius has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
<airlied>
karolherbst: just rebasing the spirv-llvm-translator to later branches shouldn't be har
<airlied>
hard
camus has quit []
camus has joined #dri-devel
kunzite1 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kunzite has quit [Ping timeout: 480 seconds]
lina__ has quit [Quit: Reconnecting]
lina has joined #dri-devel
<airlied>
karolherbst: bumped to latest 160 branches
kunzite1 is now known as kunzite
LexSfX has quit [Remote host closed the connection]
aravind has joined #dri-devel
LexSfX has joined #dri-devel
bgs has joined #dri-devel
Duke`` has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit []
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
itoral_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Lightsword has quit [Quit: ZNC]
Lightsword has joined #dri-devel
f11f12 has joined #dri-devel
fab has quit [Quit: fab]
kunzite has quit [Quit: Leaving.]
sima has joined #dri-devel
jkrzyszt has joined #dri-devel
pcercuei has joined #dri-devel
kunzite has joined #dri-devel
tzimmermann has joined #dri-devel
kunzite has quit [Remote host closed the connection]
kunzite has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yuq825 has joined #dri-devel
kunzite has quit [Remote host closed the connection]
fab has joined #dri-devel
kunzite has joined #dri-devel
carbonfiber has joined #dri-devel
sgruszka has joined #dri-devel
kunzite has quit [Remote host closed the connection]
tursulin has joined #dri-devel
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
Company has quit [Quit: Leaving]
Ahuj has joined #dri-devel
jfalempe has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
Haaninjo has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
rasterman has joined #dri-devel
lemonzest has joined #dri-devel
kunzite has joined #dri-devel
apinheiro has joined #dri-devel
<karolherbst>
cool, thanks!
<karolherbst>
not sure what to do with the other problems though :/
<karolherbst>
that bump alone only fixes a handful of bugs, like `isnormal` and other operations. The opaque pointer stuff is a bit more invovled _though_ that only matters with generated spirvs with weird tooling
itoral_ has quit [Remote host closed the connection]
<CounterPillow>
Kind of weird DRM question: where on the sliding scale from single LED to 8K display do we make the cutoff of what a DRM panel is?
<CounterPillow>
is an addressable RGB LED strip that's controlled over SPI a potential 1xn DRM display, or should the LED subsystem handle that?
<pq>
hmm... would there be a "card" for it? What would be the DRM device for a led strip?
<CounterPillow>
I assume it'd work like SPI LCDs work currently
<pq>
Would you expect the led strip to used by programs that use KMS?
<CounterPillow>
Good point. We probably don't want to display a kernel framebuffer console on it, but we do kind of want to just throw pixel data at it instead of fiddling with individual LEDs through sysfs.
<pq>
good questions, and my guess is it depends on what userspace you expect to be able to run for it
<pq>
also, how awkward would the LED API be? I'm not familiar with it.
<CounterPillow>
Very awkward, you'd be opening multiple file descriptors through sysfs per LED
<CounterPillow>
I've sent a mail to the linux-leds mailing list to propose a new API for this awkward inbetween of "more than one LED, not a display". What speaks for making this not DRM is that pixel formats map badly to it https://lore.kernel.org/linux-leds/5324811.I0CZgJUjXn@archbook/T/
<CounterPillow>
What speaks for making it DRM is that a LED matrix is basically a display and any LED strip can be a LED matrix if you run it back and forth in strips
<pq>
what are those "wacky multi-colour" things, how do you drive them?
<CounterPillow>
Basically multi-colour LEDs that are not R/G/B but something like RGBW or Violet/Green or what have you
<pq>
more than 3 channels would be a problem for DRM pixel formats indeed
<pq>
but new pixel formats can be invented
<pq>
OTOH, if it's like 2-channel violet/green, you could use any 2-channel or palette pixel formats.
<linkmauve>
CounterPillow, I’ve seen people place LED strips on their ceiling, locate each LED, and then draw things using that.
<CounterPillow>
javierm: correct
<CounterPillow>
8bpc RGB almost maps nicely to pixel formats except for the 5-bit brightness which is per LED and not globally for all LEDs so modelling that brightness as a backlight would be a disservice to the capabilities
<javierm>
CounterPillow: the brightness could be handled by a separate backlight device IMO
<CounterPillow>
You could also use a driver chip like this and arrange its output LEDs in a matrix, as another example of how multi-LED devices work in practise https://www.ti.com/product/LP5036
<CounterPillow>
but a 6x6 12-bit-per-channel DRM panel feels a little silly
<javierm>
but I don't see why a LED strip couldn't have a DRM driver, it's not that different than small RGB or monochrome OLED panels
<MrCooper>
zmike: FYI, gitlab comments support a /duplicate quick action which marks the issue as a duplicate of and related to another issue (and closes it, if it's still open)
<zmike>
🤔
<pq>
huh, I could have sworn I've seen a RGB999E5 or another common-scale pixel format before
<robmur01>
CounterPillow: sounds similar to the debates around 7-segment displays that are a bit beyond the LEDs API but not really capable enough to fit into auxdisplay
<CounterPillow>
Yeah, if you ignore the brightness across all three channels that can vary for each pixel which you might want to do for contrast reasons :)
<CounterPillow>
I think I should just get some of these devices and write some drivers for them and see how terribly it goes, if there's a need for a new abstraction it will reveal itself
<javierm>
CounterPillow: right, but you can then take each channel 8-bit color value and combine with the backlight configuration (5-bit / 32 levels) and write that to the IC
<javierm>
there's no need for the latter to be encoded in the pixel format
<javierm>
it's less flexible yes, but it will operate as a normal panel
<CounterPillow>
Hmmm, yeah
<javierm>
doing it that way it means that you could use any user-space application, even fbdev user-space using the DRM fbdev emulation
<javierm>
because you could just expose a DRM_FORMAT_XRGB8888 format
<javierm>
you wouldn't be able to chose the brightness for individual pixels / RGB led colors, do I wonder how useful that is in practice
<CounterPillow>
And I guess for the LED driver with 36x12bitsx3channels I could either implement a cursed new pixel format or use XRGB161616 and scale the values
<CounterPillow>
oh nvm it's actually 36x12bits, I overestimated the channels by a factor of 3
<gfxstrand>
karolherbst: Not sure what you mean. I don't see any arrays there.
<karolherbst>
gfxstrand: soo.. with opaque pointers disabled, you have a direct chain from the printf call to the variable being a fixed size array
<karolherbst>
with opaque pointers enabled you have this bitcast in the middle dropping the size information
<gfxstrand>
Oh, well that's annoying.
<gfxstrand>
karolherbst: So how does that show up in the back-end? Is it getting an SSBO array length intrinsic or something?
leandrohrb5 has joined #dri-devel
<austriancoder>
has anyone ever tried to emulate OES_texture_float (PIPE_FORMAT_R32G32B32A32_FLOAT) with OES_texture_half_float (PIPE_FORMAT_R16G16B16A16_FLOAT)?
<karolherbst>
gfxstrand: the back-end doesn't really care, we just need the size information to extract the printf info
<karolherbst>
because it's pointing to a static array with the string as a constant
<gfxstrand>
karolherbst: Is there a bug about this? Or is printf doing something weird? How are we handling this case right now?
<karolherbst>
it's some fallout from moving to llvm-16
<karolherbst>
so libclc is built with opaque pointers enabled and it messes up a lot of those things
<gfxstrand>
:rolling_eyes:
<karolherbst>
because... LLVM implicitly upgrades to opaque pointers
<gfxstrand>
woo
<karolherbst>
and libclc is built like this: clang -> llvm-link -> opt -> llvm-spirv
fab has quit [Quit: fab]
<karolherbst>
so if clang emits with opaque pointers disabled, llvm-link converts it to opaque pointers enabled :D
<karolherbst>
that gives me a libclc like we get it with llvm-15
<karolherbst>
but I think we have to follow more closely how that stuff will look like once opaque pointers are more matured
<gfxstrand>
I mean, if the libclc being produced is busted, then patching it in LLVM seems like the right choice.
<karolherbst>
the translator has weird hacks to follow back pointer chains and stuff
<karolherbst>
it's just not always working
<karolherbst>
yeah...
<karolherbst>
_but_
<karolherbst>
the printf is actually still legal
<karolherbst>
and there is work on making the string dynamic as well
<karolherbst>
in any case, what we do is a bit too strict and getting a random pointer to constant memory without the size information is _legal_
f11f12 has quit [Quit: Leaving]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<gfxstrand>
karolherbst: Ugh...
<gfxstrand>
karolherbst: How's that supposed to work?
<karolherbst>
you encode which string it points to?
<karolherbst>
it still has to point to uniform constant memory
<gfxstrand>
But we're supposed to be able to parse the string from the SPIR-V parser.
<karolherbst>
just it might come from a phi source
<karolherbst>
from the opencl spirv extension thing: "format must be a pointer(constant) to i8."
<gfxstrand>
Yeah, just dug that up.
<gfxstrand>
We should file a bug and tell them not to do that.
<karolherbst>
gfxstrand: for now I think it's fine to follow the pointer chain and see if we hit a variable of static size and bail otherwise, because that's what OpenCL C without extensions only allows anyway
<gfxstrand>
I really doubt anyone is emitting fully generic printf code in kernels.
<karolherbst>
_but_ spirvs can do whatever they want anyway.
<karolherbst>
uhhhh
<karolherbst>
there are extensions for that
<gfxstrand>
fuuuuuuuu
<karolherbst>
not sure they are public yet :D
<gfxstrand>
Why?!? Why are we string processing in kernels?!?
<gfxstrand>
But also if there are extensions for that then people don't expect it to work today.
<karolherbst>
building the string inside the kernel is way too much work
<karolherbst>
however
<karolherbst>
selecting the string based on some condition is I think fine, and which we don't support atm
<karolherbst>
it's still.... bad but not as terrible
<gfxstrand>
:rolls_eyes:
<karolherbst>
but it is allowed do that already with spirv
<gfxstrand>
I mean, maybe? I guess we could select on string instead of parsing it.
<karolherbst>
we already encode the string as a constant, no?
<karolherbst>
so instead of emiting a constant, we emit a variable
<karolherbst>
wouldn't really change much
<gfxstrand>
I mean, maybe it could be okay.
<karolherbst>
we already encode it in the buffer we write to
<gfxstrand>
We would need to change the printf buffer format.
<karolherbst>
why?
<karolherbst>
it's already there
<karolherbst>
we just have to write a variable instead of a constant on the lowering side
<gfxstrand>
Right now, printf has a static list of strings, known at compile-time. What gets dumpped in the buffer is just the arguments.
<karolherbst>
and the string id
<gfxstrand>
Yes
<gfxstrand>
And we could support the current thing by just making the string id the pointer or something.
<karolherbst>
that's the only change, string id constant to string id variable (with current spec behavior)
<gfxstrand>
But if we want the generic thing, we can no longer pull strings out at compile time. We have to dump them into the buffer.
<karolherbst>
yeah.. I'd ignore the generic thing
<gfxstrand>
Because it might come from random global memory
<karolherbst>
that's a problem for future us
<karolherbst>
I have a stupid idea...
<karolherbst>
we kinda lower those printf strings like we lower images....
<karolherbst>
and it's just an index..
<karolherbst>
it kinda sucks, but...
<karolherbst>
dunno.. the first step would be to just follow back the chain and find the constant string and use that for now.. dunno
<karolherbst>
could also fix it properly
yuq825 has quit []
Danct12 has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<Venemo>
hi guys
<Venemo>
is it possible to write an algebraic patten in which there are certain rules between constants?
<Venemo>
for example, I'd like a pattern such as this: (('ubfe', ('ubfe', a, '#b', '#c'), '#d', '#e'), ('ubfe', a, b - d, c - e))
<Venemo>
but obviously this doesn't work
<gfxstrand>
No, not currently.
<Venemo>
and it is only feasible when b > d and c > e
<Venemo>
gfxstrand: what would you recommend to do for this pattern then?
<gfxstrand>
I've thought about how one might be able to do that but it's tricky.
<gfxstrand>
You'd need to implement the op in C
<Venemo>
I mean I guess I could write a loop and emit them one by one, but I feel that would be quite ugly
<gfxstrand>
And maybe just bail if there's a swizzle in between.
<Venemo>
I don't know what you mean by a swizzle here
<gfxstrand>
You have one ubfe reading another. If it swizzles between them, you'd need to account for that.
<gfxstrand>
Or just bail
<Venemo>
what does it mean, "it swizzles between them"
<gfxstrand>
If you have ubfe(ubfe(a, b, c).zyx, d, e)
<gfxstrand>
IDK if that syntax makes sense.
<gfxstrand>
One of the cool things about opt_algebraic is that it knows how swizzles work so it can produce ubfe(a.zyx, b-d, c-e)
<gfxstrand>
But if you're writing an opt in C, you either need to handle that yourself or just bail whenever you see a non-trivial swizzle.
<Venemo>
sorry, I've never dealt with swizzles ever, so I'm not sure
<gfxstrand>
Be thankful!
<Venemo>
I don't want to write it in C, though. would rather shoehorn it into opt_algebraic if possible
fab has joined #dri-devel
<zzxyb[m]>
Excuse me, I will import the gbm_bo on one drm device to the second drm device through gbm_bo_import, how can I convert it into a picture and save it on the disk through gbm_bo_map, i used code like this : gbm_bo_map(m_bo, 0, 0, m_width, m_height, GBM_BO_TRANSFER_READ, &m_stride, &m_map_data) ,result is empty,is it because I should not be GBM_BO_TRANSFER_READ this flag?
kzd has joined #dri-devel
<gfxstrand>
Venemo: We could loop, in the python but that's a LOT of new rules.
<pq>
zzxyb[m], by "empty" do you mean you can access the pixels but they are all zeros?
<Venemo>
gfxstrand: I suppose this would work too: (('ubfe', ('ubfe', a, '#b', '#c'), '#d', '#e'), ('ubfe', a, ('isub', b, d), ('isub', c, e))) <-- this would be constant folded, right? but I'm not sure how to express the constraint of b > d and c > e
<gfxstrand>
Yes, that would work if we can work out the constraints
<pq>
zzxyb[m], are you checking for failures at every step?
<Venemo>
I can't find in the current syntax how to do this :(
<gfxstrand>
We don't have a constraint syntax that lets you compare constants right nowl
<karolherbst>
just add new syntax: '#b(>d)' :D
<pq>
zzxyb[m], are you sure the image you are expecting has finished being drawn into the bo in the first place?
<karolherbst>
ehh wait..
<karolherbst>
those are just helper functions, right?
<pq>
that's all I can say now, I'll be back tomorrow
<gfxstrand>
Yeah, you can do `#b(greater_than_3) but not `#b(greater_than_d)`
<karolherbst>
mhhh
<karolherbst>
could support optional arguments to the helpers? mhh
<karolherbst>
could be messy
<zzxyb[m]>
pq: i mean return null pointer
<zzxyb[m]>
pq: i'm sure, because I used mmap to dump the image in bo to disk and checked
<zzxyb[m]>
because this image was sent to the display a little abnormally at the end, so I am troubleshooting,my working scenario is to complete the rendering on the first drm device, and then gbm_bo_import to the second drm device for display
<zzxyb[m]>
i'm sure drmModeAddFB is successful and has the correct framebufferid,no errors
<emersion>
null pointer would mean a map error
<emersion>
i don't think mapping will be supported with a "foreign" DMA-BUF
<gfxstrand>
Yeah, map + dma-buf is tricky
stalkerg has quit [Remote host closed the connection]
<zzxyb[m]>
the strange thing is that the same code can mmap on an arm device, the graphics card is mali, and the image is correct, but mmap reports an error (returns a null pointer) on X86, so i seek to use gbm_bo_map
<emersion>
one shouldn't mmap directly a DMA-BUF
<emersion>
this will mess up synchronization at the very least
sgruszka has quit [Ping timeout: 480 seconds]
<zzxyb[m]>
<zzxyb[m]> "image.png" <- I just want to verify the correctness of the image, after all, the display is abnormal after my pageflig.
<zzxyb[m]>
<emersion> "this will mess up synchronizatio..." <- then how do I verify that using gbm_bo_import on different drm devices is successful without any error,after all, my work scene is that the monitor connected to the second drm device is actually rendered and processed by the first drm device, and I just want to display the rendering result gbm_bo on the second monitor.i am using gbm_bo_import + drmModeAddFB + drmPageflip.the result ends up
<zzxyb[m]>
being displayed as a pattern of bars.it seems that there is no alignment, such as stride, size and other information
<zzxyb[m]>
i will double check the gbm_bo information returned by gbm_bo_import tomorrow to see if the width and height are correct
shashanks has joined #dri-devel
<DavidHeidelberg[m]>
zmike: hmm, it doesn't print the failing shaders, right? (From what I see)
<zmike>
yeah
<DavidHeidelberg[m]>
I'm putting on my to do :)
Fr0stBit has quit [Quit: WeeChat 4.0.0]
aravind has quit [Ping timeout: 480 seconds]
ayaka has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tursulin has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
benjamin1 has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab is now known as Guest4884
andrey-k- has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
danylo is now known as Guest4888
Net147 has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Ahuj has joined #dri-devel
abhinav__4 is now known as abhinav__
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
junaid has joined #dri-devel
junaid has quit []
junaid has joined #dri-devel
<austriancoder>
how bad is the idea that a nir phi would have a swizzle? I have some cases where nir_shrink_vectors could help.
rasterman has quit [Quit: Gettin' stinky!]
<jenatali>
I think alyssa would have strong opinions on that
<pendingchaos>
couldn't you use a nir_op_mov?
sima has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
eukara has joined #dri-devel
<austriancoder>
pendingchaos: need to check it but from quickly scanning over it I would say no :) oh.. important note.. I am in vec4 world. I have an undef that gets lowered to vec3 of 0.0f. and the pi uses it. But I would be smarter to to only have ssa_12.xxx instead of ssa_12. Will talk to Alyssa :)
CATS has quit []
dfip^ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
Guest4884 has quit [Quit: Guest4884]
Ahuj has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
Surkow_ has joined #dri-devel
Surkow|laptop has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
nehsou^ has joined #dri-devel
benjamin1 has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
a-865 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
gfxstrand has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]