01:27 Venemo: colingpu: specifically to see what is in the preambles, you can disable the usage of INDIRECT_BUFFER in radv_init_graphics_state(). other than the preambles though, you can already see the contents of other command buffers that are executed indirectly - the IB print function should handle them correctly AFAIK
02:37 gfxstrand: Does AMD dumb like Intel and also wants sign-extended addresses?
12:00 bnieuwenhuizen: gfxstrand: in general yeah
12:00 bnieuwenhuizen: if you have anything recent sign-extend the 48th bit
12:01 bnieuwenhuizen: (or 47th if you count from 0 ...)
12:48 HdkR: It's part of the spec that pointers should be appropriately sign extended from bit 48. Canonicalized pointers that the hardware enforces is correct. You need the new Upper-Address-Ignore extension if you want to change that behaviour slightly
12:49 HdkR: Since on x86 only kernel addresses have bit 48 set, userspace shouldn't ever really see it unless someone uses them as tagged pointers.
12:52 bnieuwenhuizen: HdkR: I was assuming the subject was AMD GPUs :)
12:54 HdkR: Yea, if the AMD GPU is enforcing x86 canonicalized pointers then I'm very curious if that feature is toggled off on non-x86 hosts :)
23:11 gfxstrand: Am I reading correctly? It seems like contexts on amdgpu (or at least in radv winsys) don't have any implicit ordering of commands. RADV seems to be sharing a single context across all queues. If there were implicit ordering, wouldn't this mean that queues aren't actually independent?
23:12 gfxstrand: Or is it something where 3D is ordered and compute jobs run independently?