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!
enunes has quit [Ping timeout: 265 seconds]
nerdboy has quit [Ping timeout: 265 seconds]
enunes has joined #lima
nerdboy has joined #lima
yuq825 has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
megi has quit [Ping timeout: 240 seconds]
nerdboy has quit [Ping timeout: 245 seconds]
nerdboy has joined #lima
_whitelogger has joined #lima
nerdboy has quit [Ping timeout: 276 seconds]
nerdboy has joined #lima
nerdboy has quit [Ping timeout: 276 seconds]
jrmuizel has quit [Remote host closed the connection]
nerdboy has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
_whitelogger has joined #lima
anarsoul|c has joined #lima
nerdboy has quit [Ping timeout: 240 seconds]
nerdboy has joined #lima
nerdboy has quit [Ping timeout: 245 seconds]
nerdboy has joined #lima
dddddd has quit [Remote host closed the connection]
nerdboy has quit [Ping timeout: 265 seconds]
nerdboy has joined #lima
_whitelogger has joined #lima
enunes has quit [Ping timeout: 245 seconds]
nerdboy has quit [Ping timeout: 276 seconds]
enunes has joined #lima
megi has joined #lima
dddddd has joined #lima
megi has quit [Ping timeout: 276 seconds]
afaerber has joined #lima
<MoeIcenowy> yuq825: the misrendering seems to be not related to scissor...
<MoeIcenowy> I checked command stream dump, the scissor is correct
<MoeIcenowy> and even if I disable scissor after clear (before triangle draws), the same result is got
<MoeIcenowy> and mysteriously I got the same result even if I use different resolution
<MoeIcenowy> (I ported this program to waffle, thus it can be run on X/Wayland
<MoeIcenowy> yuq825: the problem is -- VIEWPORT
<MoeIcenowy> I dropped glViewport in the second draw, and manually scaled the coordinates
<MoeIcenowy> and the image become correct
<yuq825> ok
<yuq825> btw. what's the kernel branch are you using?
<yuq825> I find the drm-misc-next is broken on my h3 and s905x
<MoeIcenowy> 5.3.0 with a bunch of my patches (but no lima-related ones now)
<MoeIcenowy> yuq825: does fui() mean int to float?
<yuq825> float to uint
<yuq825> with same binary
<MoeIcenowy> okay
<MoeIcenowy> so I cannot add two outputs of it, right?
<yuq825> yes
<MoeIcenowy> I think I found the solution -- the PLBU VIEWPORT commands specify 4 coordinates
<MoeIcenowy> not a point + a size
<MoeIcenowy> it should be left, right, bottom, top, not x, width, y, height
<MoeIcenowy> yuq825: will draw outside the viewport be dropped?
* MoeIcenowy newbie to GL
<yuq825> I don't think so
<MoeIcenowy> okay
<MoeIcenowy> this problem is not related
<MoeIcenowy> it's just a wrong viewport
<yuq825> viewport just tell the which part of a window is mapped to -1,1
<MoeIcenowy> the viewport is set wrongly as glViewport(64, 64, 128, 128)
<MoeIcenowy> glViewport(64, 64, 64, 64) *
<MoeIcenowy> 64, 64, 128, 128 is the correct one
<MoeIcenowy> (TARGET_SIZE is 256
<yuq825> ?
<MoeIcenowy> yuq825: think what I said above
<MoeIcenowy> when we wrongly feed x, width, y, height to left, right, bottom, top
<yuq825> so you mean PLBU_CMD_VIEWPORT_W should be PLBU_CMD_VIEWPORT_MAX_X?
<MoeIcenowy> yes
jrmuizel has joined #lima
<yuq825> ok, I didn't verify this when taking from lima-ng
jrmuizel has quit [Client Quit]
<yuq825> seems another fundamental bug
jrmuizel has joined #lima
<MoeIcenowy> but unfortunately it's not the reason of the misrender under GNOME...
jrmuizel has quit [Read error: Connection reset by peer]
<MoeIcenowy> yuq825: should glViewport apply when I'm rendering to a FBO?
embed-3d has joined #lima
<yuq825> sure
<MoeIcenowy> yuq825: on GNOME the dock in overview screen is rendered to a FBO
<MoeIcenowy> and then copied to screen as a texture
<MoeIcenowy> however, in my situation, the FBO is empty
<MoeIcenowy> (on lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
<yuq825> maybe related with texture desc which anarsoul mentioned that linear/tiled texture have different desc format
<MoeIcenowy> yuq825: what I found is a 30x23 FBO works, but a 98x357 one doesn't
<MoeIcenowy> the 30x23 is for 2 Chinese characters
<MoeIcenowy> the 30x23 one use a glViewport of (0, 0, 30, 23), which is quite ordinary
<MoeIcenowy> but the 98x357 one uses (0, -502, 804, 1280)... what?!
yuq825 has quit [Quit: Leaving.]
jrmuizel has quit [Remote host closed the connection]
megi has joined #lima
enunes has quit [Quit: ZNC 1.7.2 - https://znc.in]
<MoeIcenowy> anarsoul: comment out lima_bo_cache_free_stale_bos doesn't fix the page allocation failure
jrmuizel has joined #lima
<anarsoul> MoeIcenowy: :(
<MoeIcenowy> anarsoul: but I have GNOME Shell perfectly running on Lima now
<anarsoul> with your viewport fix?
<MoeIcenowy> yes
<MoeIcenowy> and a further fix
<anarsoul> I need to get some coffee before I can review it
<anarsoul> :)
<anarsoul> MoeIcenowy: can you review my BO cache MR? It's been sitting there for 2 weeks already and looks like no one else have enough spare time
<anarsoul> it's a prerequisite for number of other fixes, e.g. for draws with large number of vertices
<MoeIcenowy> anarsoul: I don't know how to do it...
<anarsoul> read the code, comment on specific line if it looks suspicious to you
<anarsoul> if all looks right put your r-b tag in comments
<MoeIcenowy> I mean I cannot understand it fully...
<MoeIcenowy> oops, GNOME Shell is now triggering PP MMU fault
<anarsoul> MoeIcenowy: that can happen if you had alloc failure prior to that
<MoeIcenowy> oops
<MoeIcenowy> then it's the reason
<anarsoul> like immediately prior to that
<MoeIcenowy> not immediately...
<MoeIcenowy> on my second run, there's even on alloc failure, but pp mmu fault happens
<MoeIcenowy> s/on/no/
<anarsoul> then it can be something esle
<anarsoul> *else
<MoeIcenowy> I think alloc failure won't be preserved between two process runs, right?
<anarsoul> no
<MoeIcenowy> as expected
<anarsoul> BOs are per-process
<anarsoul> capture apitrace and analyze it?
<MoeIcenowy> okay
<MoeIcenowy> although analyzing gnome-shell is really a hell
<anarsoul> yeah, it'd be nice to have standalone reproducer
<MoeIcenowy> okay, I have a reproducer now
<anarsoul> great!
<anarsoul> looks like you're mastered the skill of debugging command stream :)
<MoeIcenowy> in the form of a X-based apitrace
<anarsoul> s/you're/you've
<MoeIcenowy> however to replay it some patches might be needed mesa
<MoeIcenowy> to fake RECT and 3D texture support
<anarsoul> I doubt gnome uses rect textures
<anarsoul> or 3d textures :)
<MoeIcenowy> anarsoul: I saw a 1x1 RECT
<MoeIcenowy> I can only say "?!" to it...
<anarsoul> oh, they use this 1x1 texture for some silly purpose
<anarsoul> I remember I read about it :)
<MoeIcenowy> for example?
<anarsoul> they use 1x1 textures for solid color
<anarsoul> and 1x2 for gradients
<MoeIcenowy> anarsoul: BTW, now I only "debug" command streams by guessing on strange glXxx calls in apitrace...
<MoeIcenowy> and try to fix it to find whether it's the cause
<anarsoul> well, I guess that's one of the ways to debug it
<anarsoul> OK, time to review MRs
<anarsoul> yours should be easy, but cwabbott's will definitely take several hours
minicom7 has joined #lima
anarsoul|2 has joined #lima
tbueno_ has joined #lima
<anarsoul|2> MoeIcenowy: just squash these two commits into one
<anarsoul|2> it makes no sense to leave viewport half-way broken
egbert has quit [Disconnected by services]
<MoeIcenowy> anarsoul: suddenly I realized an issue
egbert has joined #lima
<MoeIcenowy> I'm running GNOME Shell on X
<MoeIcenowy> and I don't even know whether is the GNOME Shell is misbehaving or X
mripard_ has joined #lima
anarsoul has quit [Disconnected by services]
anarsoul|2 is now known as anarsoul
<anarsoul> MoeIcenowy: or it's X misbehaving? :)
<anarsoul> MoeIcenowy: that's easy to tell. If you restart gnome-shell and it works fine then it's gnome-shell
<anarsoul> if X session is frozen then it's X
enunes has joined #lima
dddddd has quit [*.net *.split]
mripard has quit [*.net *.split]
tbueno has quit [*.net *.split]
minicom has quit [*.net *.split]
<anarsoul> enunes: I was thinking a bit about register pressure and spilling
<anarsoul> enunes: and I think we should improve scheduler a bit to avoid scheduling too many nodes into a single instruction
<anarsoul> currently it can stuff instruction up till it's full with ALU nodes
<anarsoul> but it increases register pressure
dddddd has joined #lima
<anarsoul> so scheduler should check how many registers instruction needs and if it's higher then certain amount - create another instruction
<MoeIcenowy> anarsoul: X is alive
<MoeIcenowy> thanks for the tip
nerdboy_ has joined #lima
nerdboy_ has quit [Client Quit]
nerdboy_ has joined #lima
nerdboy_ has quit [Client Quit]
<anarsoul> MoeIcenowy: thanks for working on it :)
<MoeIcenowy> I'm now only feeling facing indefinite problems
<anarsoul> you mean it sometimes works and sometimes doesn't?
<MoeIcenowy> no, if I try to trigger for many times, it will finally fail
<MoeIcenowy> however, the count of try is not fixed
<MoeIcenowy> and I don't find a fixed sequence to trigger it
<MoeIcenowy> a fixed sequence without control flow ;-)
<anarsoul> does it spill?
<MoeIcenowy> what's the meaining of "spill" here?
<anarsoul> moved register into temporary, if you run it with LIMA_DEBUG=pp you'll see "spilled register" message
<MoeIcenowy> yes, the control flow here means that it runs on my "BP", brain processor ;-)
<MoeIcenowy> I don't know how many registers my BP have...
<anarsoul> oh
<anarsoul> I think we should add BO labels
<anarsoul> and print list of BOs with labels on ppmmu fault
<anarsoul> to understand what it may try to read
<MoeIcenowy> now I think we really need some fail status in debugfs firstly
<MoeIcenowy> anarsoul: BTW GNOME Shell also uses strange viewports
<MoeIcenowy> and it allocates a scanout buffer with strange size
<anarsoul> how strange?
<anarsoul> (maybe that's the reason?)
<MoeIcenowy> a 1502x2432 one on a 800x1280 screen (PineTab)
<MoeIcenowy> it's the scanout buffer
<MoeIcenowy> it's neither the screen size nor doubled screen size
<anarsoul> hehe
<anarsoul> it shouldn't be an issue though
<MoeIcenowy> anarsoul: the strange viewport is one of my bug discovered
<MoeIcenowy> currently lima cannot deal with negative glViewport Y
<MoeIcenowy> and GNOME Shell uses it
<anarsoul> but I thought it can with your fix?
<MoeIcenowy> yes
<MoeIcenowy> anarsoul: BTW a strange problem
<MoeIcenowy> why is textures rendered as FBO all upside down?
<MoeIcenowy> (I discovered this on analyzing multiple traces
<anarsoul> IIRC that's GL thing
<MoeIcenowy> yes
<MoeIcenowy> I think it might be because of the inconsistency between GL Y axis and the screen one
<anarsoul> yeah, exactly
<anarsoul> IIRC 0,0 is bottom left for scanout but for FBO it's top left
marcodiego has joined #lima
drod has joined #lima
jrmuizel has quit [Remote host closed the connection]
jbrown has quit [Remote host closed the connection]
minecrell has quit [Remote host closed the connection]
minecrell has joined #lima
minecrell has quit [Ping timeout: 245 seconds]
minecrell has joined #lima
jrmuizel has joined #lima
enunes has quit [Ping timeout: 268 seconds]
jrmuizel has quit [Ping timeout: 246 seconds]
enunes has joined #lima
xdarklight has quit [Remote host closed the connection]
xdarklight has joined #lima
libv has quit [Ping timeout: 240 seconds]
libv has joined #lima
jbrown has joined #lima
drod has quit [Remote host closed the connection]
drod has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
minicom7 is now known as minicom
drod has quit [Ping timeout: 245 seconds]
drod has joined #lima
jrmuizel has joined #lima
drod has quit [Remote host closed the connection]
jrmuizel has quit [Read error: Connection reset by peer]
jrmuizel_ has joined #lima