ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
bbrezill1 has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
kts has joined #dri-devel
bluebugs has quit [Quit: Leaving]
sul has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
ella-0_ has joined #dri-devel
sdutt has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
sdutt has quit []
adarshgm has joined #dri-devel
Duke`` has joined #dri-devel
jewins has joined #dri-devel
nchery has joined #dri-devel
jewins has quit []
jewins has joined #dri-devel
bmodem has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
danvet has joined #dri-devel
bmodem has quit []
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
dviola has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
dcz has joined #dri-devel
lemonzest has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sumits has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
kts has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
kts has joined #dri-devel
jfalempe has joined #dri-devel
<pq>
dcz, cool! I also think that instead of 'bind_point = 3553' you should be able to use gl::TEXTURE_2D.
<dcz>
yup, that'll come at some point :)
sul has joined #dri-devel
<pq>
just in case: you can think of GL_TEXTURE_2D as a "slot" (bind point), and you need to glBindTexture an actual texture name to that slot, so that futher calls that operate on the slot affect the right texture. The texture parameters affect the texture, not the slot.
MajorBiscuit has joined #dri-devel
<pq>
samplers in shaders are also programmed to refer to the slot, and will then access whatever texture happens to be bound to the slot during a draw call.
<pq>
glActiveTexture changes the slot, and GL_TEXTURE_2D etc. are... kind of like object types that are bound to or expected in the slot
<pq>
using multiple slots by binding different textures to different glActiveTexture slots allows you to do multi-texturing, which is going to be useful for e.g. reading sub-sampled YUV
<pq>
rendering into textures OTOH uses the FBO attachment slots instead, IIRC, if you want to write into multiple textures at the same time
<pq>
dcz, ^
ahajda_ has joined #dri-devel
tursulin has joined #dri-devel
lynxeye has joined #dri-devel
bbrezill1 has joined #dri-devel
<dcz>
"The texture parameters affect the texture, not the slot." this was not clear to me, thanks
YuGiOhJCJ has quit [Remote host closed the connection]
<JoniSt>
vbt: It'll probably go faster if you edit the bug report template to actually include the information right in the bug report; that way people don't have to download your logs and dig through them just to figure out what hardware you're using
<JoniSt>
The Mesa version is also just missing from the report
<MrCooper>
vbt: sounds like a kernel issue then, not a Mesa one
<JoniSt>
vbt: Well okay, it's visible in the glxinfo output... You're currently running Mesa 22.1.1, which is outdated. Have you tried 22.1.3 or the current git main? Is the bug still present there? (You can build Mesa locally via meson and point your Vulkan loader at the appropriate .so files without installing it on your system)
OftenTimeConsuming is now known as Guest5376
OftenTimeConsuming has joined #dri-devel
Guest5376 has quit [Ping timeout: 480 seconds]
<JoniSt>
vbt: Similarly, it might be worthwhile to try a development kernel, i.e. 5.19-rc7. There have been a lot of drm/intel fixes, maybe one of them already addresses your issue.
itoral has quit [Remote host closed the connection]
fahien has quit [Quit: fahien]
rasterman has joined #dri-devel
<vbt>
JoniSt: i tried mes 22.1.4 too. The error persists
<vbt>
JoniSt: I don't know how to install linux 5.19-rc7 . please sorry :(
<JoniSt>
vbt: What operating system do you use?
<vbt>
MrCooper, if it's kernel issue, how do i proceed?
<vbt>
JoniSt: i do use NixOS currently. have arch and void in other partitions
<JoniSt>
You proceed by first trying a newer kernel (5.19-rc7 in this case) to see if this is a known issue. I'm not quite sure how to properly install a kernel on your OS, unfortunately, since I've always just used Debian. You should be able to find a tutorial on how to compile a kernel with the Arch PKGBUILD system, though.
frieder has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
frieder has quit [Remote host closed the connection]
enunes has quit [Read error: Connection reset by peer]
<ajax>
ugh. KHR_display_reference kinda requires that refcounted default to false.
<ajax>
dumb.
enunes has joined #dri-devel
ybogdano has joined #dri-devel
fahien has quit [Quit: fahien]
ngcortes has joined #dri-devel
krushia has quit [Read error: Connection reset by peer]
<rodrigovivi>
mlankhorst mripard tzimmermann anyone already looking into the issue of drm-misc-fixes merge to drm-tip?
<rodrigovivi>
Merging drm-misc/drm-misc-fixes... Applying manual fixup patch for drm-tip merge... error: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h: already exists in working directory
jkrzyszt has quit [Ping timeout: 480 seconds]
<tzimmermann>
rodrigovivi, i'm going to bed now. please ask in #radeon if you need a quick solution. this amd problem has been going on for a week or so. i'm honestly tired of this s?%$show
* airlied
fixed it at least once already
<airlied>
does it pop up on each merge or something?
tzimmermann has quit [Quit: Leaving]
* airlied
wonders if we should be using a fixup patch to revert some bits from next
danvet has quit [Ping timeout: 480 seconds]
<airlied>
so tip rebuilds cleanly for me here
<airlied>
maybe git clean your drm-rerere?
guru_ has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest5400
srslypascal has joined #dri-devel
gouchi has joined #dri-devel
Guest5400 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
dcz has quit [Ping timeout: 480 seconds]
<rodrigovivi>
no rush on my part... I'm glad if this is not bothering our CI...
<rodrigovivi>
but for me cleaning the drm-rerere didn't help
<JoniSt>
Step 1: Mouse cursor suddenly freezes. Step 2: Think the system has locked up, get a heart attack. Step 3: Realize that you've accidentally pushed your mouse onto its charging cable and now its sensor can't see the mouse pad.
<sravn>
JoniSt: Hope that you have recovered fully from your heart attack!
<JoniSt>
I did! Given how often I've tricked myself with this already, I really shouldn't get frightened by it anymore, but somehow it still gets me :)
nchery is now known as Guest5403
Guest5403 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
<jekstrand>
jenatali: Yeah... between the slack discussion over the week-end and me accidentally adding a pNext loop in my WSI patches a week ago, It seemed like a good idea to check for them. :)
<jenatali>
Yeah makes sense
<jekstrand>
And it was a fun little gag to write up in a meeting.
apinheiro has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
icecream95 has joined #dri-devel
gouchi has quit [Quit: Quitte]
<jekstrand>
dj-death: RE: Supported dynamic state bits.
<jekstrand>
dj-death: The only reason it matters is because only supported things get set in vk_dynamic_graphics_state_fill and only set things get copied in vk_dynamic_graphics_state_copy.
<jekstrand>
So it maybe makes setting pipelines a bit faster for drivers with fewer extensions. Given that most of it is required for 1.3, however, meh?
<jekstrand>
I could easily add an `assert((dst->vb != null) == (src->vb != null));` and wrap the VB set stuff in `if (dst->vb != NULL)`
<dj-death>
yeah just checking
<dj-death>
I guess the common code could clean them up based on enabled extensions too
<jekstrand>
dj-death: Yeah, we could. That's actually not a terrible idea.
<jekstrand>
dj-death: It would mean taking a vk_device in dynamic_state_fill but that would be ok.
<jekstrand>
Let me play
<dj-death>
not trying to prevent stuff from landing :)
<jekstrand>
dj-death: Nah, that's fine. I want to land it right.
<dj-death>
I'll look into !17602 tomorrow
ybogdano is now known as Guest5405
ybogdano has joined #dri-devel
Guest5405 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
dj-death: No, we can't pull it out of the device. The driver wants to assume everything gets copied regardless of enabled extensions. I'm going to drop it all in favor of a couple of NULL checks.
<JoniSt>
Just out of interest, what do GL drivers actually do when an application suddenly decides it wants to map a buffer read+write that had been placed in VRAM on a small BAR system? I'd assume it'll just have to do a bunch of DMA copies...?
<jekstrand>
Yup
<jekstrand>
Likely it does a map which suddenly causes the kernel to migrate the buffer.
<jekstrand>
It may stay in system memory from then on depending on $STUFF
<JoniSt>
Ouch! So the thought of "Let's just persistently map everything and suballocate buffers!" that I had a few months ago when messing with OpenGL for the first time wasn't that great after all :)
<JoniSt>
Vulkan is making me re-evaluate a lot of those choices...
<jekstrand>
Well, it all depends on $STUFF
<jekstrand>
THere's no guarantees with GL, sadly.
<jekstrand>
It may be that the kernel can migrate it into the BAR
<JoniSt>
Hmm, also true... Like all that funny stuff that u_threaded does for performance, it's rather insane
krushia has joined #dri-devel
ybogdano has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<jenatali>
JoniSt: On Windows, if the driver allocated the resource with CPU access, then it's either in BAR or sysmem. If the driver didn't allocate with CPU access, then yeah you get copies on map and unmap