ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<DanaG>
I tried unbind and bind, and it said "no such device".
<DanaG>
(via sysfs)
<karolherbst>
well, it's the correct way of doing that. You can see the bound devices inside drivers/*/ in the sysfs dir of the driver
morphis has quit [Ping timeout: 480 seconds]
<karolherbst>
and then you can just use the address listed there
<DanaG>
I think it only had one of the two GPUs there, as if it died between whatever code made it bindable and whatever code marked it unbound.
<karolherbst>
but your system is messed up now regardless
morphis has joined #dri-devel
<karolherbst>
DanaG: did you use the reset thing?
<DanaG>
It only showed the other GPU. Anyway, I rebooted. It's still failing in the VM, going to see if maybe it doesn't like amdgpu binding to it on the host first.
<karolherbst>
yeah.. it needs to unbind before it can get used in a VM
<karolherbst>
well.. if you pass it through
<karolherbst>
if you use vGPU stuff (no idea if amdgpu supports it), then that's a different case
iive has quit []
<DanaG>
I think the double sysfs registering is a genuine bug somewhere, even without VM in the mix.
<karolherbst>
yeah.. it might be, but maybe it got fixed
<karolherbst>
what's confusing about your log is, that it didn't appear to have unloaded the device before
<karolherbst>
ohh wait.. it did "amdgpu 0000:31:00.0: amdgpu: amdgpu: finishing device" okay.. missed that part
<karolherbst>
"amdgpu: Fail to disable thermal alert!" mhh
<karolherbst>
maybe unloading failed midway
<karolherbst>
anyway.. amdgpu does have code to unload this file, so I suspect something simply went wrong there
<karolherbst>
if you can reproduce it with a simple unbind (and the file is still there) you should file a bug
<karolherbst>
(or fix it)
<airlied>
Lynne: I don't think the headers will settle down, part of the point of releasing them prior to making them final is to actually make them saner, which means changes
<airlied>
like I don't expect any upstream should be shipping against this by default until it's actually released as stable
<airlied>
the header change justifications all happen inside Khronos, there are MRs and a meeting around each change, so it's definitely non-trivial effort to change one
<airlied>
at least for decode, the changes should never be more than 5 mins after a rebase, I don't think decode will change much further at least until implementations find any latent bugs
jljusten has quit [Quit: WeeChat 3.4.1]
<karolherbst>
next week somebody needs to explain to me how all thos modifier stuff should actually work (like, after/when I create the dmabuf_fd, how do I know which modifier to use)
<karolherbst>
ehh nvm.. we get the info, we just don't pass it along
Akari has quit [Ping timeout: 480 seconds]
<karolherbst>
nice, it works :)
<karolherbst>
well.. kind of
jljusten has joined #dri-devel
<Lynne>
airlied: they removed the coded w/h fields
<Lynne>
I checked and there's nowhere else where they're supplied
<Lynne>
I tried to update your branch for that change, but couldn't
mclasen has quit []
digetx has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
icecream95 has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
<airlied>
Lynne: my branch should be updated now
<airlied>
those fields were already encoded elsewhere
neonking_ has quit [Remote host closed the connection]
cheako has joined #dri-devel
DanaG has quit [Remote host closed the connection]
<karolherbst>
sooo.... Texture_2D from a buffer is something OpenGL does not allow, correct? And I assume we have close to 0 code in gallium to support that?
<imirkin>
yeah, there's no buffer <-> mipmap thing
<imirkin>
the thing that comes closest is INTEL_map_texture or something like that
<karolherbst>
I don't need mipmaps for CL though
<imirkin>
you might not need them, but 2d texture implies mipmaps
<karolherbst>
well.. it's optional :(
<imirkin>
there's also "rect" textures, which don't have mipmaps
<karolherbst>
imirkin: right.. let's say in CL you only got one
<imirkin>
but there's no buffer <-> rect stuff either
<imirkin>
rect is just a funny historical abberation, which existed prior to buffers
<karolherbst>
yeah...
<karolherbst>
I've heard
<karolherbst>
was useful to get npot textures
<imirkin>
(basically you wanted NPOT textures, but your hw was POT-only for mipmaps)
<imirkin>
like nv30 and prior
<karolherbst>
anyway.. cl has this extension "cl_khr_image2d_from_buffer" and the name already says what it is I guess :)
<imirkin>
yeah, that's not a thing
<imirkin>
but
<imirkin>
you could fairly easily cast a buffer to a 2d texture if you supply the appropriate stride/etc
<imirkin>
AND that stride is supported by the hw
<karolherbst>
yeah, that's explicit in CL
<imirkin>
e.g. some hw wants things to be 64-aligned, etc
<karolherbst>
so we always have strides
<karolherbst>
either application supplied or runtime conputed
<imirkin>
ok, but just coz the application supplies it doesn't mean the hw supports it
<karolherbst>
and the CL spec also specifies alignment requierements
<karolherbst>
so the runtime returns what it needs
<imirkin>
i see
<karolherbst>
CL_DEVICE_IMAGE_PITCH_ALIGNMENT and CL_DEVICE_IMAGE_BASE_ADDRESS_ALIGNMENT
<imirkin>
should be possible in principle
<imirkin>
but nothing actually supports that atm
<karolherbst>
yeah..
<karolherbst>
just this video editing pro toll using CL depends on that feature, and it would be fun to get it to run
<karolherbst>
it's also core in OpenGL 2.0 (the extension)
<karolherbst>
just wondering how much work it would be to fix e.g. iris
<imirkin>
you mean OpenCL 2.0?
<karolherbst>
ehh, yes
<karolherbst>
it got optional in 3.0 again, but...
<imirkin>
well, at least in nouveau, buffers (incl textures) may be suballocated
<imirkin>
but nouveau does not support any suballocation for texture resources
<imirkin>
so at least for nouveau, it'd be a ton of offset propagation potentially
<imirkin>
(but maybe not, who knows)
<karolherbst>
yeah.. well.. CL needs suballocation for textures anyway :)
<imirkin>
hehe
<zmike>
is the premise that you are reusing a buffer object as a texture or that you're uploading the buffer to a texture?
<karolherbst>
so 2D from 2D is always valid
<karolherbst>
1D from buffer as well
<karolherbst>
just 2D from buffer is optional
<karolherbst>
zmike: rendering needs to be supported
<karolherbst>
as well as image writes
<karolherbst>
well "rendering"
<karolherbst>
more like "texturing"
<zmike>
that doesn't really answer the question though
<karolherbst>
ahh, no, it's the buffer used as a texture/image
<zmike>
so the data is shared?
<karolherbst>
it's like a buffer texture, just in 2d
<zmike>
🤔
<karolherbst>
yep
<zmike>
that's not allowed for fb rendering in core gl
<karolherbst>
yeah, I noticed :)
<karolherbst>
I guess there is a reason why it's an optional CL feature now
sylware has joined #dri-devel
<sylware>
hi, updated mesa/linux-amd today with git, I get a radv memory leak, is this already known, or shall I start to bisect somewhen soon?
<sylware>
(on navi10 lxe)
thellstrom has quit [Ping timeout: 480 seconds]
sylware has quit [Remote host closed the connection]
sylware has joined #dri-devel
<sylware>
hi, again, sorry I was disconnected, anybody?
<imirkin>
zmike: yeah, but at the hw level, not a huge diff between a buffer and a linear non-mipmapped 2d texture
DottorLeo has joined #dri-devel
<DottorLeo>
hi!
<DottorLeo>
Is Vadym Shovkoplias here? :)
LexSfX has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
LexSfX has joined #dri-devel
rasterman has joined #dri-devel
slattann has joined #dri-devel
slattann has left #dri-devel [#dri-devel]
thellstrom has joined #dri-devel
DottorLeo has quit [Quit: Leaving]
thellstrom has quit [Quit: thellstrom]
gawin has joined #dri-devel
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
DottorLeo has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m>
hey, can anyone shortly explain to me what gbm is and whether it's relevant for linux?
<mi6x3m>
in the context of mesa
<mi6x3m>
does it provide solid optimization?
<DottorLeo>
hi again! If i have to attach a renderdoc capture, are there simple instruction to use it even if i'm not a developer? ^^" thanks
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
<DottorLeo>
the problem is that i'm launching my application (Doom 2016) via steam + proton so i can't link directly from Renderdoc (if i understand correctly)
JohnnyonFlame has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<DrNick>
set the launch options to ENABLE_VULKAN_RENDERDOC_CAPTURE=1 %command%
<DrNick>
oh you're asking about the asset copyright issue, nevermind
<DottorLeo>
DrNick, no no i was asking how to do ^^"
<DottorLeo>
from steam?
<DrNick>
yeah
<DottorLeo>
ok i'll try thanks
<DrNick>
I literally figured out how to do this yesterday and then discovered that Hitman 2 ran at less than 1 FPS and eventually hung
<DrNick>
so good luck!
shashank_sharma has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
Lyude has quit [Quit: WeeChat 3.4]
Lyude has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
eukara has quit [Remote host closed the connection]
shashanks has joined #dri-devel
mi6x3m has quit [Quit: Leaving]
shashank_sharma has joined #dri-devel
<DottorLeo>
DrNick, i need to have renderdoc opened before running the game?
<karolherbst>
ehh.. someone wants to add support for llvm bc to clover
shashanks has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<sylware>
the leak is probably fixed with 24049b8771be7bd9044e005565ab9dc327e9dd63
<DrNick>
DottorLeo: you need to run renderdoccmd vulkanregister or whatever its called at least once beforehand
<sylware>
missed it by a few hours/minutes :(
apinheiro has joined #dri-devel
<DottorLeo>
DrNick, i'll try thanks
<DrNick>
you'll know its working because there will be text in the upper left
gawin has joined #dri-devel
sylware has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
DottorLeo has quit [Quit: Leaving]
MajorBiscuit has quit [Quit: WeeChat 3.4]
Danct12 has quit [Quit: Quitting]
Haaninjo has quit [Quit: Ex-Chat]
shashanks has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
shashank_sharma has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
shashanks has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
h0tc0d3 has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: indeed it is, I forgot to push it out, pushed now
h0tc0d3 has quit []
eukara has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: btw there was some confusion over why you mentioned copies in relation to the separated DPB vs DST images
<airlied>
there is no need for the client side to do anything other than allocate the images and pass in the correct references
<Lynne>
I don't get where the confusing part is in "having the driver do copies is forbidden by the spec."
<Lynne>
I was saying that because you mentioned it, and said that the out-of-place DPB handling needs to be implemented because of this
<airlied>
Lynne: the hw does it
<airlied>
so the workflow from the client side is just try allocate DPB|DST combo, if that fails, allocate DPB as a 2d array with ref pics size, and DST as a single image
<airlied>
but yeah I may have confused the issue there
<airlied>
but yeah having the driver doing any large allocation or copies behind the clients back is forbidden
<airlied>
but the firmware is designed like this, so it's not the driver doing it
<Lynne>
that's a technicality and a half when put that way, but okay, not sure why I mentioned it in the first place
<Lynne>
I don't think checking when allocating images would work, since what if for some reason that fails partway into decoding
<Lynne>
the 2 redundant flags for implementations are there to signal that clearly and ambiguously
<airlied>
Lynne: oh you can check upfront
<airlied>
one of Get functions, I'm just not near spec to see which one