* airlied
goes to pull meson from f36 just in case
<airlied>
nope still faily
slattann has joined #dri-devel
<airlied>
f36 machine has some emmintrin.h fails, and nir_opcodes.h not found
macromorgan_ has joined #dri-devel
MrCooper_ has joined #dri-devel
flto_ has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
macromorgan has quit [Read error: Connection reset by peer]
jewins has quit [Remote host closed the connection]
nchery has quit [Read error: Connection reset by peer]
mmenzyns has quit []
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
nikitalita48 has quit []
abhinav__ has quit [Quit: Ping timeout (120 seconds)]
abhinav__ has joined #dri-devel
ceyusa has quit [Remote host closed the connection]
nikitalita48 has joined #dri-devel
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<airlied>
okay setting rust_std, and hacked around the include files
jewins has joined #dri-devel
ceyusa has joined #dri-devel
jhli has quit [Remote host closed the connection]
LexSfX has quit [Remote host closed the connection]
jhli has joined #dri-devel
gpiccoli has joined #dri-devel
melissawen has joined #dri-devel
aswar002 has quit [Quit: No Ping reply in 180 seconds.]
LexSfX has joined #dri-devel
mmenzyns has joined #dri-devel
aswar002 has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
sumits has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
tlwoerner has joined #dri-devel
<airlied>
karolherbst: so luxmark 3.1 dies for me in nir_lower_var_copies with an assert
Duke`` has joined #dri-devel
sumits has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: the offending shader is one of the huge ones, maybe try building with asserts to see if you hit it
Danct12 has joined #dri-devel
jewins1 has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
nchery has quit [Remote host closed the connection]
dj-death has quit [Ping timeout: 480 seconds]
abws has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Daanct12 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
dj-death has joined #dri-devel
ahajda_ has joined #dri-devel
mvlad has joined #dri-devel
itoral has quit [Remote host closed the connection]
nchery has joined #dri-devel
itoral has joined #dri-devel
danvet has joined #dri-devel
jkrzyszt has joined #dri-devel
tzimmermann has joined #dri-devel
slattann has quit []
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
tursulin has joined #dri-devel
<javierm>
tzimmermann: sorry, yesterday got dragged by something else and forgot your review request. I've done it now
ahajda__ has joined #dri-devel
<tzimmermann>
thank you
MajorBiscuit has joined #dri-devel
<tzimmermann>
javierm, 5/5 ?
<javierm>
tzimmermann: yes, I'm on it right now :)
ahajda_ has quit [Ping timeout: 480 seconds]
famfo_znc has quit []
<javierm>
tzimmermann: btw, I tried to trim down the patch-set that fix the race conditions between sysfb and fbdev/DRM but instead I had to make it bigger /o\
<tzimmermann>
what happend?
<javierm>
tzimmermann: that it doesn't really cover all the cases to only make it a disable. You also need to remove any device that was registered
<javierm>
and also, danvet suggestion to make sysfb unregister the device is also correct, because otherwise fbmem could unregister the device without sysfb being aware
<javierm>
tzimmermann: and then I also moved the sysfb disable to register_framebuffer() and drm_dev_register() as you suggested, but that also means that we need a new DRIVER_FIRMWARE capability
<tzimmermann>
i'm ok with that flag
<javierm>
because otherwise the drm_dev_register() for simpledrm could attempt to disable sysfb (and unregister it's own platform device)
<javierm>
tzimmermann: yes, that makes a lot of sense and also allows to mark the emulated fbdev with FBINFO_MISC_FIRMWARE as you suggested
<javierm>
tzimmermann: I think that will split the first 3 patches in a separate series for the new DRM capability flag and marking the fbdev as FBINFO_MISC_FIRMWARE
<javierm>
those should be less controversial than the others
<tzimmermann>
i still don't understand why sysfb needs to know when a device gets unregistered?
<javierm>
tzimmermann: think about this scenario: 1) sysfb registers a "simple-framebuffer" 2) a real DRM driver gets probed and gets over the firmware provided fb
<tzimmermann>
ok
<javierm>
tzimmermann: 3) but simplefb or simpledrm are built as a module, and someone loads it
<danvet>
what do we need that DRIVER_FW flag for?
* danvet
probably a bit out of the loop
famfo has joined #dri-devel
<javierm>
tzimmermann: the problem is nothing unregistered "simple-framebuffer" device, only devices for registered fb are unregistered
<tzimmermann>
javierm, what would happen if someone loads the simpledrm module?
<javierm>
tzimmermann: the module will match against the "simple-framebuffer" and register a new dri / fbdev devnodes
<javierm>
which is wrong
<tzimmermann>
javierm, now i get it. the simpledrm module was not loaded in the first place
<javierm>
tzimmermann: no, because wasn't built-in but as a module
<javierm>
but the real DRM driver is built-in
<javierm>
tzimmermann: so sysfb needs to unregister any registered device on disable, but that will create a NULL pointer deref if fbdev did it already
<javierm>
so it has to handle the unregistration itself
<javierm>
danvet: as usual, it depends :)
<javierm>
danvet: but I believe we do, if anything to register simpledrm emulated fbdev as FBINFO_MISC_FIRMWARE
<danvet>
javierm, I think I don't have the full patch set (nor lore)
<danvet>
but at least one comment in there sounded very dangerous, so I replied
<javierm>
danvet: no, I haven't posted it yet
<danvet>
we have to throw out fw drivers before the driver loads or machines can die
<danvet>
two drivers fighting over the same thing is no good
<danvet>
and at least in the case of i915, we had plenty of bug reports that they indeed do die
<tzimmermann>
javierm, that's a major rework
<javierm>
tzimmermann: it is indeed... but I didn't find a way to make it simpler
<tzimmermann>
javierm, before we commit to something i'd like to discuss various approaches on the list
<javierm>
danvet: you are correct. And that's exactly what we had been discussing
<javierm>
tzimmermann: sure, there's no rush with this
<javierm>
tzimmermann: that's why I think that splitting the first 3 patches makes sense, those should be more straightforward
<javierm>
and have merits on their own
<javierm>
regardless of the races
famfo has quit []
<javierm>
tzimmermann: another option is to post the full series as RFC. Let me know what you prefer
<tzimmermann>
javierm, instead of hacking up sysfb, did you consider to move drm aperture helpers into a more prominent location? drm and fbdev could be built on top o fit. you wanted to do this anyway. when sysfb creates a platform device, it could acquire the aperture immediately. any native drm driver would then hot-unplug the platofrm device even if no simepldrm/fbdev driver has been loaded yet. loading the simpledrm
<tzimmermann>
module afterwards would do nothing
nvishwa1 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I believe that's the correct way to do it, yes. I discussed this with danvet a little bit and he said (IIRC) that this should be something handled by the device model
<javierm>
but that would be an even bigger rework, certainly not something I've the time to do it
<tzimmermann>
javierm, indeed. aperture helpers would become part of the overall device code
thellstrom1 has quit [Read error: Connection reset by peer]
<javierm>
not to mention that the DRM drivers don't request their memory region so that would have to change as well if we do it in the device model
famfo has joined #dri-devel
famfo has quit []
<tzimmermann>
javierm, but drm drivers remove apertures already
<javierm>
tzimmermann: they do, yes. I meant if we move to the device model and just use the I/O mem region instead of the apertures
<tzimmermann>
javierm, yes maybe post an RFC and lets discuss on dri-devel
<javierm>
tzimmermann: what I tried to say is that the whole aperture thing is just a workaround for the lack of drivers requesting their memory regions explicitly and the device core allowing to unregister conflicting devs
<danvet>
tzimmermann, my reason for why this should be in sysfb is that sysfb should be responsible for unregistering the platform device when it's no longer valid
thellstrom has joined #dri-devel
<danvet>
and not fbdev or anything above it doing that
famfo has joined #dri-devel
<javierm>
danvet: yes, agreed. It's a layering violation that fbdev does it under sysfb feet
<javierm>
tzimmermann, danvet: so my plan is the following 1) pile more hacks in sysfb, fbdev and DRM as a "temporary solution" 2) try to come up with a unified aperture list for DRM and fbdev and remove all the hacks
<javierm>
3) move this logic to the device core and remove the aperture infrastructure
<javierm>
I'll post a RFC for (1)
<danvet>
javierm, I'm not sure the aperture stuff works
<danvet>
it works for like discrete devices
<danvet>
and pci igfx, where the fb is generally in some fake-ish pci bar
<danvet>
but on arm-soc I think this just fails
<tzimmermann>
danvet, on arm-soc, we remove *all* firmware drivers at once
<danvet>
so I wouldn't worry too much about making that side of the coin look perfect
<linkmauve>
“23:42:42 jenatali> Oh no... a real world app using glProgramStringARB...”, 0ad does that, but it also has a “newer” GLSL backend.
<linkmauve>
Still, some people recommend to use the ARB version…
<tzimmermann>
javierm, maybe rather move apertures into sysfb and rebuild drm/fbdev ontop of it. going full-device-model can be an afterthought
frieder has joined #dri-devel
<javierm>
tzimmermann: yes, that's why I mentioned (1), (2) and (3). What you mention could be (2)
<tzimmermann>
javierm, is this an immediate problem you have to solve?
lynxeye has joined #dri-devel
<javierm>
tzimmermann: you mean just skipping (1) and let the race exists in the meantime ?
<tzimmermann>
javierm, yes. if there's no hurry, i'd skip (1)
<tzimmermann>
it seems that the problem is rarely encountered in practice
<javierm>
tzimmermann: it is, but does happen since we got reports and had to add hacks to efifb and simplefb due that
<javierm>
tzimmermann: yeah, but it's blocking the last bits of danvet fbdev cleanups
rasterman has joined #dri-devel
<javierm>
tzimmermann, danvet: anyway, let me post as RFC and we can discuss in the list. I believe some patches have merits on their own even if we decide to skip (1)
<tzimmermann>
sounds good
<javierm>
tzimmermann: btw, you wanted me to wait for Lyude to review the link error fix. She already did so is OK for you to land that now ?
<tzimmermann>
javierm, sure
<javierm>
tzimmermann: cool, thanks
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: Leaving]
famfo has quit []
famfo has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
famfo has quit []
famfo has joined #dri-devel
apinheiro has joined #dri-devel
mnadrian has joined #dri-devel
<javierm>
tzimmermann, danvet: let me know what you think :)
<javierm>
but I honestly believe this is at least an improvement
nadrian_ has joined #dri-devel
nadrian has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<javierm>
in an ideal world a driver could do request_mem_region_force() or something like that and let the device model unregister any device for drivers that request_mem_region() previously for the same range
mnadrian has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
thellstrom has joined #dri-devel
<tzimmermann>
javierm, sometimes (arm-soc) we don't easily know where a device's firmware framebuffer resides. so we remove all of them. IOW even with the device model, there will be corner cases
FireBurn has quit [Remote host closed the connection]
FireBurnUK has joined #dri-devel
<tzimmermann>
going full-device-model, would mean that each device needs a device class (i.e., graphics, audio). we could remove all registered graphics devices, but would leave out potential other devices
frieder has quit [Remote host closed the connection]
<javierm>
tzimmermann: but that's already the case right? We use the struct device_type currently for example to only attempt to match drivers for the same device type when a new device is registered
<javierm>
and vice versa
<javierm>
tzimmermann: and for arm-soc I thought that the information about the firmware framebuffer was in a DT node
<javierm>
and that OF would take that info and create a platform device with this information as pdata I/O mem resource
<javierm>
tzimmermann: hmm, the type is per bus indeed and not per class...
<tzimmermann>
javierm, i've never seen something setting up the device type
<javierm>
ah no, there's bus_type that's used for matching and also device_type
<tzimmermann>
is this used consistently
<tzimmermann>
for arm-soc, we don't know the location from within the native driver
<tzimmermann>
so we remove all firmware drivers
<javierm>
tzimmermann: I see...
<javierm>
then my ideal world just doesn't exist :)
<tzimmermann>
:)
<karolherbst>
airlied: huh.. I thought I was building with asserts
jewins1 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<karolherbst>
airlied: for the include files you need a newer meson
<karolherbst>
running 0.62.0 here
<karolherbst>
pip install --user meson or something.. dunno the correct syntax
<karolherbst>
yeah.. b_ndebug is false
<karolherbst>
ohh
<karolherbst>
that assert is new
<karolherbst>
or I changed something?
<karolherbst>
weird..
<karolherbst>
yeah.. I think I broke something when cleaning up :D
MajorBiscuit has quit [Quit: WeeChat 3.4]
rkanwal has joined #dri-devel
famfo_znc has joined #dri-devel
famfo has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
<karolherbst>
airlied: fixed
<karolherbst>
so now you should see the messed up stuff :)
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
ppascher has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
flacks has quit [Quit: Quitter]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
flacks has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Wally has joined #dri-devel
famfo_znc has quit []
famfo has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Wally has quit []
itoral has quit [Remote host closed the connection]
<javierm>
tzimmermann: why every patch I post is a rabbit hole :)
<tzimmermann>
javierm, haha lol
Company has joined #dri-devel
<tzimmermann>
javierm, it's really not your fault.
<javierm>
tzimmermann: but you convinced me that using a flags argument in drm_fbdev_generic_setup() is the way to go
<tzimmermann>
you just picked some of the worst stuff to work on
<tzimmermann>
ah, ok
<javierm>
tzimmermann: just pondering if we should first do the refactor to not need preferred_bpp or just add a third param for now and do the former as a follow-up
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<tzimmermann>
javierm, simply set the flag as some high bit
<tzimmermann>
BIT(16) and upwards should be save
<javierm>
tzimmermann: yeah, but feels like a hack...
<tzimmermann>
because it is :)
<javierm>
:D
<javierm>
tzimmermann: I may leave this for now. Thought these 3 first patches wouldn't be controversial but alas I was wrong again
<tzimmermann>
but do you really want to go through all the drivers and fix preferred_depth? that might have other consequences
<javierm>
tzimmermann: yeah, that's why I thought about just adding a third flags parameter
<javierm>
that shouldn't have other consequences although would be a lot of churn
<javierm>
but we could make it as a single big patch...
<tzimmermann>
you could do: 'define DRM_FB_FLAG_FIRMWARE BIT(16)'
<tzimmermann>
and 'define DRM_FB_FLAG_PREFERRED_BPP(bpp) (bpp)'
<tzimmermann>
in the few affected drivers you'd enclose the bpp with the macro
<tzimmermann>
and rename the arguemnt from preferred_bpp to 'flags'
<tzimmermann>
that is the sane long-term interface and it still supports preferred_bpp
<javierm>
tzimmermann: yeah, then it will bpp abusing the flags arguments but I feel better about it :)
<javierm>
tzimmermann: Ok, let's do that as a intermediate step and then hopefully at some point we should be able to drop DRM_FB_FLAG_PREFERRED_BPP()
<javierm>
tzimmermann: can I do it as a mega patch changing all affected drivers ?
<javierm>
I usually try to split as much as possible but your comment about squashing 1-3 made me think if DRM expects a different convention
<tzimmermann>
it could happen that we need other flags as well. currently we have 'prefer_shadow_fbdev' really only for bochs. i'd like to see this as flag as well
<javierm>
tzimmermann: yes, that's for sure. Is just that flags is used to express an enable/disabled rather than a value like bpp would do
<javierm>
but meh, we can clean it up later
<tzimmermann>
i'd do a tree-wide patch that replaces preferred_bpp with 'flags'. and a second patch that adds the FIRMWARE falg
<javierm>
tzimmermann: Ok
<javierm>
tzimmermann: soon enough I'll forget what the original patch I posted when got deviated was about :P
<tzimmermann>
javierm, is there a beter name than 'flags' in this case?
<tzimmermann>
yeah, was was the original problem? something with modules ? :D
<javierm>
tzimmermann: LOL
<javierm>
tzimmermann: so I think that flags is Ok, if the plan is to not pass bpp using it in the future
<javierm>
it's hard to come up with a name that's encoding both flags and values in the same param
<javierm>
tzimmermann: maybe use a config union that has flags and bpp ?
<javierm>
emersion: indeed. I'll go with that, thanks!
Major_Biscuit has quit [Ping timeout: 480 seconds]
<tzimmermann>
danvet, regarding yesterday's discussion about ast's cursor locking bug: i've been able to reproduce the problem and found that modesetting races with mode detection (i2c-based edid reads)
<tzimmermann>
is there an existing lock that i can acquire in ast's i2c code that protects against this problem?
flto_ has quit []
flto has joined #dri-devel
Major_Biscuit has joined #dri-devel
<tzimmermann>
there's mode_config.mutex
maxzor has quit [Ping timeout: 480 seconds]
famfo_znc has joined #dri-devel
famfo has quit [Ping timeout: 480 seconds]
FireBurnUK has quit [Quit: Konversation terminated!]
iive has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
<javierm>
tzimmermann: we still would need the DRIVER_FIRMWARE capability flag though for dev_drm_register() to know that shouldn't attempt to disable sysfb (and hence remove the registered pdev) for simpledrm
<javierm>
tzimmermann: unless I move back the disable to remove_conflicting_framebuffers() as I had in v3, since that's only called for real drivers but I agree with you that makes more sense to do in DRM device registration
<javierm>
tzimmermann: what do you think ?
<javierm>
tzimmermann: I'm leaning towards do it at remove conflicting framebuffers time to completely avoid the need of a new DRM cap
apinheiro has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
<tzimmermann>
javierm, maybe let's discuss this on monday
<javierm>
tzimmermann: sure
GeorgesStavracasfeaneron[m] is now known as feaneron
<marex>
jeeeeeeez, tc358767 DP mode is borked
<marex>
lynxeye: &
<marex>
^
<marex>
when the DSI lines are pulled to LP11 (the default if the DSI controller is not yet initialized) and you try AUX channel access, the chip instead recognizes that LP11 as "enter test mode" and runs AUX channel at 1/8 frequency, which monitors reject
<marex>
specifically, D0 data line must be below 1V, else the chip goes bonkers
<marex>
there doesn't seem to be any way to dislodge the chip from this insane mode, grumb
famfo_znc has quit [Ping timeout: 480 seconds]
<marex>
of course, datasheet does not mention this gem
tzimmermann has quit [Quit: Leaving]
<lynxeye>
marex: urgh, that's bad.
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<lynxeye>
marex: Seems we are mostly working on the same things. I also have it on my list to look at DSI->DP mode with this chip in the very near future.
<marex>
lynxeye: dont bother, I have DSI-to-DP working on my desk and will submit patches once I sort this brain necrosis
<marex>
lynxeye: all I do right now is pull the lines low with a resistor for a bit, manually ...
<lynxeye>
marex: At least it gives me an chance to help with testing and review.
<marex>
that
<marex>
it is rather simple to get the DSI-to-DP working now that we have DSI-to-RGB
<marex>
you do need Xtal/REFCLK, the link inferred clock are ... insane
<melissawen>
pepp, just tested it and the issue is fixed, thanks a lot!
<pepp>
melissawen: great, thanks for the quick feedback
<melissawen>
pepp, np :)
<ajax>
jekstrand: before i go down this route, any opinion about making wsi just always use a thread? i suspect wayland is going to end up wanting one, and that the x11 code would be easier to follow as well
<emersion>
wayland wsi can't send wl_surface.commit from a thread
<ajax>
why not
<emersion>
because various other app state is synced to wl_surface.commit
<emersion>
so there needs to be a guarantee that swapping buffers sends wl_surface.commit
<jekstrand>
^^
<jekstrand>
It's annoying
<jekstrand>
EGL design biting us pretty bad, I'm afraid.
<emersion>
otherwise the app might queue up other wayland requests and these might get included in the commit "by mistake"
<emersion>
and various other fun stuff
<ajax>
that's... unsatisfying
<jekstrand>
Very
yogesh_mohan has quit [Ping timeout: 480 seconds]
<ajax>
don't make me need to recommend x11 for vulkan
<ajax>
i guess i don't understand what other state there is that isn't properly vulkan's
<ajax>
unless like input clips are bound to surface state?
Duke`` has joined #dri-devel
<emersion>
there is a ton of other state
<emersion>
nearly all surface-related requests are gated by wl_surface.commit
<emersion>
so that there are no intermediary bad state
<emersion>
is*
<ajax>
seems a little like a protocol failing if you can't just latch a new image, imo
<ajax>
probably i'm not telling you anything you don't know
<daniels>
that this situation sucks isn't news
<daniels>
what problem are you trying to solve by spawning background threads?
<ajax>
mostly trying to come up with a consistent approach. i sincerely dislike x11's fifo queue thread, but i'm not convinced i can delete it. so if i can't i'd just as soon always use one for x11 to make the code easier to grok.
<ajax>
and if that's true, does it then make sense to extend to the other wsi backends
<jadahl>
the only way things can't "suck" is if we only ever push fullscreen single surface content without anything more complex
<emersion>
"just latch a new image" isn't what the vulkan client is trying to do
<emersion>
the vulkan client is trying not to show completely broken output
<emersion>
synchronization is necessary here
<jadahl>
maybe vulkan is only suitable for embedded devices without display servers? :P
<emersion>
completely broken output may be de-synchronized resizing, de-synchronized video playback over the rest of the surface, double window decorations, etc etc
Sumera[m] is now known as Sumera
<daniels>
jadahl: that or if you implemented a timing protocol which would let QueuePresent return quickly without needing a thread to sleep
<jadahl>
g_timeout() via wayland? O_o
gouchi has joined #dri-devel
<daniels>
jadahl: not g_timeout, but being able to specify a frame time to latch on to
<daniels>
like, the next half of presentation-time that never got landed first because MM stuff wasn't ready to meaningfully use it, as well as the subsequent revision which died because the motivating Vulkan extension also died
<emersion>
what would it take to have a proper timing ext
<jadahl>
daniels: ah, so the ever talked about presentation-next
<daniels>
emersion: a lot of the corner cases from the first round (gory details way back in list archives) were around 'but what if you need to cancel for resize?'. I'm still on the fence as to whether it's better to say that you'll just have to wait for the queue to drain, or that you can include an explicit discard. I don't think the latter is the most useful though given that it's always going to incur some amount of jank
<daniels>
(vs. the latency from enforcing drain)
<emersion>
hm
* marex
bangs head into desk
<emersion>
it could always be added later if it turns out we need it
<marex>
lynxeye: so turns out, stm32 DW DSI host doesn't start in LP11 and rather leaves the D0 data lane low ... and the TC358767 goes nuts because of that (which, is counter to what the special PDF tells me)
nchery has quit [Ping timeout: 480 seconds]
* marex
bangs head into desk harder
kts has joined #dri-devel
nchery has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Major_Biscuit has quit []
lemonzest has quit [Quit: WeeChat 3.4]
jewins has quit [Quit: jewins]
<airlied>
karolherbst: btw if you use a compute only context, blit is off the table usually
<karolherbst>
airlied: ohhhh.. good point
<karolherbst>
airlied: but does it affect any other driver besides radeonsi?
kts has quit [Quit: Konversation terminated!]
alanc has quit [Remote host closed the connection]
<airlied>
karolherbst: probably not, and I think radeonsi might have compute shader blit support coming
<karolherbst>
ahh
alanc has joined #dri-devel
<karolherbst>
I currently see that lots of drivers disable u_threaded_context if they see that flag though
<nchery>
dcbaker: ping
cheako has quit [Quit: Connection closed for inactivity]
<airlied>
karolherbst: okay crashes now in the driver, will debug more next week
aswar002 has quit [Ping timeout: 480 seconds]
<karolherbst>
I think I should use PIPE_FLUSH_DEFERRED
<karolherbst>
maybe that and PIPE_FLUSH_ASYNC together even
<karolherbst>
there are so many goodies I ignored for now :)
ngcortes has joined #dri-devel
<dcbaker>
nchery: pong
cheako has joined #dri-devel
mvlad has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]