ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<jekstrand>
karolherbst: In case you look at it while I'm asleep, rusticl/ojbect-wrappers
<jekstrand>
karolherbst: I've got everything but Device converted, I think.
<jekstrand>
Oh, and context
fxkamd has quit []
mbrost has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
mbrost has joined #dri-devel
iive has quit []
tursulin has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
lplc has quit [Ping timeout: 480 seconds]
linearcannon has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
mhenning has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jewins has quit [Quit: jewins]
jewins has joined #dri-devel
LexSfX has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
linearcannon has joined #dri-devel
mbrost has joined #dri-devel
katp32 has joined #dri-devel
katp32 is now known as Guest1180
Guest1180 is now known as katp32
Wally has joined #dri-devel
romangg has quit [Server closed connection]
romangg has joined #dri-devel
fahien has quit [Server closed connection]
fahien has joined #dri-devel
katp32 has left #dri-devel [#dri-devel]
vsyrjala has quit [Server closed connection]
vsyrjala has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
jadahl has quit [Server closed connection]
jadahl has joined #dri-devel
Adrinael has quit [Server closed connection]
Adrinael has joined #dri-devel
cworth has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
mntmn has quit [Server closed connection]
mntmn has joined #dri-devel
Wally has quit [Remote host closed the connection]
ceyusa has quit [Server closed connection]
ceyusa has joined #dri-devel
shashanks has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Company has quit [Quit: Leaving]
marcan has quit [Server closed connection]
marcan has joined #dri-devel
Wally has joined #dri-devel
devilhorns has joined #dri-devel
devilhorns has quit []
oneforall2 has quit [Remote host closed the connection]
mclasen has quit [Remote host closed the connection]
Wally has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Wally has joined #dri-devel
shankaru has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
i-garrison has quit []
i-garrison has joined #dri-devel
Wally has quit [Remote host closed the connection]
<DrNick>
stacking multiple meson devenvs could be more elegant
adavy has quit [Server closed connection]
LexSfX has quit []
kts has quit [Quit: Konversation terminated!]
LexSfX has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
LexSfX has quit []
Duke`` has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
Viciouss has quit [Server closed connection]
Viciouss has joined #dri-devel
mbrost has quit []
nchery has joined #dri-devel
shankaru has quit [Quit: Leaving.]
danvet has joined #dri-devel
shashanks has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
thellstrom has joined #dri-devel
Koniiiik has quit [Server closed connection]
Koniiiik has joined #dri-devel
itoral has joined #dri-devel
pnowack has joined #dri-devel
mszyprow has joined #dri-devel
javierm has quit [Server closed connection]
javierm has joined #dri-devel
dj-death has quit [Server closed connection]
dj-death has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
Prf_Jakob has quit [Server closed connection]
mlankhorst has joined #dri-devel
Prf_Jakob has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pnowack has quit [Quit: pnowack]
unidan has quit [Server closed connection]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
sven has quit [Server closed connection]
sven has joined #dri-devel
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
alanc has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
itoral has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
mattrope has joined #dri-devel
alanc has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
ccr has quit [Server closed connection]
ccr has joined #dri-devel
itoral has quit [Remote host closed the connection]
Terman has quit [Server closed connection]
Terman has joined #dri-devel
itoral has joined #dri-devel
<karolherbst>
jekstrand: I think we can get rid of having to save the err code in the struct
<karolherbst>
but I can play around with that after you are done converting I think
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
<dj-death>
danvet: robclark: yeah, not sure we can do that
<dj-death>
first because of GuC
<dj-death>
second we don't seem to have a nice way to clear the counters
<dj-death>
and also, there is definitely an expectation that counters should survive a context switch
<karolherbst>
jekstrand: why not use decrement_strong_count in release?
<karolherbst>
it's equal to Arc::from_raw just without creating an Arc
<karolherbst>
and I midly prefer to use cl_* types when we deal with the CL API, so Result<..., cl_int> instead of i32
<karolherbst>
ohh wait.. you use that type_err field to check we have the correct object, yeah... guess we should keep it then
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<karolherbst>
jekstrand: ahhhhh.. I can't checkout your branch :D
<karolherbst>
moved mine to rusticl/main
thellstrom1 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lynxeye has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
shashanks has joined #dri-devel
MrCooper has joined #dri-devel
tursulin has joined #dri-devel
kj has joined #dri-devel
Major_Biscuit has joined #dri-devel
tonyk has quit [Server closed connection]
tonyk has joined #dri-devel
ahajda has joined #dri-devel
itoral has quit [Remote host closed the connection]
BobBeck has quit [Server closed connection]
itoral has joined #dri-devel
BobBeck has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
thellstrom1 has quit []
bnieuwenhuizen has quit [Server closed connection]
bnieuwenhuizen has joined #dri-devel
bnieuwenhuizen is now known as Guest1211
pcercuei has joined #dri-devel
whald has joined #dri-devel
itoral has quit [Remote host closed the connection]
italove31 has quit [Server closed connection]
itoral has joined #dri-devel
italove31 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
haagch has quit [Server closed connection]
haagch has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
rkanwal has joined #dri-devel
itoral has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kgz has quit [Server closed connection]
kgz has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Company has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Haaninjo has joined #dri-devel
jkrzyszt has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pendingchaos has joined #dri-devel
<dschuermann>
alyssa: jekstrand: can I get a rb for !13080?
Daanct12 has quit [Quit: Leaving]
unevenrhombus[m] has joined #dri-devel
Daanct12 has joined #dri-devel
<clever>
i was just thinking, VR displays have a special tag to make drm/xorg/window-managers exclude it from the normal desktop layout, and allow an application to gain exclusive control of it
<clever>
how is that managed, and could i extend an SBC video driver to treat 1 port as always being in that mode?
<clever>
i want to abuse that port for non-video tasks (which i can already do via the DRM api), but the single-master rules mean if Xorg is touching hdmi, i cant do anything
<pq>
clever, I think the kernel has a hardcoded list of HMDs.
<pq>
IIRC nowadays there is also a bit in EDID to indicate a HMD
<clever>
pq: i assume there is a bool on the port, and that hard-coded list is just used to set the bool? could i then modify the driver to just always set it?
tjaalton has quit [Server closed connection]
tjaalton has joined #dri-devel
<pq>
I have no idea.
<pq>
probably?
<clever>
got any keywords i can search for in the src? like what that hardcoded list might be stored in?
<pq>
HMD?
<clever>
drivers/gpu/drm/drm_edid.c:/* Non desktop display (i.e. HMD) */
<clever>
thats looks close
<pq>
I think it's a KMS property how that flag is exposed, so you could look up the property name, too
<clever>
#define EDID_QUIRK_NON_DESKTOP (1 << 12)
<clever>
that line immediately follows the previous
<clever>
does drm allow userland to mutate that flag? or must it be the driver? and i guess the drm master would have to co-operate, so still the same problem
nchery has quit [Remote host closed the connection]
<clever>
ah, yep, and here it is in the drm_display_info: info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
<pq>
I would expect not, but you'll have to check yourself.
<clever>
which comes from a drm_connector, struct drm_display_info *info = &connector->display_info
<pq>
"immutable" KMS properties are read-only to userspace
<pq>
maybe you can just override the EDID?
<clever>
the port also lacks edid entirely
<clever>
a fixed resolution is set in the device-tree
<pq>
there is e.g. a kernel commandline option to override EDID with a file IIRC
<pq>
maybe check if non_desktop might be set via DT? Maybe you get lucky.
<clever>
thats basically what i was going to add
<clever>
so the entire user base isnt forced to accept my choice
shoragan has quit [Server closed connection]
mairacanal[m] has quit []
Eighth_Doctor has quit []
DrNick has quit []
kallisti5[m] has quit []
<pq>
AFAIU DT is supposed to describe the hardware, and not be user settings, so I wonder if that is going to be accepted.
tomba has quit [Quit: Bridge terminating on SIGTERM]
HayashiEsme[m] has quit []
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
yshui` has quit []
x512[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
<clever>
how well do you know the kernel side of DRM? could drm_encoder_helper_funcs->enable mutate the drm_connector and that would work?
neobrain[m] has quit []
Mis012[m] has quit []
Vin[m] has quit []
exit70[m] has quit []
PiGLDN[m] has quit []
pmoreau has quit [Quit: Bridge terminating on SIGTERM]
cwfitzgerald[m] has quit []
reactormonk[m] has quit []
kalli0815[m] has quit []
sigmoidfunc[m] has quit []
robertmader[m] has quit []
gdevi has quit []
onox[m] has quit []
JosExpsito[m] has quit []
unrelentingtech has quit []
shadeslayer has quit [Quit: Bridge terminating on SIGTERM]
YaLTeR[m] has quit []
zamundaaa[m] has quit []
unevenrhombus[m] has quit []
RAOF has quit [Quit: Bridge terminating on SIGTERM]
danylo has quit [Quit: Bridge terminating on SIGTERM]
jasuarez has quit [Quit: Bridge terminating on SIGTERM]
jenatali has quit [Quit: Bridge terminating on SIGTERM]
heftig has quit [Quit: Bridge terminating on SIGTERM]
hasebastian[m] has quit []
Mershl[m] has quit []
kusma has quit [Quit: Bridge terminating on SIGTERM]
Sumera[m] has quit []
naheemsays[m] has quit []
_alice has quit [Quit: Bridge terminating on SIGTERM]
dafna2[m] has quit []
martijnbraam has quit [Quit: Bridge terminating on SIGTERM]
MrRoffline[m] has quit []
Tooniis[m] has quit []
xerpi[m] has quit []
JohnStultz[m] has quit []
tintou has quit []
bylaws has quit []
LaughingMan[m] has quit []
Wallbraker[m] has quit []
MatrixTravelerbot[m] has quit []
aura[m] has quit []
nielsdg has quit []
gagallo7[m] has quit []
Andy[m] has quit []
gnustomp[m] has quit []
doras[m] has quit []
zzoon[m] has quit [Quit: Bridge terminating on SIGTERM]
jekstrand[m] has quit []
moben[m] has quit []
Strit[m] has quit []
undvasistas[m] has quit []
egalli has quit []
Anson[m] has quit []
chivay has quit []
blue_penquin has quit []
halfline[m] has quit []
T_UNIX has quit []
ambasta[m] has quit []
pushqrdx[m] has quit []
apinheiro[m] has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
cleverca22[m] has quit []
ella-0[m] has quit []
ralf1307[theythem][m] has quit []
chema has quit []
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
shoragan has joined #dri-devel
<clever>
pq: the rpi platform uses dt for config a lot, because the hardware is very variable, and this would only work when the matching hardware has been attached to the DPI port
<pq>
are those upstream? ;-)
<clever>
upstream is against the idea of overlays, and isnt accepting any of them
<clever>
so upstream linux has a lot of trouble using the variable nature of the hw
<pq>
clever, I've almost never looked at the kernel side of DRM.
<pq>
so I dunno
<clever>
ive barely looked at the userland half, lol
<javierm>
clever: as pq said, unless the resolution is fixed for the hardware, that really shouldn't be in the DT
<clever>
for the DPI port on the rpi, its just a raw digital parallel interface, hsync, vsync, 24bits of color
<clever>
what is valid, depends on what the user plugs in
<javierm>
clever: what you could do though is to have a of_device_id table in the driver and fill the .data field with that info
<pq>
that's how all monitors work :-D
<clever>
pq: but hdmi is 3 differential lanes, sending the 8bit color in serial form as 10 symbols, rather then parallel
<clever>
and hdmi has a proper edid spec to detect the supported options
<clever>
dpi is just raw parallel, and no edid
<pq>
clever, VGA before DDC was a thing...
<clever>
yep
<clever>
and you can convert dpi to vga with a dumb 3 channel DAC
<clever>
but my goal is non-video abuse, driving stepper motors
<clever>
the hardware can already do it, when i'm the drm master
<clever>
but then you cant use hdmi under xorg
<javierm>
clever: how interesting
<javierm>
clever: so you are plugging a step motor in the other side instead of a panel?
<clever>
javierm: basically, all the hardware is doing is taking an array of 24bit samples (typically called a framebuffer) and playing them on 24 pins at a defined rate (typically called the pixel clock)
<clever>
who says those 24bit values must represent a color?
<clever>
what if that was 12 step pulses, and 12 direction signals, to drive 12 stepper motors at once?
<javierm>
clever: can't decide if that's brilliant or crazy :)
<clever>
this chunk of sample code, will just send the same uart data on 8 pins at once, but could be extended to send 24 unique serial streams at once
<javierm>
clever: thanks for sharing. It definitely is food for thought
<javierm>
it would had never occur to me
<clever>
the root problem, is that all 3 video outputs on the rpi, are locked to a single drm master
<clever>
line 137-149, is using drm_for_each_connector_iter to search for the DPI drm_connector, where the encoder is the dpi encoder
<clever>
so, something else must have made that connector?
<clever>
probably the crtc file
<clever>
*digs more*
<clever>
hmmm, having trouble finding where the drm_connector actually gets created
q66 has quit [Quit: q66]
q66 has joined #dri-devel
Wallbraker[m] has joined #dri-devel
<clever>
javierm: any idea where thats hiding?
flacks has quit [Quit: Quitter]
<javierm>
clever: search for drm_connector_helper_add()
Daanct12 has quit [Quit: Leaving]
<clever>
i see that in the fkms(legacy), hdmi, txp, and vec modules
<clever>
but its missing from dpi
<clever>
but it does accept a drm_connector_helper_funcs, which is also missing from dpi!
oneforall2 has quit [Remote host closed the connection]
flacks has joined #dri-devel
<clever>
ah, i think its often abusing compatible = "dumb-vga-dac", from drivers/gpu/drm/bridge/simple-bridge.c
<clever>
thats why i cant find it anywhere
<clever>
ah, i think i see how it works, the DPI doesnt have a drm_connector, its just a dumb drm-less? port, device-tree then binds that to a bridge(which does have a drm_connector), and that bridge is the user-facing part
<MrCooper>
clever: since you seem to be using Xorg, have you tried changing the property with xrandr?
oneforall2 has joined #dri-devel
Daanct12 has joined #dri-devel
<clever>
and that then allows other bridges like say dpi->hdmi to be wired in, and create a differently behaving drm_connector
<clever>
MrCooper: not yet, i wanted it to be set before Xorg starts, so you dont get any stray graphics leaking out
<javierm>
clever: so I think you either need your own "bridge" or "panel" driver
<javierm>
I'm quoting because is really a set of step motors :)
<clever>
yeah
<clever>
the only other problem that remains then, is that i dont want a frame to ever display twice
<javierm>
and then an overlay that will set the "resolution" of your "display"
<clever>
but i assume i can use the drm api to queue up one or 2 pageflips into the future?
<javierm>
clever: maybe you could use a shadow buffer for that ?
<javierm>
and only push an update if something changed
<clever>
my general idea was to register multiple framebuffers, and use atomics to display each for 1 frame
<clever>
but i dont want unexpected latency spikes to delay a pageflip, and render an image twice
<clever>
each frame should only ever be displayed once, and rendering black is better then repeating a frame
<clever>
which is a bit backwards from what drm normally should do
<javierm>
clever: please share the end result. It will be a very interesting reading for sure
<clever>
there is also 1 minor issue for certain protocols, like uart
<clever>
during hsync and vsync, all 24 color bits go to 0
<clever>
and the hw wont let hsync/vsync go below 1
<clever>
so there is a 1 "pixel" blip of 0 per scanline, and a 1 "scanline" blip of low per frame
<clever>
but other then that, all other timing parameters are free game
<clever>
once during investigations, i accidentally enabled interlacing, but the odd field timings where undefined
<clever>
that resulted in an even field that was 1/60th of a second long, and an odd field that was 2 seconds long!
<clever>
my crt then just kept turning on&off, because it saw 2 vsync's at the right distance, turned on, then nothing, turned off! lol
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
HdkR has quit [Server closed connection]
HdkR has joined #dri-devel
devilhorns has joined #dri-devel
Plagman has quit [Server closed connection]
Plagman has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
agx_ has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
Lynne has quit [Server closed connection]
Lynne has joined #dri-devel
Daanct12 has quit [Quit: Quit]
Daanct12 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
<alyssa>
dschuermann: IIRC I looked at that recently, did something change?
<dschuermann>
not, but I'd like to land it
camus1 has joined #dri-devel
<alyssa>
OK
Haaninjo has quit [Quit: Ex-Chat]
camus has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Daanct12 has quit [Quit: Quit]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<alyssa>
dschuermann: is it, like, ready to land?
padovan has quit [Server closed connection]
itoral has quit [Remote host closed the connection]
padovan has joined #dri-devel
<dschuermann>
I hope so :)
itoral has joined #dri-devel
<dschuermann>
it shouldn't create any stats diff anywhere
<bbrezillon>
jekstrand: do you want me to push one branch per vk-sec-cmdbuf version so you can have a glance and play with the one you were looking for?
<bbrezillon>
I'd really like to get that sorted out so we can move on and merge the dozen MR
<alyssa>
dschuermann: ?
nashpa has quit []
itoral has quit [Remote host closed the connection]
dliviu has joined #dri-devel
<dschuermann>
alyssa: what's the question?
pcercuei has quit [Ping timeout: 480 seconds]
<alyssa>
dschuermann: what do you mean by stats diff
<dschuermann>
the MR shouldn't create any difference for any shader
<dschuermann>
(by itself)
<alyssa>
...No?
<alyssa>
why not?
<dschuermann>
unless you change the callback functions, it is semantically equal to what we have upstream
<dschuermann>
unless I made a mistake when translating the callbacks
<alyssa>
ohhm.
<alyssa>
dschuermann: I thought it should improve shaders like the aggressive vectorization patches did?
<alyssa>
am I misunderstanding the purpose?
<dschuermann>
it gives the option to do so by passing a suitable callback
<alyssa>
what about not breaking vectorized chains?
<alyssa>
and cases where scalarizing then revectorizing doesn't work without aggressive vectorization, doesn't the new lower_to_scalar fix that?
jewins has joined #dri-devel
<pq>
shashanks, thank you! I'll have a look next week.
<shashanks>
pq: sure, np :)
<dschuermann>
alyssa: not unless you specify the required vector width in the callback. I only mechanically translated what was there
<dschuermann>
alyssa: as the previous filter was only true/false, I translated it to width=1/0 (0 == don't touch)
pcercuei has joined #dri-devel
_alice has joined #dri-devel
ambasta[m] has joined #dri-devel
Andy[m] has joined #dri-devel
apinheiro[m] has joined #dri-devel
aura[m] has joined #dri-devel
blue_penquin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
chivay has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna2[m] has joined #dri-devel
dcbaker has joined #dri-devel
Anson[m] has joined #dri-devel
Guest1230 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
exit70[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
go4godvin has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
HayashiEsme[m] has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JohnStultz[m] has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kalli0815[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
Mershl[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
Vin[m] has joined #dri-devel
<alyssa>
ah ha, got it
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nielsdg has joined #dri-devel
onox[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
MrR[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
shadeslayer[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
unevenrhombus[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
<alyssa>
so i'll need to write a trivial patch to the bifrost backend to drop the special scalarizing callback in favour of a vectorizing one, sure makes sense thank you i missed that part
pmoreau is now known as Guest1254
thellstrom has joined #dri-devel
<dschuermann>
exactly :)
<alyssa>
got it
pzanoni has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
urja has quit [Server closed connection]
urja has joined #dri-devel
Hi-Angel has joined #dri-devel
nchery has joined #dri-devel
tzimmermann has joined #dri-devel
CME has quit [Server closed connection]
CME has joined #dri-devel
shadeslayer[m] is now known as shadeslayer
fxkamd has joined #dri-devel
kts has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has left #dri-devel [Leaving]
Ristovski has quit [Server closed connection]
Ristovski has joined #dri-devel
frankbinns has joined #dri-devel
sdutt has joined #dri-devel
mattrope has joined #dri-devel
shankaru has quit [Quit: Leaving.]
rkanwal has joined #dri-devel
<kusma>
The pvr MR is in, congrats to everyone involved (I assume some of you are here) :)
<alyssa>
wha?
<kusma>
In as in submitted, not landed of course.
<alyssa>
holy crap I never thought I'd see the day
<kusma>
Yeah, I tend to use three-space like core mesa for my stuff just to be "less strange", but there's enough variants that "normal" isn't really a thing :P
<alyssa>
I, er, seem to have twice as many followers as IMG itself...
mszyprow has quit [Ping timeout: 480 seconds]
<alyssa>
frankbinns: So now we get to find out how much Apple "borrowed" for AGX :-p
<jekstrand>
frankbinns: Welcome!
<alyssa>
frankbinns: `rogue_nir_pfo` -- AGX needs the same logic, it looks like
<alyssa>
we wrote nir_lower_blend for that
<alyssa>
the packing itself I'm doing in the AGX compiler when translating NIR->IR, not sure what the right approach is though
<frankbinns>
@alyssa no comment :P
<frankbinns>
jekstrand: hey :)
<jekstrand>
frankbinns: You missed the perfect opportunity to call your Vulkan driver PowerVK and make it sounds like a SNES accessory from the 90s. :P
<jekstrand>
bbrezillon: I meant just push a branch somewhere with the first version (the one with `if (level == secondary) record_command()`) so I can pull it and play around.
<jekstrand>
bbrezillon: And tell me where said branch is. :D
<bbrezillon>
retrospectively, I don't like this approach much, since it forces us to extend the scripts to take a list of entrypoints to generate wrappers for
<bbrezillon>
the nice thing about the cmd_dispatch indirection is that we can leave functions unimplemented and that doesn't trigger linking/compilation errors
<jekstrand>
Yeah, I'll try to play around with it on Monday or Tuesday and see if I can make the generation better there.
<jekstrand>
Today, I apparently have a PowerVR driver to review. :D
<frankbinns>
jekstrand: please be gentle :P
<bbrezillon>
jekstrand: also had a version with the cmd_dispatch tables added to vk_device and with dispatcher functions doing 'if (level == secondary) dev->sec_cmd_dispatch.CmdXx() else dev->prim_cmd_dispatch.CmdXxx()', but we're basically just saving one pointer location per cmd_buffer, so I'm not sure it's any better than putting the dispatch_table directly in the vk_command_buffer object
<daniels>
frankbinns: \o/ !
<jekstrand>
frankbinns: Oh, you have nothing to fear. I'm not going to look closely enough at the details today to be harsh. Aparently, that's alyssa's job. :P
* jekstrand
checks phoronix. Nothing yet.
<daniels>
now all we're missing is ajax to come good with his semi-regular threats of i128/verite, and uhhh ... I guess Parhelia?
off^ has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
fxkamd has quit []
Akari has joined #dri-devel
<jekstrand>
frankbinns: Has the rest of your team figured out IRC yet?
<MTCoster>
I'm not sure "figured out" describes it, but I'm here
<kj>
CreativeCylon here
<rkanwal>
Hiya, Rajnesh here.
<jekstrand>
Hehe. :)
<daniels>
hi all! :)
<jekstrand>
Welcom!
<jekstrand>
*Welcome, even
Duke`` has joined #dri-devel
<daniels>
frankbinns: funnily enough I was actually going through the uAPI before lunch
<pcercuei>
So the kernel is C11 now... Does that mean we can use "auto" types?
<jekstrand>
Ooh... Can we use auto types in Mesa?
<jekstrand>
If we do, NIR builder code is going to start being a lot fewer characters...
<sarahwalker>
belated hello, I am also on the img team
pH5 has quit [Server closed connection]
pH5 has joined #dri-devel
simon-perretta-img has joined #dri-devel
<jekstrand>
Hi sarahwalker. Welcome to DRM/Mesa!
<alyssa>
sarahwalker: Welcom!
<alyssa>
frankbinns: i apologize if this is terribly inappropriate but
<alyssa>
your last name is perfect for writing a driver for a tiler gpu :-p
mbrost has joined #dri-devel
<alyssa>
jekstrand: I thought auto types are C++ only?
<alyssa>
all the chromebooks shall be free mwahaha
<pcercuei>
Hmm, looks like "auto" in C doesn't do what I thought it did...
<pcercuei>
It's not like the C++ auto
<simon-perretta-img>
(Very!) belated hello, I believe I'm the last to hop on from the IMG team :)
sarahwalker has quit [Remote host closed the connection]
<jekstrand>
Hi simon-perretta-img!
<anholt>
welcome, img folks!
<MTCoster>
anholt: thanks :)
<alyssa>
simon-perretta-img: Hi!
<alyssa>
wonder if we need a dedicated channel for IMG driver discussion
<alyssa>
I assume you've all been talking on Slack or whatever, would be nice to be in the open and not take over #dri-devel
<MTCoster>
alyssa: that would be nice - we've had teams shoved down our throats over here
<alyssa>
Oof
<alyssa>
Teams is. not my favourite.
<zmike>
this is the day I have feared for time interminable
* zmike
flees
<alyssa>
zmike: Another driver you have to make Zink work on! :-D
<daniels>
well, if #powervr isn't too impolitic then we could take that, else maybe #img-gpu or something
<zmike>
I foresee an upcoming blog post in which zink becomes lavapipe-only
<daniels>
(#imagination is bound to have people wonder in and talk about neuroscience)
<alyssa>
i have claimed all of them mwahaha
<jekstrand>
Of all the implementations of corporate chat I've experienced, Teams is the worst.
<alyssa>
agreed
<MTCoster>
jekstrand: no no, i was subjected to google chat in its earliest days. THAT was the worst
<daniels>
jekstrand: oh sweet summer child
<alyssa>
MTCoster: who can I shoot IMG hardware questions at?
<alyssa>
you? great
<jekstrand>
MTCoster: I've never used google chat for group chats for work stuff.
<alyssa>
what's the idea behind the scissor array? (and apparently depth/bias array too?)
<daniels>
thankfully Nokia scrapped Lotus Notes about 3-4 months after I started working there
<jekstrand>
I've heard a rumor that for a while (and maybe still), Facebook (*caugh* Meta) made their employees do everything on, well, you know, facebook. That sounds pretty horrible.
<jekstrand>
daniels: Lotus Notes! I remember that. Never used it for a work setting, though.
<MTCoster>
alyssa: #powervr sounds good
<daniels>
(but not after someone in my team realised that he could look absolutely awesome on velocity metrics by moving every bug assigned to him to the next status down in the list every day - buys you a lot of time when you have 200 statuses)
<daniels>
jekstrand: Facebook Workplace is a thing, yeah. also Phabricator came out from there
<zmike>
I see nobody here has ever used s-messenger
<pcercuei>
IMG == Imagination Tech?
<MTCoster>
pcercuei: yup, that's us
<pcercuei>
I used to work a lot with Paul Burton, don't know if that rings a bell
shashanks has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
join_subline has quit []
<jekstrand>
Ok, I think that's enough MR comments for now. I'll maybe look at the compiler later.
ybogdano has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
<cwabbott>
wow, gitlab/firefox is really struggling with the pvr MR
rkanwal has quit [Ping timeout: 480 seconds]
<alyssa>
cwabbott: and people wonder why I use vim for my reviews...
<jekstrand>
alyssa: Your vim reviews bother me
anarsoul|2 has quit []
anarsoul has joined #dri-devel
Major_Biscuit has quit []
<alyssa>
jekstrand: GitLab bothers my Firefox
<anarsoul>
cwabbott: you just need a new laptop :)
<alyssa>
anarsoul: it bothers my m1
<cwabbott>
this is a pretty new xps 13 with 32gb of ram, it's not exactly low-end
frankbinns has quit [Remote host closed the connection]
<daniels>
alyssa: not sure if it's just Firefox itself or some extensions, but zmike was saying some pages take multiple minutes to load for him in Firefox. in Chrome, seconds ...
<jekstrand>
Most of my comments were "if you do this, you can delete some code". Maybe that'll help with MR load times. :P
<alyssa>
jekstrand: Hey mine too :d
<jekstrand>
See! We're helping!
<alyssa>
:-D
<jekstrand>
cwabbott: "embrace the laziness" :D
<cwabbott>
;)
<alyssa>
jekstrand: "achieve the laziness"
<jekstrand>
alyssa: I am the laziness!
<jekstrand>
Lunch and then back to Rust OpenCL... Hopefully I'll have a nice set of patches for karolherbst by EOD.
<alyssa>
jekstrand: There we are
<daniels>
jekstrand: OpenCL on PVR? wow, that was quick
mwalle has quit [Server closed connection]
mwalle has joined #dri-devel
pzanoni has joined #dri-devel
<jekstrand>
daniels: :P
<jekstrand>
daniels: You know me. Always ahead of the curve. :D
<robclark>
jekstrand: pls no auto types
<jekstrand>
robclark: Generally, I'm not a fan of auto. But I could see `auto sum = nir_iadd(b, x, y);`
<robclark>
I suppose in limited cases where the type is obvious it can be ok.. but auto can easily make code very hard to understand
<anholt>
auto types are lovely when your language has a nice language server that can annotate what they work out to be. Without that, not a fan.
<pcercuei>
pinchartl: Or I can merge it if you want. We need this patch for a separate bridge driver
<gawin>
auto is nice when you can guess type from the same line
whald has quit [Quit: Leaving]
dottedmag has quit [Server closed connection]
<jekstrand>
Yeah, that's why I'd be fine with it for nir_builder code. EVERYTHING returns a nir_ssa_def *
dottedmag has joined #dri-devel
<jekstrand>
So it lets you avoid a bit of typing without much loss of information.
<jekstrand>
However, if people took that as license to start using auto all over the place... kill it with fire.
<anholt>
typedef nir_ssa_def def in nir_builder.h? ;)
<jekstrand>
anholt: I've thought about it
<jekstrand>
Specifically, having a #define you can throw at the top of a file before pulling in NIR headers that adds `typedef ssa nir_ssa_def *` and strips all the `nir_` prefixes from the builder functions.
<jekstrand>
karolherbst: RE cl_int. I hate API-specific typedefs like that with a passion. It's fine for something like GetInfo where you want to be able to easily match the listed type to the spec. However, I'd really like to get away from them in the internals. IMO, the only reason why APIs like OpenCL and OpenGL do that is because they didn't want to depend on stdint.h.
<jekstrand>
karolherbst: For error codes in particular, I'm thinking of making two new typedefs: `type CLError = cl_int` and `type CLResult<T> = Result<T, CLError>` and using those everywhere. I think that's a nice compromise. I'll do that as a follow-on patch to my current work.
<jekstrand>
By contrast, Vulkan uses uint32_t etc. everywhere.
haasn has quit [Server closed connection]
haasn has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
ybogdano has joined #dri-devel
pzanoni` has joined #dri-devel
Guest1254 is now known as pmoreau
glennk has quit [Server closed connection]
glennk has joined #dri-devel
RSpliet has joined #dri-devel
mjn has joined #dri-devel
mjn has quit []
shashanks has joined #dri-devel
kj has quit []
ybogdano has quit [Read error: Connection reset by peer]
<HdkR>
I'm pleasantly surprised that the pvr_drm implementation didn't heck up their struct member paddings.
<daniels>
HdkR: you can thank danvet for that :)
<HdkR>
Nice
<daniels>
'have you read Botching Up ioctls, and have you read it twice?' should be a mandatory question for all new uAPI submissions
<airlied>
we should just add, have you ask HdkR
<HdkR>
Would be nice. I run every drm ioctl change through my cross-arch struct verifier
<daniels>
airlied: :D
<vsyrjala>
HdkR: is that verifier made of meat, or is it something that could be part of ci?
rkanwal has joined #dri-devel
mhenning has joined #dri-devel
<HdkR>
vsyrjala: Partial meat atm. Any new struct definition I need to currently go through and annotate it
<HdkR>
I could probably fuzzy match which structs to care about to make it more automated though
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
angerctl has quit [Server closed connection]
angerctl has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
tzimmermann has quit [Quit: Leaving]
mbrost has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
samuelig has quit [Server closed connection]
samuelig has joined #dri-devel
<jekstrand>
karolherbst: Just pushed my rusticl/object-wrappers branch again. It's ready to go now. Everything is natively using Arc and, while there is definitely cleanup work to do, I think it's in reasonably good shape.
<jekstrand>
What cleanup work, you ask? Well, I think we should be passing refs to objects around a lot more than Arcs if we can.
<jekstrand>
Right now, nearly everything takes an Arc and that means we almost always have to increment the reference count on everything at the start of each call and decrement afterwards.
<jekstrand>
With the old system, we could pass a reference to the Arc storred in the wrapper object everywhere.
<jekstrand>
Now, we have to be more careful
<jekstrand>
Rather, we don't have a wrapper object
<jekstrand>
We either have a bare pointer or we make an Arc ourselves.
<jekstrand>
The problem if we start passing raw refs around is that, if you want to stash something, you need to create an Arc from that ref. For that, I'm thinking of having a GetArc trait which provides a Foo::get_arc(&self) -> Arc<Foo>
<jekstrand>
Of course, that only works if Foo::new() returns an Arc but pretty much everything does.
<jekstrand>
The other option is we could just trim down our usage of Arc<Foo> and keep it to just constructors which want to stash a Foo
<jekstrand>
That's maybe the best thing to do short-term
<jekstrand>
But I'll leave that until next week after you've had a chance to look at my branch
FLHerne has quit [Server closed connection]
FLHerne has joined #dri-devel
<krh>
wow, good news, welcome img folks!
<anholt>
jekstrand: would arc.downgrade() weak refs be good enough for your getarc needs?
<jekstrand>
anholt: No. The problem is if we just pass around references, you need to be able to turn an Arc into a reference.
<jekstrand>
rather, you need to be able to turn a reference in to an Arc
<jekstrand>
If Arc were invasive (how you'd normally do it in C++ or C), you'd just say "Hey, this is a reference counted thing and I have a valid pointer to it. Let me create another reference"
<jekstrand>
But because Arc is external, it requires a bit of unsafe code which will blow up the moment you have a Foo on the stack somewhere.
mlankhorst has quit []
<jekstrand>
But, again, I think the #1 problem here is actually just that we're using Arc too many places. If something's not going to stash it off, it should take a &Foo rather than a &Arc<Foo>.
<anholt>
yeah, the weak thought I was having didn't work
<anholt>
jekstrand: actually, can you link code where you think you have extra refcounts happening?
<jekstrand>
anholt: get_arc() creates an Arc<T> and requires incrementing the reference count to do so. If it's only ever inspected, we could be using get_ref() instead which returns a reference, trusting the client to not clReleaseFoo it away mid-call.
Duke`` has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mvlad has quit [Remote host closed the connection]
ds` has quit [Server closed connection]
ds` has joined #dri-devel
neonking has quit [Remote host closed the connection]
<marex>
my jaw drops ... pvr ...
<anholt>
jekstrand: instead of from_raw, I think I would return the transmute of the &Arc<T> from your creation functions after forget()ing it, and then you could transmute that pointer into &Arc<T> again for get_arc() without doing refcounts, and destroy would decrement_strong_count().
<anholt>
wait, no. &arc is on the stack, we don't have a box.
<jekstrand>
yup
<jekstrand>
There's an implicit Arc container kicking around somewhere that the client has references to.
<jekstrand>
And we can get at it by checking very carefully if a pointer is good
* jekstrand
should implement Drop for CLObjectBase to smash the dispatch table to NULL or something to catch use-after-free.
<anholt>
and you really don't want to just have an extra box at the c layer?
<jekstrand>
anholt: That's what I just got done deleting. (-:
<jekstrand>
Well, not really a Box more of a hand-rolled Arc of an actual Arc
sigmaris has quit [Server closed connection]
sigmaris has joined #dri-devel
<anholt>
so, my thought if you're fine with "the C caller must guarantee that the lifetime of the object persists across these calls" would be something like get_arc() -> CLResult<&Arc<T>> { unsafe { let a = Arc::from_raw(self.get_ptr()?); let ref = &a; std::mem::forget(a); Ok(ref) } }
Haaninjo has quit [Quit: Ex-Chat]
famfo has quit [Server closed connection]
famfo has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jekstrand>
anholt: Oof, that's some magic
<anholt>
I mean, so is calling from_raw() multiple times and incrementing the strong refcount to work around that :)
<Lyude>
is apitrace the hip and cool tool for recording OpenGL traces these days? or have we moved to something else
<jekstrand>
anholt: Yeah, but std::mem::forget()?
<anholt>
Lyude: it's the best we have, as long as you're not on android
* jekstrand
doesn't even know what that does.
mbrost has quit [Ping timeout: 480 seconds]
<Lyude>
I think it just makes it so that rust considers the variable gone without calling it's destructor
Wally has joined #dri-devel
<jekstrand>
anholt: Another thought that came to mind if we really care and it becomes a real problem is to have a little struct that holds an Arc which it imports from the client with from_raw() and then in the drop, "hands it back" to the client instead of decrementing the reference count. It would also implement Deref<Arc<T>> so it looks pretty much like an Arc but it wouldn't actually be one and you
<jekstrand>
couldn't steal it.
<zf>
is there any way to create an snorm texture buffer object?
<jekstrand>
But I think what I have now is fine.
cheako has quit [Quit: Connection closed for inactivity]
<jekstrand>
zf: Not in GL
<anholt>
jekstrand: my thing doesn't work, because again a is an Arc on the stack, while I was thinking about the ArcInner.
* anholt
is not practiced at this
<zf>
well, that's annoying
<Lyude>
also, you might be able to use std::mem::take() instead
<jekstrand>
zf: Well, not without an extension on top of ARB_texture_buffer_object
<zf>
would mesa be interested in such an extension? :D
<anholt>
(I've mostly only read c ffi stuff that was boxes, not arcs)
<jekstrand>
zf: idk. Depends on what you plan to do with it.
<zf>
we need it in Wine to implement Direct3D 10+ SNORM buffer views
rkanwal has quit [Ping timeout: 480 seconds]
Hi-Angel has quit [Ping timeout: 480 seconds]
<RSpliet>
Lyude: to stay in the theme of the day: there's also this, I think, closed source free-to-use thing:https://developer.imaginationtech.com/pvrcarbon/
<Lyude>
eh, closed source just sounds like too much trouble if I have to fix something :P
<jekstrand>
zf: Hrm... If D3D10 has it, there's probably a GL extension. Let me look a bit more.
rkanwal has joined #dri-devel
<RSpliet>
Lyude: probably :-P Depends on what you want to do with it. It's got a functional GUI, it can export renderdoc, and it can export a recording to C++ + CMake for replay
<jekstrand>
zf: Yeah, looks like GL doesn't have it. At least, I'm not finding it quickly. Shouldn't be that hard to write the extension text and implement it if someone had a mind to.
<zf>
cool, I've not written an extension before, but I'd be glad to try