<wens>
[ Option "AutoAddGPU" "off" ] should be enough to prevent X from using lima as a display
<wens>
(which of course it can't do)
Barada has quit [Quit: Barada]
minecrell has joined #lima
Da_Coynul has joined #lima
Barada has joined #lima
yuq825 has quit [Remote host closed the connection]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
kaspter has quit [Quit: kaspter]
Barada has quit [Quit: Barada]
Barada has joined #lima
Barada has quit [Quit: Barada]
kaspter has joined #lima
enunes has quit [Ping timeout: 248 seconds]
dddddd has joined #lima
enunes has joined #lima
robher has quit [Ping timeout: 250 seconds]
lvrp16 has quit [Ping timeout: 250 seconds]
smaeul has quit [Ping timeout: 250 seconds]
MoeIcenowy has quit [Ping timeout: 250 seconds]
robher has joined #lima
lvrp16 has joined #lima
MoeIcenowy has joined #lima
smaeul has joined #lima
kaspter has quit [Ping timeout: 264 seconds]
megi has joined #lima
kaspter has joined #lima
kaspter has quit [Remote host closed the connection]
cwabbott has quit [Read error: Connection reset by peer]
kaspter has joined #lima
cwabbott has joined #lima
<nerdboy>
yeah, the "good" log still has "(WW) modeset(0): Option "PrimaryGPU" is not used"
<nerdboy>
hmm, without the second part i get a long string of "(EE) FBDEV(1): FBIOPUTCMAP: Device or resource busy" and then "AIGLX: Screen 1 is not DRI2 capable"
kaspter has quit [Ping timeout: 264 seconds]
<anarsoul>
nerdboy: it's Xorg bug, not mesa or lima
kaspter has joined #lima
kaspter has quit [Quit: kaspter]
jernej has quit [Remote host closed the connection]
jernej has joined #lima
<anarsoul>
enunes: any chance that you'll have some time today to review pp cf MR?
<enunes>
anarsoul: ok I'll comment there today
<enunes>
anarsoul: I think I see a bug in spilling which may or may not affect the reg pressure stuff or ideas, let me give it a try...
<anarsoul>
just use u_upload and allocate spill stack per draw
<anarsoul>
once we implement BO cache performance impact will be negligible
<enunes>
anarsoul: I totally agree and I don't like that solution too much either
<enunes>
at this point I just want to get something that fixes that bug so I'm just trying to get the proposed solution right
<enunes>
I believe my initial solution which was to just allocate a buffer per fs would be much simpler, however I think yuq sees some way in which it wouldn't work
<anarsoul>
so why not to allocate it with lima_ctx_buff_alloc()?
<enunes>
I don't know either, I took it out of ppir_screen at first but yuq suggested to keep it there
<anarsoul>
it's really part of context, not screen
<enunes>
I don't want to refactor it once again in this same MR
<anarsoul>
oh
<anarsoul>
5 min...
<enunes>
and re-test of course
<enunes>
lets see if a quick attempt goes somewhere...
<enunes>
if I understand correctly no because if you add multiple shaders for 1 flush, every one may have a different ctx->fs->stack_size so we really need to record the largest one
<enunes>
pp_buffer_size 0x400 per pp per core is something we got from the blob
<enunes>
sorry, 0x400 per element in the stack per pp/core
<enunes>
what is the effect of the last parameter to lima_ctx_buff_alloc ?
<enunes>
or, the difference between u_upload_alloc and u_suballocator_alloc
<anarsoul>
yes
<enunes>
what is the difference?
<enunes>
we don't have anything to upload, so suballocator?
<anarsoul>
yeah, that'll work if u_suballocator_create() was called with large enough size
<anarsoul>
currently it's 1mb
<anarsoul>
that's 128 temporaries for mali450mp8
<anarsoul>
I'd say it's reasonable size limit
<enunes>
u_upload_create also seems to be default 1mb, but I think it resizes?
<anarsoul>
yeah, u_upload resizes if object doesn't fit
<anarsoul>
u_suballoc just fails
<anarsoul>
(so don't forget to limit spill attempts if you're going to use suballocator)
<enunes>
can you post a comment in that MR proposing this