ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tursulin has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<idr> So... the finalize_nir hook is called twice.
<idr> This is a bummer because many of the lowering passes that we run, only need to be run once.
columbarius has joined #dri-devel
<idr> And nir_lower_gs_intrinsics only can be run once. :(
bluebugs has joined #dri-devel
<idr> It looks like the only other Gallium driver that uses that pass is zink.
co1umbarius has quit [Ping timeout: 480 seconds]
<idr> zmike: ^^^ How does zink not end up with multiple set_vertex_and_primitive_count in geometry shaders?
<idr> With the last set_vertex_and_primitive_count setting everything to zero. :(
<zmike> uhhh
mbrost has joined #dri-devel
<zmike> probably don't call that in finalize?
<zmike> 🤷‍♂️
<idr> zink does.
<zmike> does it?
<zmike> huh
<idr> Without massively restructuring a pile of our shared code, I don't have that luxury.
* zmike is better than he thought
<zmike> dunno
<zmike> I guess I'm just that good
<idr> Uh... ok.
<zmike> (I really have no idea)
<zmike> if you end up figuring it out, I'm interested since this was always one of those things that "just works"
Hi-Angel has quit [Ping timeout: 480 seconds]
<idr> zmike: I am not sure how it could work. :( The output of NIR_PRINT=1 on any geometry shader test could enlighten things.
<idr> I've been using glsl-fs-fogscale.
<idr> I have a couple commits that fix the problem I was encountering with that test and finalize_nir hooked up.
<zmike> maybe it's just not finalizing twice for me?
<imirkin_> does OpenCL have a "ssbo" equivalent? something where you'd do untyped stores to a resource with a base address?
<imirkin_> i know you can pass in pointers to stuff, but that generally gets implemented as general writes to VA, not the ssbo-type writes
<samueldr> I'm observing something that makes no sense; related to that divide by zero...
<samueldr> ideal is 1073742035; in clk_hw_round_rate, `rate` (the second param) ends up being 0
<imirkin_> samueldr: 32-bit platform?
<samueldr> yeah
<imirkin_> i think that's a known issue
<imirkin_> where rounding fails
<imirkin_> at least i def remember seeing stuff about that
<imirkin_> where if the clock values are too high (and 1GHz is certainly pretty high) you get messed up results
<samueldr> but how would that value become zero at the function call "boundary" ?
<imirkin_> samueldr: it wouldn't
thellstrom has quit [Read error: Connection reset by peer]
<imirkin_> i would suggest that your analysis is incorrect somehow
<imirkin_> i.e. the value isn't 0 like you think it is
thellstrom has joined #dri-devel
<samueldr> I added if (WARN(rate == 0, "clk_hw_round_rate, rate is zero."))
<imirkin_> where
<samueldr> to clk_hw_round_rate; and it hits
<samueldr> and using %ld to printk() the value
<imirkin_> so "ideal" is 0 then?
<samueldr> ideal = 1073742035
<imirkin_> do you print that before the warn?
<airlied> imirkin_: some thing lower opencl globals to ssbos
<airlied> things
<imirkin_> airlied: that's a driver decision, right?
<airlied> imirkin_: yes
<imirkin_> airlied: basically i have an opencl impl that i'm trying to get to use ssbo's
<imirkin_> i've thus far been unsuccessful, but i also don't actually know CL
<imirkin_> airlied: the situation is that on a4xx, the blob that came with my board only has ES 3.0. the later blobs that come with various android phones don't seem to execute successfully on the board.
<imirkin_> (and my attempts to do what those later blobs do have also not resulted in working ssbo's)
<samueldr> imirkin_: I print `ideal` before the function call; in the function I print `rate` before the warn
<imirkin_> samueldr: surprising :)
<airlied> imirkin_: yeah can't think of a way to make that happen from CL API
<samueldr> imirkin_: indeed!
<imirkin_> samueldr: one might even say ... not ideal
<samueldr> I'm not discounting that my instrumentation could be flawed, but at a glance it doesn't look wrong
<imirkin_> samueldr: put up a "git diff" somewhere?
<samueldr> yeah, I was actually thinking about that
<airlied> imirkin_: can you lower ssbos to globals? :_
<airlied> :-)
<imirkin_> airlied: yea
<imirkin_> airlied: i might just do that...
nchery has quit [Quit: Leaving]
<imirkin_> airlied: but there's a lot of overhead to doing that
<imirkin_> airlied: most importantly, bounds checking
<airlied> yeah sounds like bounds checking in the shader might be all the hw can do
<imirkin_> well ... it's the same descriptors as for images
<imirkin_> (which i can definitely get CL to make use of)
<imirkin_> and the "newer" blobs also use them
dhwohrom^ has quit [Remote host closed the connection]
<samueldr> (though there is a yet untested change building from %d -> %lld for ideal)
<imirkin_> samueldr: well, long == int, right (on 32-bit)
<samueldr> it was a warning from the compiler
<samueldr> so I wanted to be thorough
<samueldr> right, so ideal is zero
<samueldr> now that I've re-instrumented with %lld
* samueldr hates C :)
mbrost has quit [Ping timeout: 480 seconds]
<samueldr> footguns at reach all the time, but that's not for this channel
<jenatali> imirkin_: CLOn12 lowers global mem to SSBOs
<imirkin_> jenatali: the situation is i'm tracing what a driver is doing
<imirkin_> jenatali: so i want to force that driver to use ssbo's somehow
<jenatali> Ohh
<jenatali> Yeah, no, the CL API doesn't have that, it's just memory
<imirkin_> well, the CL api has images
<imirkin_> which will require the driver to use some sort of descriptor
<imirkin_> is there a way to do untyped writes to images?
<jenatali> Uh... nope, don't think so
<imirkin_> e.g. to have a RGBA8 image, but just write U32's to it
<jenatali> You can create buffer image views, but that's still typed
<airlied> jenatali: I did some light clover on zink on vulkan hacking last week, had to do that lowering :-P
bluebugs has quit [Ping timeout: 480 seconds]
<imirkin_> right ok
<imirkin_> sorta what i expected, but thanks for confirming
<jenatali> airlied: Sharing lowering passes or doing something different?
<jenatali> I know a bunch of the stuff in CLOn12 is very hacked together before I really knew anything about how to write proper lowering passes so probably not easy to share right now
<samueldr> would a change similar to this be appropriate?
<samueldr> correct, maybe not though
<samueldr> I can't say it makes things work, but it makes things less wrong on my already shaky foundations
<samueldr> (continuing assuming tcon0 actually works, since right now writing to the framebuffer through DRM doesn't hang userspace for a while like it did when it was failing)
<airlied> jenatali: I cut-n-paste yours but it needs adapting, due to other lowering
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
pnowack has quit [Quit: pnowack]
boistordu has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
Bennett has quit []
dfip^ has joined #dri-devel
<marex> samueldr: how do you reach ideal == 0 ? u64 ideal = (u64)rate * i; so either i == 0, which means dclk_min_div == 0 or rate == 0 , which one is it ?
* samueldr looks back
idr has quit [Quit: Leaving]
<pinchartl> samueldr: looks fishy
<samueldr> (to be 100% clear I'm out of my depth with clock stuff :))
<samueldr> though it was stated earlier that on 32 bit (allwinner) platforms things are screwey
<pinchartl> the problem seems to be that dclk_min_div is 0
<pinchartl> that's not right
<pinchartl> a clock divisor of 0 isn't valid
shadeslayer has quit [Quit: Ping timeout (120 seconds)]
shadeslayer has joined #dri-devel
<pinchartl> that's what you need to fix, not hack around it by a check in the loop
<samueldr> when I said I'm out of my debt with clock stuff, it means I have no idea where to start really looking into that right now
<pinchartl> it happens to be in clock-related code, but the problem isn't specific to clocks
<pinchartl> it's just C
<pinchartl> look at where dclk_min_div comes from, and figure out why it's 0
<samueldr> in a pretty big codebase, with a lot of background knowledge about hardware
<pinchartl> and then fix that
<samueldr> I'm not saying I won't, but that "just" is probably the most loaded word to use
<samueldr> but yes, as I said when I shared that initially, it's unlikely to be the *solution*, but I wanted to move forward with other things; the division by zero broke so many things that maybe working around would have pointed me to the actual issue
bluebugs has joined #dri-devel
<samueldr> but, with that said, thank you pinchartl, as *in this case* it looks trivial enough, and that nudge into looking at dclk_min_div helped
<samueldr> (forward port of the older patch set did not include what must be a new property)
bl4ckb0ne has quit [Ping timeout: 480 seconds]
bl4ckb0ne has joined #dri-devel
NiksDev has joined #dri-devel
dviola has quit [Quit: WeeChat 3.2]
kem has quit [Ping timeout: 480 seconds]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
danvet has joined #dri-devel
mattrope has quit [Ping timeout: 480 seconds]
Hi-Angel has joined #dri-devel
mlankhorst has joined #dri-devel
Guest6808 has quit []
thelounge63 has joined #dri-devel
Company has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
lemonzest has joined #dri-devel
<airlied> jenatali: the entrypoint vs call MR is finally ready for merging :-P
tursulin has joined #dri-devel
rasterman has joined #dri-devel
jkrzyszt has joined #dri-devel
pnowack has joined #dri-devel
<pq> ajax, yes, I know alpha is always linear. My puzzle is, that when anything does premult, they multiply alpha into non-linear RGB values. That is the exact wrong thing to do if your aim is to filter or blend correctly, that is, in light-linear values to better match physics.
thellstrom1 has joined #dri-devel
<pq> mareko, ahh, that's what you meant with associativity. Ok. I never thought of that case, because it requires an extra temporary render target to hold (a o b).
thellstrom has quit [Ping timeout: 480 seconds]
<pq> swick, for normal blend the order *does* matter. If your stack is bg, a, b, then blending b into bg before a into bg would be wrong.
LaydLis21F has joined #dri-devel
LaydLis21F has quit []
<pq> Perhaps the assumption I got wrong is how premult is done in apps and toolkits; do they actually multiply alpha into light-linear RGB values and *then* convert to the sRGB non-linear encoding for 8 bpc?
<pq> That's an important question for Wayland which is premult by default, but there being two different ways of doing premult.
<pq> and we never wrote down which premult it is
<pq> A different matter is whether compositors convert to light-linear representation before blending or not. I've been assuming that most (all?) do not.
<pq> For premult the big question is: which way does Cairo do it?
sdutt_ has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
kem has joined #dri-devel
pcercuei has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
xexaxo has joined #dri-devel
jhli has quit [Remote host closed the connection]
xexaxo_ has quit [Ping timeout: 480 seconds]
quasselcore_ has joined #dri-devel
xexaxo_ has joined #dri-devel
quasselcore has quit [Ping timeout: 480 seconds]
xexaxo has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
xexaxo has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
Net147_ has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
Net147_ has quit [Remote host closed the connection]
Net147_ has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
Net147_ has quit [Read error: Network is unreachable]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
Peste_Bubonica has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Duke`` has quit []
yoslin has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
yoslin has joined #dri-devel
pcercuei has quit [Quit: brb]
jkrzyszt has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dviola has joined #dri-devel
iive has joined #dri-devel
hansg has joined #dri-devel
<mripard> sravn: if you have a bit of time, could you review ?
jewins has joined #dri-devel
<marex> there is one thing I don't quite understand, maybe someone can give me a hint ...
<marex> with latest mesa (although it goes back quite a bit) with etnaviv (might be irrelevant), qt5 with eglfs backend does eglChooseConfig(... EGL_SURFACE_TYPE, EGL_PBUFFER_BIT ...) and returns zero available configuration
<marex> but eglChooseConfig(... EGL_SURFACE_TYPE, EGL_WINDOW_BIT ...) returns 4 configurations
<marex> both return EGL_SUCCESS , i.e. it is not an error
<marex> why is it not possible to allocate the pbuffer ?
macromorgan has joined #dri-devel
<MrCooper> marex: may depend on the platform, GBM & Wayland platforms don't seem to support PBuffers (or pixmaps)
<marex> MrCooper: got any details on the later part , starting with GBM .... ?
<zmike> emersion: so you're saying the kms stuff can just be removed entirely since that should only hit gbm?
<marex> that sounds odd, why wouldnt they ?
<MrCooper> marex: don't know why, just that they currently don't according to eglinfo
<emersion> zmike: yea
<zmike> cool
<emersion> zmike: assuming resource_get_param is implemented
<zmike> it is
<emersion> cool
<emersion> then yeah i'd just fail on KMS queries
<zmike> sgtm
<emersion> supporting KMS handles would be a bit annoying
Company has joined #dri-devel
<marex> MrCooper: oh, I should check eglinfo indeed, thanks for the hint
<marex> I still wonder why the pbuffer support is missing, it just doesn't make sense to me
<pq> marex, probably no-one bothered to wire it up and no-one asked for it. It's not the first time with pbuffers.
<pq> marex, people tend to use FBOs and textures/render targets nowadays instead, or surfaceless EGL platform if offscreen-only is your aim.
<marex> pq: it is for offscreen, yes
<pq> funnily enough, surfaceless EGL platform supports pbuffers :-)
<marex> pq: what am I looking for in mesa (I presume this is mesa thing, where else would it be) ?
<marex> hm
<pq> a moment...
<marex> src/egl/drivers/dri2/platform_surfaceless.c no ?
<marex> except I need it for somewhere else
<pq> EGL_PLATFORM_SURFACELESS_MESA and eglGetPlatformDisplay(EXT)()
co1umbarius has joined #dri-devel
<pq> checking that the needed EGL extensions are actually advertised for this is a bit of a chore
<marex> pq: wait a moment ...
<marex> that suggestion sounds familiar
<marex> pq: specifically comment 6
columbarius has quit [Ping timeout: 480 seconds]
<pq> marex, surfaceless context is a different thing from surfaceless platform. I am referring to the platform.
<marex> pq: so if I grep right, this is not mesa driver specific , is it ?
<pq> it's not driver-specific I guess, or I don't know why it would be
f11f12 has quit [Quit: Leaving]
<pq> marex, it talks about surfaceless context, not platform.
<marex> pq: I think I am confused, just like comment 6 above
<marex> pq: why would I care about surfaceless platform with qt5 ?
<pq> yes, surfaceless context and surfaceless EGL platform are completely different things
<pq> marex, because you said you wanted pbuffers for off-screen-only rendering.
<pq> I have no idea what qt5 is about.
<pq> EGL platform is "which window system do you connect to and how", where surfaceless means "none, no display".
<marex> pq: they request a bunch of pbuffers for offscreen rendering as far as I can tell
<pq> surfaceless context extension means: you can eglMakeCurrent with EGL_NO_SURFACE.
<marex> ah
<pq> to confuse everything, you don't have to rely on surfaceless context extension on surfaceless EGL platform, because there you can create a pbuffer surface. :-)
<marex> pq: I spent most of yesterday digging through that qt5 code and mesa, trying to wrap my head around what's going on there, I think I am already positively confused :)
<pq> marex, I suppose you *don't* want off-screen *only* rendering, but both off-screen and on-screen, since you're talking about qt?
<pq> in that case, sorry for mentioning surfaceless EGL platform. It does off-screen only.
<marex> pq: well, can't you render off-screen and then have scanout engine display the result ?
<pq> sure, that's called on-screen :-)
<marex> oh, well ...
<pq> ...with double buffering
<marex> pq: just for clarity, the surfaceless platform is mostly for testing, I recall seeing it used with dEQP
<marex> right ?
<pq> but yes, you could use purely off-screen setup, and import a display-capable buffer for rendering
<pq> well... testing is one, GPGPU also, not sure if wlroots uses it with the above mentioned buffer imports
<marex> hmmm, maybe I just need to add .create_pbuffer_surface in ?
mattrope has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
nchery has joined #dri-devel
sdutt has joined #dri-devel
azorshi has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<marex> I am about to test it
mlankhorst has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
bluebugs has joined #dri-devel
<sravn> mripard: yep, I will take a look tonight or sunday
bluebugs has quit [Read error: Connection reset by peer]
bluebugs has joined #dri-devel
Duke`` has joined #dri-devel
<mripard> sravn: awesome, thanks
bluebugs has quit [Quit: Leaving]
Daanct12 has joined #dri-devel
Daanct12 has quit []
sdutt has quit []
sdutt has joined #dri-devel
JohnnyonFlame has joined #dri-devel
cedric has joined #dri-devel
Anorelsan has joined #dri-devel
cedric has quit []
Danct12 has quit [Ping timeout: 480 seconds]
cedric has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
camus1 has quit []
cedric is now known as bluebugs
camus has joined #dri-devel
<imirkin_> how does one read back the contents of an image in OpenCL?
<imirkin_> (i.e. in the C program)
Danct12 has joined #dri-devel
<imirkin_> someone needs to register
<imirkin_> oh. it's already registered. but not nearly as useful as
<jenatali> imirkin_: clReadImage?
<jenatali> Oh, clEnqueueReadImage
<imirkin_> thanks
<imirkin_> ok cool, that looks perfect
nsneck has joined #dri-devel
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
mbrost has joined #dri-devel
gouchi has joined #dri-devel
<jekstrand> General question: I just finished making my Ray-tracing pt. 2 slide deck for XDC next week. It's 46 very dense slides. No way it's going to fit in 45 minutes. What would people be more interested in: Shader compiling for ray-tracing pipelines or BVH building?
<jekstrand> My current thought is see how far I get and maybe organize a BVH building break-out
<jekstrand> Because I think it'd be good to have back-and-forth there.
<jekstrand> Thoughts?
<jekstrand> bnieuwenhuizen: ^^
<imirkin_> i'd definitely be interested in a good talk about BVH, whether it's yours or someone else's
<jekstrand> I'm not going to talk about actual BVH algorithms, FYI
<imirkin_> (although full disclosure, i will not be attending in any capacity. but i do watch the videos afterwards.)
<jekstrand> Just about the annoying complexities of launching piles of OpenCL kernels to do it
<imirkin_> ah
macromorgan is now known as Guest6898
macromorgan has joined #dri-devel
Guest6898 has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<daniels> jasuarez: rpi farm seems v unhappy
ngcortes has joined #dri-devel
<jasuarez> I'll check
<jasuarez> Thx
hfink has quit [Remote host closed the connection]
seanpaul has quit [Read error: Connection reset by peer]
CosmicPenguin has quit [Remote host closed the connection]
ezequielg has quit [Remote host closed the connection]
zmike has quit [Remote host closed the connection]
hfink has joined #dri-devel
CosmicPenguin has joined #dri-devel
seanpaul has joined #dri-devel
ezequielg has joined #dri-devel
zmike has joined #dri-devel
<jasuarez> daniels: it's up now
<jasuarez> i've restarted some of the broadcom jobs, they seemed stuck
<daniels> jasuarez: thankyou!
<jasuarez> 👍️
gouchi has quit [Remote host closed the connection]
Anorelsan has quit [Quit: Leaving]
alyssa has joined #dri-devel
* alyssa mumbles
<alyssa> Xorg is giving me an atomic_flush before i've signaled the previous vblank event... DCP does not like.
<alyssa> (wayland and simple-fb are fine)
imirkin_ has quit [Quit: Leaving]
pnowack has quit [Quit: pnowack]
<alyssa> or maybe not that. something is definitely broken in how I'm handling vblanks
mlankhorst has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
<alyssa> I guess there's no in-tree precedent for this firmware-managed vblank nonsense.
<airlied> alyssa: nouveau might
<airlied> but not sure if it still has vbl irqs
<alyssa> 👀
<danvet> alyssa, if you do delay the vblank event until dcp sends you one then atomic helpers should hold up the next hw commit
<danvet> since uapi is that you can get EBUSY up to that vblank
<danvet> most hw is fairly unhappy with this
<danvet> s/vblank event/crtc_state->event completion/
<danvet> which exists everywhere, even without vblank
<alyssa> right, that's what I think I've done and which works for weston but not apparently X
<alyssa> although .. what I'm doing is still abusing the semantics of vblank a lot.
<alyssa> e.g.: if enable_vblank() is called and then nothing else happens (no atomic_flush), no vblank will come in
<alyssa> although err atomic_flush isn't what I really want is it now. ugh
<alyssa> the call ordering in tomic_helper_commit_tail doesn't match that. Uh
<alyssa> (commiting modeset enables *after* committing planes)
<alyssa> though commit_tail_rpm swaps that
<alyssa> oh just need a non-default commit function uh ok
<alyssa> right and i''m using the rpm version, so that's fine
ngcortes has quit [Ping timeout: 480 seconds]
<danvet> alyssa, I'm wondering whether it wouldn't be simpler to start out without announcing vblank support
<danvet> and only handing the crtc_state->event through your vblank machinery
<danvet> and maybe it might be easier to just not bother with hw vblank
<danvet> but fake it with hrtimer
<danvet> and then if the display is entirely idle, fire a vblank event once per second for clock drift
<alyssa> I mean, it's fake in either case ... my understanding is that I /needed/ vblank to get the EBUSY stuff
<danvet> assuming dcp didn't go into self-refresh :-)
<danvet> nah
<danvet> you need to handle crtc_state->event
<danvet> because that one is uapi (and the atomic helper keels over if you don't)
<danvet> but no vblank required
<alyssa> Hmm okay
<danvet> only thing required is that you get that out the door when convenient
<danvet> accurate timestamp optional (it'll just pick current time if there's none)
<alyssa> giving a try to handling state->event without adveristing vblanks
ngcortes has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<alyssa> oh and ... i'm also trying to swap 0 layers ... that can't possible work
<alyssa> sigh
ngcortes has quit [Ping timeout: 480 seconds]
<anholt_> oof. virgl really wants a base value on load_ubo.
<anholt_> (it requires that the ubo array's base index has to be in the TGSI register's index, not its indirect offset)
* alyssa can't tell if she's making positive or negative progress anymore
<alyssa> (git bisect 1, alyssa 0)
ppascher has joined #dri-devel
<alyssa> aggressive use of git bisect got me to Xorg again,w eee
<airlied> anholt_: isn't that how ubos work in TGSI anyways?
<airlied> the indirect offset shouldn't only be used for indirect UBO accesses
<airlied> which requires GL4.0 / ARB_gpu_shader5 on the host
<alyssa> modeset is still broken. come on, this was working recently ago! :p
<anholt_> airlied: well, by tgsi spec it seems like it ought to be just as happy with the base offset in the indrect vs in the index field of the register.
<anholt_> but virgl ends up trying to deref vsconst[indirect] instead of vsubo1[indirect] because the "1" was added to the user's indirect offset.
Company has quit [Read error: No route to host]
Company has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gpoo has quit [Ping timeout: 480 seconds]
<alyssa> ok modesetting working again. sort of.
<clever> ive been booting linux on an arm board, and i'm trying to add a framebuffer to it now
<alyssa> clever: i'm so sorry
<clever> ive added a `compatible = "simple-framebuffer";` to the DT, but as soon as i turn that on, the SD card stops working
<clever> alyssa: getting an image out on video is already working
<clever> the problem is getting linux to put an image at that addr in ram
<alyssa> zsimple-framebuffer is as simple as it gets
<alyssa> so if that doesn't work ... it's not the gfx stack's fault ...
<alyssa> most likely
<clever> what could i look into, to debug this more?
<alyssa> dunno -- but if a trivial gfx thing is breaking your SD card you have far bigger issues than gfx
quasselcore_ has quit [Read error: Connection reset by peer]
<clever> my DTB patching is also extremely flakey
<clever> alyssa: this should be disabling the simple-framebuffer, but it doesnt do anything
loki_val is now known as crabbedhaloablut
<marex> clever: doesnt upstream already contain all the RPi graphics hardware init stuff ?
<clever> marex: upstream is closed-source, ive replaced it with open source code
<clever> and now i have to re-implement nearly every feature
<marex> clever: I meant linux upstream
<clever> marex: there is an undocumented register, that essentially firewalls off the gfx hardware, and the arm core cant configure any of it
<clever> so the gfx init within linux just fails
<clever> i have already brought the gfx hw online with my own code, and it is running a full demo with shaders, in parallel to linux booting
<clever> one of the layers on the screen, is just whatever happens to be at +128mb into ram
<clever> reg = <0x8000000 40000>;
<clever> and simple-framebuffer then tells linux to use that
vivijim has quit [Ping timeout: 480 seconds]
<clever> oh
<clever> there is also a custom MMU, between the arm core, and the ram
<clever> i didnt map +128mb
<clever> so when the arm tries to write to +128mb, it gets re-routed to $undefined
<clever> and who knows what happens!!
gpoo has joined #dri-devel
<marex> clever: cant linux manage all that just like on other hardware with (io)mmu ?
<marex> it seems to me various GPUs also have their own MMUs and Linux handles that
<clever> marex: this MMU can only be written to by the VPU core, and is meant to do things at a magement engine level
<alyssa> clever: then... write it from the VPU...
<clever> alyssa: yep, already patched it to map the 128mb offset for the framebuffer
<alyssa> (in general I don't get the appeal of doing everything on the arm core. it's an uphill battle.)
<clever> in the case of gfx, not using the arm would add latency to pageflips
<clever> even with things all on the vpu, i'm seeing a stable tear about 20 pixels from the top of the screen
<clever> i see a flashing cursor!!!
<clever> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]---
<clever> it stopped flashing, lol
<clever> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
<alyssa> again... why can't use you mainline vc4?
<clever> alyssa: it fails with "async external abort" if it writes to even 1 control register
<alyssa> why?
<clever> undocumented firewall, that wont let the arm manage things
<clever> it has to be turned off by the firmware first, and i dont know how
<alyssa> so you're missing a power gate or a clock gate? sounds like one or two registers probably?
<alyssa> lot easier than reimplementing the entire gfx stack at any rate
<clever> definitely not power or clock gating
<clever> its rendering gfx right now
<clever> that looks like "on" to me
gouchi has joined #dri-devel
hansg has quit [Remote host closed the connection]
<clever> alyssa: just a bit triggered, because every RPF engineer ive asked for help, says clock/power gating, and then never answers again
<clever> and that above video, clearly shows its on
Duke`` has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
stuartsummers has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<alyssa> easily could be multiple independent gates
<alyssa> or dependent gates or...
<alyssa> I don't know the clock topology.
<alyssa> I'm also not an RPF engineer
<clever> alyssa: if i write to a register from the VPU, and then read it from the ARM, i can see the value
<clever> that implies that there are no gates blocking it
<clever> if i write from the VPU, then write the identical value from the ARM, it gets an async abort
<clever> that implies that only writes are blocked
<marex> clever: what is VPU btw ?
<marex> Video Processing Unit ?
<clever> marex: the VPU is a dual-core processor with scalar and vector opcodes
<clever> it lacks an MMU, but has a form of MPU (step out of lines, and you fault, but the addresses must be identity mapped)
<marex> so custom ISA ?
<marex> or some small ARM coprocessor ?
alyssa has left #dri-devel [#dri-devel]
<clever> its a variant of a synopsys DSP, which is ARC based
<clever> but it doesnt match any of the existing ARC toolchains
<clever> somebody modified the ISA heavily
<clever> gives you a binutils + gcc that can target it
<marex> oh
<marex> clever: the async abort could be multiple things, ranging from what alyssa said, IP is gated off (clock, reset, etc), but also things like wrong write width
<marex> i.e. the write might need to be 8/16/32bit and no other
<clever> marex: always doing 32bit writes
<marex> or yes, it is blocked because secure/non-secure setting of the ARM core
<clever> 8bit reads malfunction in all kinds of fun ways
<clever> when running under the closed firmware, you can just mmap /dev/mem, and poke the HVS control registers, directly from userland
<clever> that implies zero security is being enforced, in that state
<clever> there is undocumented hardware, that allows you to block ALL MMIO from userland, reads just return null
<clever> but i have found that and disabled it
<clever> and i believe i tested HVS writes from arm secure mode, and they failed
<clever> something is selectively blocking HVS writes, but allowing SD/uart/i2c writes
<marex> well if it is disabled, why do you get aborts ? :)
<clever> there appears to be at least 2 different security features
<clever> 1 to stop userland from doing mmio, even if it gets mapped somehow
<clever> a 2nd to stop even kernel mode from touching certain dangerous hardware
<marex> clever: well ... what happens if you try the access from e.g. u-boot ?
<clever> i'm using a custom bootloader, and it fails even from the first few opcodes ran on the arm
<clever> but when using the closed firmware, it doesnt fail
<marex> that should run in secure mode (on rpi2 and 3 anyway)
<marex> clever: the closed firmware is running on ARM or on the companion core ?
<clever> the closed firmware runs on the VPU
<marex> can you e.g. run the closed firmware in QEMU and have it poke registers via JTAG , thus find out what it writes and reads and when etc ?
<clever> nope
<clever> qemu doesnt support the VPU ISA (yet, its on my todo list)
<clever> the jtag for the VPU is also not publicly documented
<marex> qemu does support arc :)
<clever> but somebody at broadcom heavily modified this arc variant
<clever> it disagrees with the arc isa in a number of ways
<clever> when booting normally, the closed firmware will drop a compiled copy of armstub7.S at arm physical 0 (the reset vector)
<clever> it will then patch lines 194/195, with the addresses for the linux kernel and dtb files
<clever> armstub7.S is responsible for setting things like CNTFRQ, and dropping out of secure mode, then running linux
<clever> if your using uboot or tianocore, then youve replaced armstub7.S with that
<clever> linux expects CNTFRQ to contain the freq of the arm timer, but the register defaults to 0, and linux trusts it way too much, leading to a divide by zero!
<clever> thats one of the many things ive discovered have to be configured
<marex> ACK
<clever> the FPU must also be enabled (armstub7.S has examples) and not flagged for trapping
<clever> if you fail to do so, linux just assumes you dont have an FPU
<clever> and the instant userland touches the FPU, you get SIGILL
<clever> my latest iteration on the bootloader uses lazy context switching on the FPU, so it had been configured to trap all access
<clever> took a few days to figure out
NiksDev has quit [Ping timeout: 480 seconds]
<clever> marex: i think i see the cause of the latest failure, color_imageblit() is rendering the penguin logo to the framebuffer, i dont think it checks if it fits...
<clever> so if the framebuffer is too small, it will overflow, and fault
<clever> CONFIG_LOGO=n, ok, there goes that theory...
<clever> why is it even running this then?
<clever> ah
<clever> this appears to be the font rendering, for the console
i-garrison has quit []
ngcortes has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
co1umbarius has joined #dri-devel
tursulin has quit [Remote host closed the connection]
Hi-Angel has quit [Ping timeout: 480 seconds]
iive has quit []
thellstrom has joined #dri-devel
thellstrom1 has quit [Read error: Connection reset by peer]
hanetzer has joined #dri-devel
pcercuei has quit [Quit: dodo]
<hanetzer> I need to find a bar.