<libv>
gah, they are copying only the relevant attributes, then using a buffer offset anyway, making the attribute reference back from the copied attributes by that offset
<libv>
and that probably works when using some symbolic reference to the memory, which the kernel then nicely translates
<libv>
but is refused when i do it
afaerber has quit [Quit: Verlassend]
dlezcano_ has quit [Quit: Leaving]
dlezcano has joined #linux-exynos
ssvb has joined #linux-exynos
<Wizzup>
libv: yeah I haven't really played with the mali binary drivers on any of my exynos hw
<Wizzup>
mostly because I try to refrain from using binary stuff, I guess
<si1v3r>
free 2d is nicer than gimpy 3d. :/
RSpliet has left #linux-exynos [#linux-exynos]
<libv>
Wizzup: it somewhat makes sense now
<libv>
at first i really thought i found a nasty bug
<libv>
although it is nasty, it is probably not a bug
<libv>
just very very ugly, and hard to parse, especially since this is also going to be how framebuffer objects are being handled
<libv>
in one case that i have now, the memory reference actually falls just before what the mali knows
<libv>
perfectly legal, as the hw will try to access that address with an offset, putting it just inside the known address range
<libv>
but a bitch for me to automatically parse
<libv>
and apparently, it cannot be replayed as easily, although i am not sure what is causing that, and i do not want to go and find out right now
<Wizzup>
ah, that's ... not very nice
<si1v3r>
Hey look, 4 penguins on a peach pit. neat.