<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]
<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>
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>
(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?
<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.
<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
<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 docs.cl
<imirkin_>
oh. it's already registered. but not nearly as useful as docs.gl
<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
<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]
<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]