ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
jrmuizel has quit [Remote host closed the connection]
_whitelogger has joined #lima
_whitelogger has joined #lima
dddddd has quit [Remote host closed the connection]
Barada has joined #lima
MoeIcenowy has quit [Ping timeout: 245 seconds]
chewitt has joined #lima
MoeIcenowy has joined #lima
guillaume_g has joined #lima
Wizzup has quit [Ping timeout: 246 seconds]
Wizzup has joined #lima
cwabbott has quit [Read error: Connection reset by peer]
cwabbott_ has joined #lima
MoeIcenowy has quit [Ping timeout: 252 seconds]
MoeIcenowy has joined #lima
Barada has quit [Quit: Barada]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #lima
cwabbott_ has quit [Read error: Connection reset by peer]
afaerber has quit [Quit: Leaving]
cwabbott has joined #lima
embed-3d_ has joined #lima
embed-3d has quit [Ping timeout: 248 seconds]
afaerber has joined #lima
dddddd has joined #lima
jrmuizel has joined #lima
buzzmarshall has joined #lima
Barada has joined #lima
Barada has quit [Client Quit]
Elpaulo has quit [Quit: Elpaulo]
<rellla> heyo lima guys, i need your help ;)
<rellla> i tried to implement ppir fddx/fddy and got a reasonable codegen imho - piglit tests (for example shaders@glsl-derivs) still fail, see http://imkreisrum.de/piglit/glsl-derivs/
<rellla> for comparision i fed the offline compiler with the shader and get the following code:
<rellla> https://pastebin.com/raw/7pBEjn2u , whereas lima results in https://pastebin.com/raw/0ErZH7kw (which also includes some compressed debug infos from the piglit test)
<rellla> my guess is, that it has sth to do with the sync. i don't actually understand, what it does, but maybe it's a problem that dFdx and dFdy are divided into 2 instructions?
<rellla> (in case you wonder, i hardcoded dFdx to scalar slot and dFdy to vector slot for the testing)
<rellla> thats the one issue i have. the second one, personally more interested in, what are the general conditions i have to follow, if i want to combine some instructions after the scheduler?
<rellla> for example that would be instr 001 and 002 in my test case, which contain dFdy and dFdx, both reading from $0 and writing to $1 with different components used.
<enunes> rellla: right now there is no general automatic combining, if you want to (or must) combine them, you have to combine yourself
<enunes> did you read speculation on derivatives https://gitlab.freedesktop.org/panfrost/mali-isa-docs/blob/master/Utgard-PP.md#speculation-on-derivatives and does that make sense to you?
<enunes> maybe they are required to be in the same instruction for some reason? I think you may need to experiment with that
<cwabbott> no, they're not required to be in the same instruction, that wouldn't make any sense
<rellla> enunes: i read that, but i must admit, i don't really understand it ;)
<cwabbott> also, dFdx and dFdy can both go in any slot
<rellla> *any addition slot ?
<cwabbott> yes
<cwabbott> your assembly looks correct
<cwabbott> my (wild) guess is that you're enabling the right bit to enable helper invocations
<rellla> let me push my code somewhere ...
<cwabbott> although that would break texturing too... hmm
<cwabbott> and yeah, sync is required for all instructions that do derivatives and texturing, since threads have to share their results
<cwabbott> you seem like you're doing it correctly
<rellla> i disabled nir_lower_wpos_ytransform temporarily to avoid the load_uniform op, but this should not be the problem
<rellla> maybe there is some other thing missing still... texture based maybe?
<rellla> enunes: regarding the combination, i guess i have to think about the conditions, when the recent instruction can be combined the last one.
<enunes> rellla: I think it's not necessary to care about this now unless it's required
<enunes> which looks like it isn't
<rellla> isn't it an advantage, when instr count goes down?
<rellla> or do you just want to say, "the are much more important tasks now" :)
<enunes> yes but right now it would only be some sort of premature optimization, at some point I think there should be some attempt to do an overall pass combining things when possible
<anarsoul> rellla: if disassembly looks correct but it still doesn't work you should check actual binary
<anarsoul> maybe some "unknown" fields differ
<anarsoul> (that's how I discovered that branch instruction has another "next instruction length" field (for the case when branch is taken)
drod has joined #lima
guillaume_g has quit [Quit: Konversation terminated!]
jonkerj has quit [Read error: Connection reset by peer]
jonkerj has joined #lima
buzzmarshall has quit [Remote host closed the connection]
jrmuizel has quit [Remote host closed the connection]
afaerber has quit [Quit: Leaving]
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 268 seconds]
drod has quit [Remote host closed the connection]
afaerber has joined #lima
jrmuizel has joined #lima