ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tjaalton_ has quit [Remote host closed the connection]
tpalli has joined #dri-devel
tjaalton has joined #dri-devel
ngcortes has joined #dri-devel
pnowack has quit [Quit: pnowack]
ngcortes has quit [Remote host closed the connection]
iive has quit []
ybogdano has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
<anholt>
airlied: thanks. just realized I don't have an ack for the uprev commit, either :/
<airlied>
anholt: ab for that
<jenatali>
Looks like I have to completely rewrite how we produce DXIL signatures, that'll be fun
cphealy has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
<kisak>
must be time to switch over to cursive
<HdkR>
Cursive is great for only signatures. I can just scribble on something and no one can duplicate it, not even myself.
rasterman has quit [Quit: Gettin' stinky!]
Lucretia-backup has quit []
Lucretia has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
nchery has joined #dri-devel
oneforall2 has joined #dri-devel
shsharma has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
shsharma has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
dv_ has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
nsneck_ has joined #dri-devel
nsneck has quit [Ping timeout: 480 seconds]
fxkamd has quit []
nchery has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
bnieuwenhuizen_ has quit []
bnieuwenhuizen has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
<graphitemaster>
I assume when NV lists "Maximum number of 32-bit registers per SM" and then lists something like 64 K here, they do not mean 64,000 32-bit registers, but 64 KiB worth 32-bit registers
<graphitemaster>
The other fields use KB so maybe they do mean thousands (K)
<graphitemaster>
But they're power of two's so I'd assume they mean K as in 1024
<graphitemaster>
What a shitty table
<imirkin>
graphitemaster: yes. "shared" memory in GL compute parlance is split between registers used for shaders and for the super-shared "registers" across the SM
<graphitemaster>
Yeah I know that
<graphitemaster>
I just want to know if 64K 32-bit registers means 64 * 1024 * 4 bytes or 64 * 1024 bytes or 64 * 1000 * 4 bytes or 64 * 1000 bytes XD
nchery has joined #dri-devel
<imirkin>
afaik 64kb worth of registers. i.e. 65536 / 4 32-bit registers.
<imirkin>
although turing+ introduces "uniform" registers, not sure how those are accounted for exactly
cworth has joined #dri-devel
sdutt has joined #dri-devel
cworth has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<mareko>
airlied: I didn't actually finish FP16/mediump support - tess and GS varyings and transform feedback were the main missing items, and then some failing tests I think
<mareko>
the reason I stopped is that I didn't see any perf improvement in a GLES benchmark we cared about
kts has quit [Ping timeout: 480 seconds]
<HdkR>
rc1 tomorrow right?
cphealy has joined #dri-devel
benettig has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<cheako>
I've uploaded my API dump, the most interesting frame is 4113
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
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mvlad has joined #dri-devel
<pq>
javierm, awesome doom! What the window system stack like in that picture? fbdev or KMS? Xorg or something else?
nchery is now known as Guest1496
nchery has joined #dri-devel
itoral has quit [Remote host closed the connection]
nchery is now known as Guest1497
nchery has joined #dri-devel
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
tursulin has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<javierm>
pq: it's just fbdev. I also cheated because Doom complains that can't run there due the minimum resolution being 320x200 and the panel only having 128x64
Guest1496 has quit [Ping timeout: 480 seconds]
<javierm>
pq: so what I did is to run on fb0 and then grab each frame, transform and write into fb1
<pq>
ahaha, but hmm...
Guest1497 has quit [Ping timeout: 480 seconds]
<pq>
I wonder if there is some way to trick weston/drm - Xwayland - doom/x11 to let doom run in 320x200 and then Weston scales it down to "fullscreen"
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<pq>
Xwayland would have to advertise 320x200 video mode as a possibility to Doom, then Doom does a modeset with RandR, and Xwayland emulates that with wp_viewport without actually changing the mode.
<pq>
But I suspect Xwayland might refuse to advertise modes larger than what the Wayland compositor has.
mszyprow_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
<javierm>
pq: doom is able to upscale, the problem is with down scaling below 320x200
itoral has joined #dri-devel
<javierm>
with bigger resolution it scales and you just get blurry images
<emersion>
gamescope could be used to fake a large screen but… o_O
<javierm>
pq: I tried to hack the original doom source to remove that constraint, but there seemeded to be too many assumptions about 320x200
<pq>
javierm, yes, exactly; Xwayland would fake 320x200 mode to Doom while actually running in 128x64 Wayland desktop.
<pq>
emersion, oh, that sounds better
<javierm>
pq: ah, got it now. haha, that would be interesting to explore
<pq>
javierm, the more standard and unptached components used, the more impressive it is :-D
<javierm>
pq: 100%
itoral has quit [Remote host closed the connection]
<javierm>
pq: so then I just gave up and did the hack I mentioned
itoral has joined #dri-devel
<javierm>
but didn't considered that xwayland lying and advertising a 320x200 resolution
<pq>
Xwayland is good at lying about video modes I think, but it might refuse to do it with modes larger than actual, I'm not sure.
<pq>
the usual use case is upscaling and not downscaling, indeed
<pq>
although... hmm.
<javierm>
yeah. I never had this much fun working on a driver :)
Ziemas has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
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
<linkmauve>
Weston itself can already fake a different mode, if the hardware supports plane scaling (i915 does), in an [output] section set mode=320x200 and the primary plane for this output will be 320×200, and then scaled to the actual monitor’s size.
<linkmauve>
This is what I use to test hidpi for instance.
<pq>
linkmauve, uhh... how does that work? 'mode' is supposed to change the video mode, not only the FB size.
<linkmauve>
It is a video mode change, to userland it looks like the screen grew more pixels than it actually has.
<pq>
I would be surprised if ssd1307 driver supported any other video modes than the native one, let alone mode bigger than the native one.
<pq>
linkmauve, so you get the big video mode on HDMI or whatever, but then the monitor scales it down?
<pq>
but then plane scaling is not at play there
<pq>
not that ssd1307 supported plane scaling to begin with, I believe
itoral has quit [Remote host closed the connection]
<linkmauve>
Just tested with my 1366×768 LVDS, the connector stays in 1366×768, but its crtc says Mode: 1920x1080@59.96 userdef nhsync pvsync
<linkmauve>
I’m pretty sure LVDS doesn’t support scaling at all, so it’d be in the encoder maybe?
<javierm>
pq: correct, the driver only supports its only native mode. Which in fact is hardcoded in the Device Tree
<pq>
hmm, so you are using a custom modeline, and then the *kernel driver* decides to fake it, because it know the panel can only run at a single specific mode.
<pq>
linkmauve, Modes on what object?
<linkmauve>
On the CRTC.
<pq>
then you are *
<linkmauve>
And correct about the custom modeline.
<javierm>
pq: I guess that could expose a 320x200 mode to user-space and then scale down in the driver. Just like we do with the pixel format :P
<linkmauve>
javierm, I believe that’s what i915 does here, but at scanout instead of in software.
<pq>
linkmauve, ah, connector does list modes by EDID, but it won't show what's happening on the cable.
<javierm>
linkmauve: I see. Interesting
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<pq>
linkmauve, ok. What you see is not Weston at all. It is the kernel driver allowing an unlisted mode and magically deciding to scale it instead of actually using it.
<pq>
or maybe the panel has a scaler
<linkmauve>
That’s what I thought as well.
<vsyrjala>
it's in the pipe (~=crtc)
<vsyrjala>
with intel hw that is
<pq>
This won't work on a panel that does not have a scaler and a driver that does not scale.
<pq>
IOW, Weston is not faking. The driver is.
<linkmauve>
Right.
<pq>
Weston *could* fake modes with a primary plane that supports scaling, but that's not implemented.
<pq>
Weston could also fake with renderer scaling, but that's not implemented either, though daniels has a MR for something like that.
<pq>
but it's only for upscaling I think
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
heat has joined #dri-devel
<linkmauve>
Oh, that’d be interesting. ^^
<javierm>
pq, linkmauve: I never thought that sharing a picture of doom would spark a conversations like this
<javierm>
it seems gfx land is full or rabbit holes
<javierm>
*of
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<danvet>
tomba, pinchartl since I think you're the last two who actively cared about fbdev, feel like taking a look at "[PATCH 01/21] MAINTAINERS: Add entry for fbdev core" ?
<daniels>
pq: yeah, renderer-follows-scale only does upscale (i.e. renderer buffer is an integer multiple smaller than the display mode), but it could reasonably easily be adapted
<daniels>
I've been waiting for some of Derek's region work to coalesce before I do tho, because that will make things far less error-prone ...
rasterman has joined #dri-devel
flacks has quit [Quit: Quitter]
<pq>
javierm, haha, well, isn't userspace almost always the biggest hurdle in KMS development? :-)
flacks has joined #dri-devel
<javierm>
pq :) I'm just joking. Learning a lot from these discussions since I'm a newbie in gfx
tobiasjakobi has joined #dri-devel
thellstrom has joined #dri-devel
<danvet>
demarchi, btw want drm-misc commit rights so it's simpler to push the all over refactorings you're doing?
frieder_ has joined #dri-devel
frieder has quit [Read error: Connection reset by peer]
devilhorns has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
gawin has joined #dri-devel
heat has joined #dri-devel
itoral has quit [Remote host closed the connection]
<graphitemaster>
Conceptually is there really anything different about SSBOs and UBOs when it comes to the driver?
<graphitemaster>
I would assume drivers still attempt to marshal small SSBOs as uniforms
<cheako>
I've uploaded my API dump, the most interesting frame is 4113 https://drive.google.com/drive/folders/1u5dTh1esfT-22M3q9-hL5glf_xf1eUac?usp=sharing I think there are a growing number of allocatememory calls when compared to freememory. It also seems like the engine is overzealous when re-creating the swapchain, I don't think it's beneficial to free all those images after reciving a VK_SUBOPTIMAL_KHR. I assume something like the
<cheako>
awk https://pastebin.com/65fhiHGR would show an even number of allocs-free, but instead this value increases. Validation layers doesn't show it.
kts has joined #dri-devel
jewins has joined #dri-devel
sdutt has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
off^ has quit [Remote host closed the connection]
<dianders>
javierm / danvet: Thanks for your thoughts on my debugfs woes. At least now I know I'm not crazy and didn't just miss something super obvious. ;-) I'm not convinced I'll manage to find time to do anything quite as major as being discussed. What about something even simpler that moves us in a baby step? Add a debugfs API to "drm_panel" for panels to use. This can be the right API for panels to use long run but for now it doesn't go
<dianders>
further than the panel. Create a top-level "panel" dir in debugfs and then a sub-dir for each panel device under there owned by each panel. Since debugfs isn't ABI this could move later if/when we find a way to hook this into drm more correctly.
<danvet>
dianders, yeah, but maybe we should put the panel under the existing connector debugfs directory
<danvet>
that should be doable I think
<danvet>
dianders, also maybe an option is that the info file also points at the parent object
<danvet>
but that can be added later on
<danvet>
since it's probably better to make the interfaces specific
<dianders>
danvet: The existing connector directory = something like /sys/kernel/debug/dri/1/eDP-1 ?
<danvet>
iow some drm_panel_add_debugfs() and then some magic to make it show up
<danvet>
yeah
<danvet>
maybe that's already too much screaming, dunno
<dianders>
danvet: I just couldn't figure out how to do that. The panel stuff is pretty disconnected from everything else DRM. Even more so now that there's no more drm_panel_attach...
<danvet>
as long as panel drivers only ever call drm_panel_add_debugfs then it shouldn't matter much how we wire it up like you say
<danvet>
dianders, we can't set it up from the panel bridge helpers?
<javierm>
the good thing is what dianders mentioned, that debug is not an ABI so could be done incrementally
<danvet>
like worst case it needs a bunch of calls to a drm_panel_actually_create_the_debugfs_stuff_now(panel, connector);
<dianders>
danvet: I don't think we're guaranteed that the panel bridge helpers are used in any particular case, are we?
jfalempe has quit []
<danvet>
not the greatest, but also not the worst
<danvet>
dianders, yeah but if we take care of the 90% case and encourage people to use more of the standard stuff
<danvet>
and allow the other 10% to work too
<danvet>
then that's good enough I think
<dianders>
danvet: OK. I'll try to find some time later today or tomorrow and dig to see if one of those two options works. Either trigger it off the panel bridge helpers or find a magic place to call drm_panel_actually_create_the_debugfs_stuff_now(). Gotta run for the moment. Thanks!
kts has quit [Quit: Konversation terminated!]
jfalempe has joined #dri-devel
jfalempe has quit []
FireBurn has joined #dri-devel
FireBurn has quit []
FireBurn has joined #dri-devel
jfalempe has joined #dri-devel
FireBurn has quit [Remote host closed the connection]
<pendingchaos>
obviously they can't be in ssbos (not because the spec disallows it, but because it doesn't say how that would work),
<pendingchaos>
anyone know what exactly are the rules for opaque types like OpTypeImage in SPIR-V?
<pendingchaos>
but what about function/private variables? this is mostly disallowed in glsl, but I can't find anything in the spir-v spec about this
<jenatali>
pendingchaos: You can pass them as function args for sure. I believe function-local are disallowed except for SampledImage constructed from image + sampler
<jenatali>
imirkin: Found the difference. The dri frontend treats 3.1 as core, but the wgl frontend treats 3.1 as compat
<imirkin>
jenatali: so with 3.1, there is no core / compat
<imirkin>
it's all 3.1
<imirkin>
but you might expose GL_ARB_compatibility. or you might not.
<jenatali>
With 3.1 it's up to the implementation whether it returns the compat extension (i.e. a compat context) or not, yeah
<imirkin>
core / compat separation came with 3.2
<imirkin>
BUT
<imirkin>
when you ask for some context on linux (e.g. 3.1)
<imirkin>
the driver will just give you e.g. GL 4.6
<imirkin>
gawin: i don't see a record of that in the MR comments
<gawin>
resolved thread
<imirkin>
the one i started. heh. didn't expect anholt's comment in there :)
<imirkin>
gawin: done
<gawin>
in the end I used your suggestion, if suggested by two people then probably it's objectively better.
<gawin>
thanks
<imirkin>
gawin: the do { } while (foo = foo->next) thing is a pretty common pattern
<imirkin>
gawin: fwiw i'm always wary of for loops with weird "next" code
<imirkin>
but obv from a runtime perspective, it's all the same
<gawin>
for me assignments in c are tricky (as quiet casting in background can happen, especially if macros are used)
maxzor has quit [Ping timeout: 480 seconds]
<sravn>
dianders, danvet: We could add the debugfs stuff in the pnale bridge, I think that would be a better fit than adding it to drm_panel. This would also fit the idea that we should (maybe) move over to always use a bridge between the display driver and the panel.
<sravn>
I wanted to type panel bridge
<sravn>
Lots of things has happended while I was away so maybe the bridge ideas have changed since, but I liked how things became simpler with the display driver <=> bridge <=> panel model
i-garrison has quit []
i-garrison has joined #dri-devel
maxzor has joined #dri-devel
<demarchi>
danvet: that would be helpful
nchery is now known as Guest1528
nchery has joined #dri-devel
ybogdano has joined #dri-devel
gouchi has joined #dri-devel
Guest1528 has quit [Ping timeout: 480 seconds]
<anholt>
austriancoder: looks like gc2000 is out of disk space. have you set up a docker-gc cronjob?
devilhorns has quit [Remote host closed the connection]
<jenatali>
Yup, the variables are gone by the time it gets to the driver
devilhorns has joined #dri-devel
rellla has joined #dri-devel
<imirkin>
iirc there's some uniform specialization thing available
<imirkin>
i have no information beyond its potential existence
JohnStultz[m] has joined #dri-devel
<jenatali>
Looks like it's getting nuked from nir_remove_dead_variables somehow
<imirkin>
yeah. so just like gcc 2.96 was optimizing my loops then -- "for () { do stuff }" -- we don't _really_ need that, the program will run much faster without it.
<imirkin>
(i'm definitely not still bitter about that, 20+ years later)
<jenatali>
Er, to be more specific, nir_remove_dead_variables is killing the function_temp array somehow, and once that's gone, pick and pick2 becomes usesless
<jenatali>
Does anybody else use the NIR linker? I searched and I only saw zink with failures for this test in the logs
<imirkin>
without answering that, i can say that it's fairly new
<ccr>
it takes no time to execute if there's no code to run!
<imirkin>
exactly.
<imirkin>
it _did_ run a lot faster
<austriancoder>
anholt: should be working again.. yeah time for a docker-gc job.
<imirkin>
the more annoying thing was that gcc 2.96 wasn't a real release - it was just a CVS checkout RH made at some random point.
<imirkin>
and shipped with RH 6 or so?
<ccr>
something like that
* ccr
gets flashbacks from gcc vs egcs "wars"
<jenatali>
Yeah ok, vars_to_ssa is seeing that the load is undef if it pick and pick2 aren't the same, and therefore the compiler assumes that they have to be the same, which means that the temp array is considered unused, and therefore it and the uniforms are all dead
<imirkin>
i see no problem with that logic.
gawin has quit [Ping timeout: 480 seconds]
<jenatali>
Yep. Test isn't sufficiently smart to circumvent a smart compiler
mbrost has joined #dri-devel
<jenatali>
Yup. Initializing the array fixes the test
Daanct12 is now known as Danct12
frieder_ has quit [Remote host closed the connection]
cworth has quit [Ping timeout: 480 seconds]
<imirkin>
jenatali: tbh i dunno what level of intelligence is "allowed" for optimizing such things out
<jenatali>
Yeah
<imirkin>
(from the uniform API)
<cheako>
does overlay layer depend on internals of mesa?
<imirkin>
although afaik it's "any", so this could be fine
<cheako>
I'm looking to write a vulkan layer.
<pendingchaos>
cheako: I think it's supposed to work with non-mesa drivers, if that's what you mean
<pendingchaos>
it uses stuff in src/util/ and src/vulkan/util though
<cheako>
I can't figure out where it's populating vtable, does it peek inside the opaque vkinstance handle?
<danvet>
mlankhorst, mripard_ tzimmermann ack for adding demarchi in drm-misc?
glLiquidAcidARB has joined #dri-devel
<zmike>
imirkin: this is actually the worst
<imirkin>
:(
<imirkin>
sorry. i shouldn't have looked, and just let someone else slap a r-b on there
<imirkin>
what you don't know can't hurt you!
<zmike>
there's a gtf test that does the same thing
<imirkin>
(esp when it relates to xfb of gl_PointSize)
<zmike>
so in any case it's probably relevant
<zmike>
I think I need a spec bug
<imirkin>
why doesn't this Just Work btw? does vk do the GLES thing of requiring emitting a gl_PointSize?
<zmike>
yes
<zmike>
and according to opengl (core) spec, the pointsize value that's used depends on the state of that enum
<imirkin>
ah. and so then you helpfully stick in gl_PointSize = glPointSize() value. but that doesn't gel with the contents of the shader...
<zmike>
but it doesn't explicitly say whether that behavior also affects xfb
<imirkin>
i would assume that it'd be undefined to xfb gl_PointSize without setting it in the shader
<imirkin>
i _sorta_ assume that without that value set, you're expected to xfb the thing in the shader anyways, even though the glPointSize is different
<imirkin>
but ... not 100% sure
<imirkin>
i'd just export 2 things
<imirkin>
(in the presence of xfb)
<zmike>
actually the worst
<imirkin>
xfbgl_PointSize + realgl_PointSize :)
ybogdano has quit [Remote host closed the connection]
tobiasjakobi has quit [Ping timeout: 480 seconds]
<imirkin>
i.e. aka a ton of work for a corner case no one will hit
glLiquidAcidARB has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
i-garrison has quit []
<mlankhorst>
demarchi: don't have i915 commit rights yet btw?
<jenatali>
Branch point is today, right?
i-garrison has joined #dri-devel
<airlied>
zmike: care to add llvmpipe to it so I can ack it easier :-P
<zmike>
k
<zmike>
airlied: you mean the label in gitlab or ?
<zmike>
llvmpipe doesn't export the cap
oneforall2 has quit [Quit: Leaving]
<Sachiel>
jenatali: yes
<jenatali>
Sad face, just too slow to get GL4 into it
<airlied>
zmike: yes it does, but it's hidden in gallivm
<zmike>
oh
<zmike>
obviously
<Sachiel>
cram it all in now, then bugfix your way through the next couple of weeks
<zmike>
airlied: k
mbrost_ has joined #dri-devel
<jenatali>
Alright, only 2 (hopefully easy) extensions away from GL4.2 now, cool
mclasen has quit [Ping timeout: 480 seconds]
<ccr>
\:D/
mbrost has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
nchery is now known as Guest1551
nchery has joined #dri-devel
<airlied>
jenatali: people only care about compute shaders :-P
<jenatali>
Got those!
Guest1551 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
Mali has lots of data structures where different words are interpreted different ways depending on a "type" word at the start.
<alyssa>
(Think: a "depth" field only existing in a Texture descriptor if it's a 3D texture)
<alyssa>
GenXML can handle this by overlaying all the possibe combinations, but this makes for verbose dumps and seems a bit unsafe.
crabbedhaloablut has joined #dri-devel
<alyssa>
Considering augmenting our XML with `if="mode=3D"` type properties
<alyssa>
but not sure if there's an established way to handle this in existing GenXML's
<alyssa>
Kayden: anholt: ^ not sure if Intel or Broadcom hit this in their respective GenXMLs
<imirkin>
there's definitely some funny business in the media things on intel. i don't think it was handled particularly well in the genxml though.
<alyssa>
*nod*
<imirkin>
iirc there are just a bunch of structs for the "class"-based things, and then the main struct just has a bag of bits without any info on how to interpret it
<alyssa>
*nod*
<imirkin>
airlied: did you never land the crocus media thing?
<airlied>
imirkin: no I had some license rabbit holes to descend and got distracted
<imirkin>
delightful
<airlied>
yeah turns out the gpu vendors don't pay the license fees you'd expect
<imirkin>
alyssa: look in e.g. gen6.xml at INTERFACE_DESCRIPTOR_DATA
<bl4ckb0ne>
the ext in question is VK_EXT_acquire_drm_display, im on polaris10
mdnavare has quit [Read error: Connection reset by peer]
mdnavare has joined #dri-devel
shoragan has quit [Ping timeout: 480 seconds]
<airlied>
alyssa: the cap break glGetUniform, and Khronos guideance so far is that other impls don't do that
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<alyssa>
airlied: grumble... what's involved in fixing the cap?
<airlied>
fixing the glGetUniform path I suppose
<alyssa>
Thanks for volunteering C:
<imirkin>
alyssa: that was a "note to self" presumably? :)
baryluk has joined #dri-devel
Koniiiik has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
<graphitemaster>
I really dislike AMD's approach to open source. "Open" stuff which is just repos of docs and no code or worse - precompiled binaries and no code - this is actually worse than NVs not giving anything *shrug*
<imirkin>
yeah, links in github tend to go stale pretty quickly
<imirkin>
i recently reported such a thing to another company (in an unrelated field)
<imirkin>
to my *vast* surprise they fixed it not by updating the github link but by making the original link work. i guess too many things had the old link :)
nchery has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Remote host closed the connection]
<graphitemaster>
I was able to find more information of what I needed in the Cuda documentation than what I'm able to find in AMDs OpenGPU docs and "open" code.
maxzor_ has joined #dri-devel
<graphitemaster>
I'd consider that a bit of a soft failure since NV has a reputation for being closed as hell lol.
<imirkin>
nvidia has always had excellent developer docs for cuda & co
<imirkin>
(ok, i dunno about literally always ... were those docs really that great for cuda 1.0? probably not. but for a long time)
<graphitemaster>
Bonus points you can actually navigate the cuda docs in a terminal webbrowser
<imirkin>
(they certainly beat trying to do compute in a vertex shader, irrespective of the amount of docs...)
<graphitemaster>
These gpu open docs need 50 js files to load the damn nav bar
pcercuei has quit []
<imirkin>
yeah, i always try my best to minimize that for any web stuff i do
<imirkin>
but it seems like most people don't give a shit
cphealy has joined #dri-devel
<graphitemaster>
I think Fabien Sanglard has the best website I've ever visited: https://fabiensanglard.net/
<pendingchaos>
radeon_info is initialized in ac_gpu_info.c
<pendingchaos>
and for GFX10+ with wave64, we multiply it by 2 so it can be compared with wave32
<pendingchaos>
not sure if the fragment shader lds stuff is correct
<pendingchaos>
result is waves per simd
kgz has joined #dri-devel
Prf_Jakob has joined #dri-devel
<graphitemaster>
pendingchaos, I assume waves in this means wavefronts (i.e groups of 64 threads) - just checking to make sure, no one is consistent with the terminology - I've seen waves used to refer to individual threads in a wavefront which is really confusing
<HdkR>
Waves being used to refer to individual threads is just wrong
maxzor is now known as Guest1570
maxzor_ is now known as maxzor
<maxzor>
Maybe all that's needed is Fabien Sanglard starting writing blog posts about AMD stuff
<maxzor>
graphitemaster, there are various levels of open-source, piles of code without comments nor design considerations, nor any educated engineer making any significant documentation effort is a ring1 layer?
<graphitemaster>
Lets see how good these actually are, going to play around
<maxzor>
is the rocm-smi python wrapper around the c api not enough for your need?
<graphitemaster>
Not to use at runtime in a shipped product to dynamically pick kernels and adjust local size
<graphitemaster>
I really dislike how this information is presented by both AMD and NV as static developer profiling markers and not actually exposed as information in APIs for writing code.
<graphitemaster>
I mean aside from cuda which has all this stuff
pcercuei has joined #dri-devel
pnowack has quit [Quit: pnowack]
JohnnyonFlame has quit [Ping timeout: 480 seconds]