<Frogging101>
Should I replicate what it does in radv code, or should I build addrlib structs and call into addrlib?
<Frogging101>
I'm leaning towards the former being more acceptable, but I'm not sure
<graphitemaster>
Update on my strange bug. If I remove `restrict` from the cubemap image I'm writing to in the shader it works fine on Intel mesa, no garbage data now.
<MrCooper>
doras: given that a 3D_FULL_SCREEN profile exists, that probably should be used for 3D full screen apps :)
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Major_Biscuit has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
kts has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
fab has joined #dri-devel
enunes has joined #dri-devel
heat has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7306
nchery has joined #dri-devel
Guest7306 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rsalvaterra_ has quit []
<doras>
MrCooper: since it's an AMD-specific configuration that requires root to set (and therefore mostly useless for the average user), I was leaning more towards figuring out whether there's a need for a standard uAPI here, or if it's just AMD's bad defaults/bad heuristics and no other vendor actually needs it.
rsalvaterra has joined #dri-devel
<doras>
clever: which distro and kernel do you use? As far as I could tell from the kernel code, the sysfs API is the only way to set it to anything else than the "BOOTUP_DEFAULT" setting.
<doras>
So if it's set to "3D_FULL_SCREEN" by default in your case, it likely means whoever provides your kernel had patched it in.
Duke`` has quit [Ping timeout: 480 seconds]
<tleydxdy>
doras: on arch kernel and with my card 3d full screen is the default
<doras>
tleydxdy: which GPU do you have?
<tleydxdy>
rx580
zehortigoza has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<doras>
tleydxdy: do you have any startup script or any performance-tuning daemon/application that could directly or indirectly affect it?
tarceri has quit [Ping timeout: 480 seconds]
<tleydxdy>
I saw the default in the code
<pinchartl>
is there a way, with a test-only atomic commit, to test plane configuration without having an FB ? I want to check if scaling from/to given sizes is supported, I can create a full commit that would match what I would do at runtime, except that I have no FB available at that point
<tleydxdy>
somewhere in smu7*.c?
<tleydxdy>
I don't remember
Duke`` has joined #dri-devel
<doras>
tleydxdy: ah, then the default likely differs between GPU generations.
<doras>
I never had an issue with my RX 580. It all started with the RX 5700 XT that I got last week.
<tleydxdy>
well, that sounds like a regression then
<doras>
Let me git-blame the line which sets the default for RX 580...
tarceri has joined #dri-devel
<doras>
First of all, it seems that only "smu7" defaults to `PP_SMC_POWER_PROFILE_FULLSCREEN3D`:
<emersion>
these may make some KMS usage impossible
<pinchartl>
it doesn't have to work for real commits
<pinchartl>
only test commits
<emersion>
I mean, a dumb BO wouldn't describe these things
<emersion>
so maybe a test-commit works with a dummy BO, but not with the real BO
<pinchartl>
do you mean that things like SRC_[XYWH] values could be accepted with a dummy BO but not work with a real BO ?
<pinchartl>
I'd like to be able to test plane placement and scaling
<pinchartl>
basically, everything but the BOs
<emersion>
yes, that's what I mean
<emersion>
driver constraints are complicated
<pinchartl>
I can imagine that being the case in theory. in practice... SRC_* validation can certainly depend on the FB (pixel format, pitches, ...), but on the BOs themselves ?
<emersion>
if a test works with a dummy BO, drivers can't always guarantee it'll work for any real BO, even if allocated with the scanout flag etc
<emersion>
well, for one thing, if you have two GPUs and allocate a BO on the other one... it cannot be scanned out on the first
<pinchartl>
right now we have no way to test a plane composition layout before we get an FB for each plane, which is really painful
<emersion>
it is
<pinchartl>
yes, but that's a problem of whether a BO is acceptable or not for a device
<emersion>
with James Jones we had a proposal to properly address this
<pinchartl>
I don't see how it would influence SRC_[XYWH] validation
<emersion>
but its work
<pinchartl>
James' work on the universal device memory allocator (is that how it was called ?) is also something I need, but it's orthogonal to the issue of testing composition layouts without BOs
alanc has quit [Remote host closed the connection]
<emersion>
there's a part about KMS, where you'd submit a KMS test commit with a "dummy" BO, and get back "constraints", which you can feed into the allocator (GBM)
<emersion>
and get a buffer guaranteed to work for that usage
<pinchartl>
yes I've seen that one
<pinchartl>
I still think it's a separate issue from composition testing
<emersion>
this would fix the issue of getting a buffer not suitable for the usage
<emersion>
i don't think so…
<pinchartl>
right now I want to test if a plane can scale from a given resolution to full screen in a given mode
<pinchartl>
and at the point where I want to test that, I have no FB
<pinchartl>
James' work won't help with that use case
<emersion>
it can, see above
<emersion>
> you'd submit a KMS test commit with a "dummy" BO, and get back "constraints", which you can feed into the allocator
<emersion>
getting back constraints instead of "it may work, if you're lucky"
<emersion>
is the important part
<pinchartl>
that's about allocation, to find out how to allocate BOs (and also pick a pixel format, and modifiers) that work cross-device
<pinchartl>
it's a missing component too, but that's not what I'm after here
<emersion>
you're after a way to check whether a KMS configuration is supported
<emersion>
and the driver might need a real BO to give an answer
<emersion>
constraints solve this issue
<pinchartl>
of course, that proposal would introduce a dummy BO that could then most likely also be used for testing composition use cases
<pinchartl>
no, I disagree
<pinchartl>
the proposal passes a dummy BO to an atomic test, and the driver returns constraints
<pinchartl>
that's orthogonal to the issue of testing if scaling is supported
JohnnyonFlame has joined #dri-devel
<emersion>
what if scaling is supported only for 16-byte aligned BOs?
<emersion>
what would the dummy BO test-commit return, true or false?
<emersion>
returning "it works under these buffer constraints" fixes that issue
<pinchartl>
it's an additional problem that has to be handled, but it's not the same problem
<emersion>
anyway, why do you need to know before-hand?
<clever>
emersion: for some hardware (rpi), the scanout doesnt have any special alignment requirements that i know of, but the BO must be physically contiguous, and within the lower 1gig of the physical space
<emersion>
if it doesn't work, you need a fallback
<emersion>
which means you might as well wait to get a BO and see if you can use KMS or not
<pinchartl>
today you can't even test if it works or not, that's hardly a fallback :-)
<emersion>
the fallback is compositing via GL or Vulkan
<emersion>
doing the scaling without KMS
<pinchartl>
my platform has no GPU I can use
<pinchartl>
and if KMS can't do it, I'll error out
<emersion>
ah, embedded
<pinchartl>
but I want to know *before* I get access to an FB
<pinchartl>
the two issues are related. we may conclude that we need to solve both because it's too dangerous to solve the composition test only and leave the BO problem for later, we may then get stuck
fab has joined #dri-devel
<pinchartl>
I can't tell if we have to bundle the two problems because of that, or if we can solve the composition test first in a way that gives us reasonable confidence that it won't hinder solving the BO problem
<pinchartl>
to put it differently, is it acceptable to give applications a test API that does not guarantee the same commit with a real BO will be accepted ? I think it would be quite useful on its own on many embedded platforms
<emersion>
i agree that small steps are best, and a "no definitely not" / "maybe" test API would be better than nothing
<pinchartl>
sounds like we have an endless amount of work to do :-)
<pinchartl>
to give some context
<pinchartl>
I'm working on an application that captures from a camera and display on a KMS plane, with zero copy
<pinchartl>
the camera can capture in different resolutions
<pinchartl>
and I'd like to test what resolutions can be supported with full screen display
<pinchartl>
as I can then pick an appropriate one
<pinchartl>
if I have to allocate BOs just for testing, for every different resolution, that gets very expensive
<emersion>
hm, out of curiosity, would it be possible to allocate with the largest resolution, then create multiple FBs with smaller sizes?
<emersion>
from the same large BO
<pinchartl>
that would be fairly impractical (but one may argue that's because of the whole userspace stack design)
<pinchartl>
it *may* be possible, but that would incur a performance impact in any case, as I'd have to allocate large buffers, to then free them and reallocate smaller ones. that takes time and would be best avoided
<pinchartl>
(of course I could also keep the large buffers regardless of the selected camera capture resolution, but then I'd waste memory)
<pinchartl>
it's "fun" to deal with systems that have 256MB of RAM :-)
* pinchartl
remembers the time when he had to deal with Linux systems with 16MB of RAM
<pinchartl>
there was fortunately no video there
<clever>
i just realized a tricky the pi3 does, the MMIO is at the top 16mb of the lower 1gig
<clever>
and if you set gpu_mem=16 (the smallest it can do), the firmware is also in the top 16mb of the lower 1gig...
<clever>
i suspect the firmware is entirely covered up by the mmio window
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7314
nchery has joined #dri-devel
Guest7314 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest7315
nchery has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Guest7315 has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
fab has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
sravn has joined #dri-devel
lygstate has quit [Read error: Connection reset by peer]
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: Bouncer restarting]
lemonzest has quit [Quit: WeeChat 3.5]
Lyude has joined #dri-devel
kts has joined #dri-devel
nchery is now known as Guest7323
nchery has joined #dri-devel
Guest7323 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
QwertyChouskie has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
reduz__ has quit [Read error: Connection reset by peer]
reduz__ has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
dschuermann has quit [Read error: Connection reset by peer]
dschuermann has joined #dri-devel
nchery is now known as Guest7326
nchery has joined #dri-devel
Guest7326 has quit [Ping timeout: 480 seconds]
<Frogging101>
airlied: I actually can't find anywhere that we call into addrlib aside from src/amd/common/ac_surface.c
<bnieuwenhuizen>
Frogging101: see stuff like AddrComputeSurfaceInfo
<Frogging101>
yes, we call that in ac_surface.c to populate surface fields
<bnieuwenhuizen>
that is a call into addrlib?
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
fxkamd has quit []
<Frogging101>
bnieuwenhuizen: Yes. However, I would be adding this to src/amd/vulkan/radv_meta_bufimage.c. I could pull in the addrlib handle from cmd_buffer->device->ws->addrlib. I'm just saying this might be crossing areas of concern a bit, and this would be the first time
<Frogging101>
(the addrlib handle is stored in the radv_amdgpu_winsys structure)
<bnieuwenhuizen>
Frogging101: what are you doing?
<Frogging101>
I need to do what addrlib's HwlComputeNonBlockCompressedView function does, in radv. The function calculates new mip level parameters and extents for the image view in order to work around the hardware's bad mipmap degradation
nchery has quit [Read error: Connection reset by peer]
<Frogging101>
actualExtentElements is, I believe, equivalent to our u.gfx9.base_mip_width/height
fab has quit [Quit: fab]
<Frogging101>
bnieuwenhuizen: I also wanted to use ComputeSurfaceAddrFromCoord for the GFX9/"second copy" case. PAL uses it to calculate the memory offset into the image to copy from/to