ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Kayden has joined #dri-devel
CATS has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
CATS has joined #dri-devel
<JoshuaAshton>
why did NV even do GL mesh shader
<JoshuaAshton>
In fact, why do they keep making new GL exts
<JoshuaAshton>
It's just a waste of time because there's literally no users for any of their new stuff... :/
<JoshuaAshton>
inb4 one single weird CAD software or something /shrug
<airlied>
CAD software is the reason for mesh shaders at all I think
<airlied>
so probably for some of those
<airlied>
bit also a change they developed the GL ext years ago during bring up to validate the hw :-P
co1umbarius has joined #dri-devel
alanc has quit [Remote host closed the connection]
columbarius has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has joined #dri-devel
Jeremy_Rand_Talos has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<cmarcelo>
karolherbst or rusticl people: is there anything special to run OpenCL-CTS other than entering in meson devenv environment... /me trying to run ./test_basic. (I managed to run some other workload with rusticl, so rusticl itself works).
<karolherbst>
not really
<karolherbst>
you might have to set the CL device type though
<cmarcelo>
and I set RUSTICL_ENABLE=iris
<karolherbst>
it refuses to run on CPU devices in case you tried with llvmpipe
<karolherbst>
ahh.. that should be enough then
<cmarcelo>
I've build my own OpenCL-ICD per OpenCL-CTS instructions, think that could be harmful somehow...?
<karolherbst>
uh...
<karolherbst>
just use the system provided one
<karolherbst>
it's kinda weird.. but there is some differences in how env variables are parsed or something.. dunno
<karolherbst>
the devenv handling _might_ need some adjustments
<mriesch>
peculiar question maybe, but a) what entity allocates memory for an opengl context and b) what memory block size is typically used?
fxkamd has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
greenjustin has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
shashanks has joined #dri-devel
kzd has joined #dri-devel
<karolherbst>
mriesch: what's the context of this question?
<mriesch>
karolherbst: opengl application that exhibits increasing shared memory consumption. i guess there is a memory leak in the opengl context (textures, ...?) but this needs some verification
<mriesch>
the stack is qt, weston, mesa, panfrost
<karolherbst>
soo, it's about CPU memory and a potential memory leak?
<karolherbst>
or well.. might be GPU memory as well
<karolherbst>
well.. you could either use a memory leak detector or file a bug or something
<mriesch>
i assumed that shared mem rather points to gpu memory, but feel free to correct me
fab has quit [Quit: fab]
<karolherbst>
shared memory as in Linux shared memory?
<mriesch>
yes
<karolherbst>
it's memory shared by processes
fab has joined #dri-devel
<mriesch>
karolherbst: well you can see that this is not exactly my area of expertise :-)
<mriesch>
i gave valgrind a shot, but couldn't find anything convincing between all those false positives...
<mriesch>
as to "file a bug", i wouldn't know where -> if my app and qt can be ruled out, it could be mesa (or something below), but that's a big if
<mriesch>
in order to narrow it down, i am reasoning a bit and came up with the questions above.
<MrCooper>
italove: the Gallium HUD changing the application behaviour seems like a bad idea, it means we have to be careful with asking to enable the HUD for narrowing down issues
<mriesch>
e.g., if mesa allocates the gl memory and there is a leak, will there be an increase in shared mem?
smilessh has quit [Read error: Connection reset by peer]
<karolherbst>
no
<karolherbst>
as I said, shared memory is memory shared between processes
<karolherbst>
just because shared memory is used, doesn't mean there is a leak neither
smiles_1111 has joined #dri-devel
<mriesch>
karolherbst: the usage increases with a rate of approx 30 mb per second until the process is killed
smiles_1111 has quit [Remote host closed the connection]
<mriesch>
but ok, different question: can the gpu/gl memory usage be monitored somehow?
<karolherbst>
what's the application?
<mriesch>
a custom video player that takes frames from a gstreamer pipeline and renders them onto a certain geometry
smiles_1111 has joined #dri-devel
<karolherbst>
might want to file a bug against that one
smiles_1111 has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
<mriesch>
karolherbst: yeah, it's my project, so any bug i'll file lands on my desk ;-)
<karolherbst>
would be kinda weird that something trivial like that would trigger memory leaking bugs inside mesa where running weston + other things doesn't?
MajorBiscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
but it kinda depends
MajorBiscuit has joined #dri-devel
<karolherbst>
I'd still suggest checking with valgrind and/or libasan and figure out any reachable or leaked memory
<karolherbst>
and cuming from a project not used by others it's highly likely it's just an application bug
<karolherbst>
maybe you are leaking each frame or something?
<karolherbst>
or it leaks inside gstreamer or.. somewhere
<mriesch>
karolherbst: definitely more likely than a bug in the stack below, but you never know
fxkamd has quit []
<mriesch>
and i thought that maybe one could trace when gl memory is allocated in order to find out what the application, gstreamer, qt, .. is doing wrong
<robmur01>
just an idle musing, but does disabling panfrost's BO cache (PAN_MESU_DEBUG=nocache) make any difference?
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mriesch>
robmur01: i can try that (on monday, though, i think i'll call it a week
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<robmur01>
heh, good plan :)
benjaminl has quit [Ping timeout: 480 seconds]
<MrCooper>
mriesch: no matter how exactly "GL memory" is allocated, there's always some corresponding data structures in normal memory, so leaks of the former correspond to leaks of the latter, which can be caught by valgrind or sanitizers
MajorBiscuit has joined #dri-devel
<mriesch>
MrCooper: ok, i see. then i'll take another stab at that with valgrind
<mriesch>
ok, karolherbst robmur01 MrCooper thanks for your comments and have a nice weekend
<MrCooper>
no worries, you too
fab_ has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
fab_ is now known as Guest2026
Guest2026 is now known as fab
JohnnyonFlame has joined #dri-devel
fab is now known as Guest2027
MajorBiscuit has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<italove>
MrCooper: I see what you mean, but if we just revert the patch the original problem will still exist: apps that use partial redraw have to disable it if they want to use gallium hud, because otherwise the gallium hud won't be drawn correctly. So, I'm guessing maybe the solution here would be to revert and then print some kind of warning when buffer
<italove>
age is queried if gallium hud is active? This way the user can manually override the extension if they want to get rid of the artifacts.
<MrCooper>
yeah maybe, or a GALLIUM_HUD option to disable buffer age
sgruszka has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
junaid has quit [Remote host closed the connection]
sassefa has joined #dri-devel
<italove>
MrCooper: the problem with just making it an option without a warning is that the user will have to first figure out that their artifacts are caused by the gallium hud not being accounted for in the buffer age.
sarahwalker has quit [Remote host closed the connection]
jfalempe has quit [Quit: Leaving]
<MrCooper>
true
idr has joined #dri-devel
alanc has joined #dri-devel
djbw has joined #dri-devel
<benjaminl>
lol no idea. I've seen exactly one use of this in the wild, which was for a minecraft rendering plugin: https://github.com/MCRcortex/nvidium
<benjaminl>
it kinda makes sense in that context, since the rest of the rendering pipeline is GL, and will be forever
<benjaminl>
(in response to earlier message about GL_NV_mesh_shader)
vliaskov_ has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
sukrutb has joined #dri-devel
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
<emersion>
hwentlan_: might be interesting to you: [PATCH] drm/vkms: Add support to 1D gamma LUT
<emersion>
ah you were cc'ed
vliaskov has joined #dri-devel
rauji___ has quit []
vliaskov has quit [Ping timeout: 480 seconds]
pallavim_ has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
<sassefa>
Trying to learn how to make my own impl of drm_info. So far I'm just browsing xf86drm.h and xf86drmMode.h manually trying to find the funcs I need
<Venemo>
Lynne: the current code only anticipates sumbitting graphics+compute together, and this needs to be extended to also support compute + sdma, this is what I meant by refactoring
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
<benjaminl>
sassefa: there are some man pages, but they aren't very comprehensive. I mostly just read the source code
<benjaminl>
the kernel docs are also useful
JohnnyonFlame has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
mattrope has joined #dri-devel
rasterman has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
gouchi has joined #dri-devel
dtmrzgl has quit [Remote host closed the connection]
dtmrzgl has joined #dri-devel
gouchi has quit []
<sassefa>
do i respond to someone by putting their name first like this?
<sassefa>
benjaminl: thanks!
mattrope has quit [Remote host closed the connection]
mattrope has joined #dri-devel
pallavim_ has quit [Remote host closed the connection]
pallavim_ has joined #dri-devel
<hwentlan_>
emersion, thanks. that'll be useful
<emersion>
i think it's missing interpolation though
<gfxstrand>
jenatali: Okay, that's a bit more nuanced understanding than I picked up elsewhere.
<gfxstrand>
Annoying.
<jenatali>
Very
<jenatali>
Those are our only failures :(
<gfxstrand>
So you can do everything, if only you had LOD on shadow samplers :facepalm:
<jenatali>
On WARP anyway, I haven't really been trying the hardware vendors since we added so many D3D features that haven't been implemented yet
<jenatali>
Yep pretty much
<jenatali>
If I turn off DXIL validation, it works fine on WARP, NVIDIA, and AMD, but crashes on Intel...
<gfxstrand>
And with limited sampler pools, I don't suppose you want to double up samplers just for LOD.
<gfxstrand>
Intel is being dumb. The instruction totally works. Probably something in their compiler.
<jenatali>
Yep, exactly
<gfxstrand>
Can you rush out a SM 6.7.1 that just adds the LOD thing? ;-)
<jenatali>
I take it that this discussion is because our potential waiver request made it to the working group? I hate not being able to participate directly...
<gfxstrand>
Yeah, I wasn't paying attention to my e-mail this week and just now saw it fly by.
<jenatali>
I tried. Our compiler team doesn't have a way to do that really. SM6.8 is due in the fall and should have these
<gfxstrand>
Trying to form an actual opinion based on all the information, not just the existential "OMG is this HW or SW?!?" crisis that the rest of Khronos is having. 😅
<jenatali>
:P
<jenatali>
I appreciate that
<gfxstrand>
I missed our Wednesday meeting where this was apparently discussed. I'll try to make sure I'm in the next one.
<jenatali>
Thanks. Hopefully we'll be able to set up a meeting where we can talk to the working group outside of the IP framework that gives our legal group heartburn
<gfxstrand>
Yeah. That'd be nice.
<gfxstrand>
We can have IP-free portions of WG meetings, they just have to be set up special.
<jenatali>
Yeah
<jenatali>
We've done it for CL and GL before
<gfxstrand>
Unfortunately, now that I do have all the information, you you may not like my opinion...
<jenatali>
That's fine
sima has quit [Ping timeout: 480 seconds]
<gfxstrand>
On the other hand, if D3D doesn't have those sampler ops, the chances of apps making heavy use of them are low...
<gfxstrand>
GL just likes to ADD ALL THE THINGS
<gfxstrand>
Not being able to do LOD on a shadow sampler is really annoying, though.
<jenatali>
Yep, to all of the above lol
<gfxstrand>
IDK that apps want it, I'm just thinking from a layer/workaround perspective.
<gfxstrand>
That and TXS are our favorite tools for getting around texop weirdnes.s.
<jenatali>
Yeah txs is fine, it's just our shadow samplers that are... weird
<jenatali>
Whatever the working group ends up deciding, we'll obviously be beholden to, but I'd be doing us a disservice if I didn't try to plead my case
<gfxstrand>
Silly shadow samplers
<gfxstrand>
That's totally fair
<gfxstrand>
And whatever happens, this problem will eventually be behind us. Everyone can do LOD on shadows in hardware, we just need to bump all the versions of all the things everywhere and that takes time.
<grillo_0>
Hey emersion, I'm the guy from the VKMS 1D LUT patch. I think I can add the missing interpolation. This patch was part of a patchset that I'm working on, the patchset focuses on adding NV12 support to VKMS. The LUT was needed to make the test igt@kms_plane@pixel-format pass on the new format.
<emersion>
grillo_0: have you tried other tests with LUTs? are there some failing because of the missing interpolation?
<grillo_0>
I tried only the kms_color and pixel-format.
<emersion>
i'm not sure interpolation is actually required by the KMS API
<emersion>
the docs do mention interpolation
<emersion>
but in an indirect manner
<grillo_0>
Yeah, I didn't know that the interpolation was mandatory when working with LUTs, I will fix it :).
<emersion>
no worries, i'm not sure myself! and thanks for working on this :)
<grillo_0>
You're welcome :)
a-865 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
a-865 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
any1 has quit [Remote host closed the connection]
any1 has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
smilessh has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]