ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Duggan has quit []
gawin has quit [Ping timeout: 480 seconds]
Duggan has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
<DavidHeidelberg[m]>
gawin: happy that my MR is visible. We intent to use mostly Android (any) -> Vulkan.
<DavidHeidelberg[m]>
Anyway, maybe we'll have nine-tests soon (I still havent got to patching my intel with potentional crash fix)
<DavidHeidelberg[m]>
gawin: what do you think, I just browsed my commits and... 2014, Direct3D9 merged... should I ask in 2022 wine folks if they would be fine to get it in?
<DavidHeidelberg[m]>
it doesn't make much sense for old hardware, because it's failing and low ratio performance/power consumption, but for these days low power devices (RPi4, phones, tablets) it still kinda gives some sense to me
Duggan has quit []
sdutt__ has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
Duggan has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
<illwieckz>
as you'll see commits are even just named “wip”, “fixup”, far from being mergeable 🙂️
<kode54>
indeed
<kode54>
also strongly considering getting an A750 or A770 in the future
vliaskov has joined #dri-devel
jkrzyszt_ has joined #dri-devel
tursulin has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
swalker_ has joined #dri-devel
swalker_ is now known as Guest2731
swalker__ has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Guest2731 has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
fab has joined #dri-devel
lynxeye has joined #dri-devel
andyrichle[m] has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2022-10-10 08:24:01)]
kts has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
chipxxx has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
chip_x has joined #dri-devel
jljusten has quit [Quit: WeeChat 3.6]
kts has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jljusten has joined #dri-devel
jljusten has quit [Read error: Connection reset by peer]
jljusten has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts_ has quit []
gawin has joined #dri-devel
kts has joined #dri-devel
JohnnyonFlame has joined #dri-devel
enilflah has quit [Ping timeout: 480 seconds]
italove9 has quit []
italove has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
JohnnyonFlame has joined #dri-devel
fab has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
zehortigoza has joined #dri-devel
bmodem1 has joined #dri-devel
underpantsgnome[m] has quit []
devilhorns has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
devilhorns has quit []
Leopold has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #dri-devel
chip_x has quit [Read error: No route to host]
<agd5f>
jani, exact same source. The internal state just never gets set to anything other than disabled, so IIRC, we only ever turn it off
technopoirot has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<emersion>
danvet: do you know if it's beneficial for user-space to implement a complicated CRTC->connector allocation algorithm, or is a first-come first-served good enough?
<emersion>
wlroots has the complicated version and i'm wondering if i can yank it
<emersion>
cc vsyrjala ^
bgs has joined #dri-devel
fahien has joined #dri-devel
<gawin>
zuwik9708
kts has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<gawin>
shit, can someone remove last msg from log. stupid evdev
<emersion>
that's not possible
<emersion>
even if it was, that wouldn't be enough
<gawin>
I know I mean web page of bot
<emersion>
if this was a password, the only way is to rotate it
gawin_ has joined #dri-devel
<ishitatsuyuki>
rip to your lifetime password
gawin has quit [Ping timeout: 480 seconds]
gawin_ has quit []
gawin has joined #dri-devel
<gawin>
used just in vm, but still annoying. (mouse was still in VM)
<vsyrjala>
the one thing that screws that over now is bigjoiner. as in we sometimes need to use >1 pipes internally to drive big displays
<emersion>
vsyrjala: specifically, something that the naive solution would not handle:
<emersion>
CRTC 1 is compatible with DP-1 and DP-2
<emersion>
CRTC 2 is compatible with DP-1 only
<emersion>
user enables CRTC 1 with DP-1 (first come first served)
<emersion>
user wants to enable DP-2 but no compatible CRTC is found
<emersion>
does this sound like something which could happen?
<vsyrjala>
old i915 hw definitely had restrictions where you needed a specific pipe for some outputs. new hw not so much
<vsyrjala>
except for the bigjoiner cae, which is even more annoying since you can't even see it from any mask. just have to TEST_ONLY your way to a solution basically
<emersion>
hm, we definitely don't do that, and i don't think anyone else does
<emersion>
would be nice to fully virtualize the CRTCs exposed to user-space, so that the kernel can do the right thing
<danvet>
emersion, minimally you should pick a connector that is possible per the routing info
<danvet>
otherwise a bit too dense
<emersion>
danvet: dense?
<emersion>
yeah, i mean everybody uses possible_crtcs
<danvet>
well if connectorA only works with crtc1 and you try to light it up with crtc0
<vsyrjala>
the problem with full virtialization is that not all crtcs are created equal. so either we'd have to overadvertise or underadvertise the capabilities
<emersion>
danvet: does the description below "something that the naive solution would not handle" help understanding what i mean?
<emersion>
vsyrjala: other advertise, then fail atomic commits which can't make it
<emersion>
over*
<vsyrjala>
which kinda ends us where we started
<emersion>
no, because the kernel is better equipped to decide which CRTC to use for e.g. bigjoiner
<emersion>
IOW, the implementation is in the kernel instead of having all user-space mess it up
<danvet>
emersion, I think that case can happen
<emersion>
danvet, cool, thanks. i'll keep the complciated approach then
<danvet>
e.g. old i915 panel, where the integrated panel only worked with a specific pipe
<danvet>
but other outputs could use either
<danvet>
iirc
<danvet>
emersion, what I think is not needed it full combinatorial with ATOMIC_CHECK
<danvet>
since those cases drivers virtualize internally thus far and try to pick the best
<emersion>
we do full combinatorial without ATOMIC_CHECK
<vsyrjala>
emersion: well, someone will mess it up anyway. dunno if there's much point in making the kernel do it ;)
<emersion>
ok, very nice
<emersion>
vsyrjala: no, the kernel cannot mess up, because the kernel has more info
<danvet>
in the end I expect this will be a forever tradeoff with kernel providing more info to userspace
<danvet>
vs kernel virtualizing stuff harder
<emersion>
vsyrjala: by "mess up" i mean user-space implementing the naive approach
<vsyrjala>
it may not have all the info _at the time_
<emersion>
what do you mean?
<emersion>
it has the whole new atomic state to work with
<vsyrjala>
eg. if you decide a few frames later that a 3dlut is needed, but don't want a modeset to get one
<emersion>
ah, yes, that's for sure, it's not a "all cases work always" solution, but at least it'd improve things a bit
<emersion>
i'd be surprised if anybody but wlroots implements the complicated approach
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
<vsyrjala>
i just use xorg. at least i can manually tell it what to use :P
<emersion>
"manual configuration" is really not great
<tleydxdy>
would the heuristic of pick the least capable one first work?
<emersion>
it's fine for vsyrjala but about everyone else wouldn't do it
<daniels>
yeah, CRTC object IDs as a mandatory configuration axis is a non-starter
<emersion>
if you don't want it in the kernel, maybe in libdrm would be a good start
<danvet>
daniels, I'm not clear what you mean ...
<daniels>
danvet: 'making users write "HDMI-A-1 = CRTC-47" in a config file just to make their displays work is an unacceptably bad UX'
<tleydxdy>
I have a similar problem with docked displays, when there's just one of them it can do the preferred mode, but when there's two either both have to drop to some lower mode or one have to be the beta, and which is the beta depends on the order they're detected
<emersion>
you should be able to force the first one to a lower mode, to let the second one pick the preferred
<emersion>
no way the compositor can guess which one you want the preferred mode on
<tleydxdy>
exactly
<tleydxdy>
so how should compositor deal with it
<emersion>
just provide a way to configure which output mode to use…
<emersion>
like everybody does right now
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<tleydxdy>
isn't that the manual configuration route?
<daniels>
that is the manual configuration route, but requiring users to specify a resolution is in fact ok
<daniels>
'4K or 1080p' is a meaningful choice to present to someone, when your best-effort attempts have failed
<daniels>
'CRTC 42, 43, or 44?' is not
<emersion>
^
<emersion>
in the CRTC case, the compositor can find a better solution without further input from the user
sigmaris has quit [Ping timeout: 480 seconds]
<daniels>
emersion: I am surprised though to hear that wlroots hates user freedom and won't allow them to configure CRTC routing :P
<emersion>
it won't even allow compositors to configure that through an API!
<emersion>
truly a walled garden project
<daniels>
:-o
tursulin has quit [Ping timeout: 480 seconds]
<tleydxdy>
tbh if I'm writing a compositor I'd expect some lower level library to handle these stuff automatically, maybe libdrm maybe kernel
<daniels>
tleydxdy: that low-level library is libweston/wlroots
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
<daniels>
the kernel isn't the place to do complicated policy gymnastics, because ... it just isn't
<tleydxdy>
but configuring crtc is not a wayland only thing right?
<emersion>
though, that exact part could be libdrm
<daniels>
libdrm isn't an appropriate place to do those gymnastics either, because it very directly presents the KMS API and not any high-level concepts
<zamundaaa[m]>
<emersion> "hm, we definitely don't do that,..." <- KWin does do a complete combination search with `TEST_ONLY`, because we had users where nothing else worked
<emersion>
we already have drmModeConnectorGetPossibleCrtcs
<emersion>
zamundaaa[m]: ah, interesting
rkanwal has joined #dri-devel
<daniels>
emersion: sure, but we don't have drmModeAtomicDoRoutingPlease
<emersion>
zamundaaa[m]: which driver?
<zamundaaa[m]>
it was old Intel hardware iirc
<emersion>
daniels: could have drmModeFindCrtcRouting
<emersion>
zamundaaa[m]: so it didn't work without TEST_ONLY at each step?
<daniels>
emersion: you could indeed, but then an atomic property list isn't the greatest interface to be working with tbh, and that's currently the only thing we have to deal with 'complex' configuration
<zamundaaa[m]>
emersion: "at each step"?
<daniels>
so you'd need to invent some kind of higher-level representation of KMS config intent, and at that point is it better in libdrm than libliftoff?
<emersion>
zamundaaa[m]: try each CRTC with each compatible connector and do a TEST_ONLY each time?
<tleydxdy>
yeah sounds like libdrm is in the right position for this stuff, all the possible users that need it are already using it probably
<emersion>
daniels: we could just have a CRTC array and a connector array, and fill the best routing
<zamundaaa[m]>
Yes. It iterates through all possible combinations and does a TEST_ONLY every time
<daniels>
I definitely think libliftoff is a better starting place for 'I want something vaguely like this to work well please' than libdrm
<emersion>
hm, maybe
<emersion>
it's not an especially opinionated algorithm
<zamundaaa[m]>
Is there hardware where crtcs and their drm planes have vastly different buffer capabilities? Like, only specific ones support a given format?
<daniels>
oh yes
<emersion>
it'd just be whatever the gold standard is to do it
<emersion>
zamundaaa[m]: drmdb has examples for this
<emersion>
on desktop GPUs, the plane capabilities are very different
<daniels>
it's not uncommon for one CRTC to support high-res modes and fancy scaling and compression etc, and the other to barely be able to light up a tiny DSI panel
<emersion>
on arm, they can be pretty similar
<zamundaaa[m]>
I'm mostly interested in formats because if buffer allocation is necessary at each step, that might make a generic library quite hard to do
<daniels>
yeah, the standard on arm is that the planes on a given CRTC are generally interchangeable, but CRTCs are frequently very different
<daniels>
zamundaaa[m]: why would you need to allocate buffers?
<zamundaaa[m]>
Different resolutions + different formats
<daniels>
emersion: relatedly, when I was asked last week how someone would go about doing complicated plane-property things (like complex colour management pipelines), I suggested that libliftoff would be a good place to centralise the pain
<emersion>
ah, i heard about that in the HDR workshop :)
<zamundaaa[m]>
I mean, you can't really test it in any other way than allocating the buffers and doing a test commit, can you?
<emersion>
so you're responsible!
<daniels>
zamundaaa[m]: ah yeah, needing an FB to TEST_ONLY is a long-standing issue
<daniels>
emersion: it me!
<emersion>
zamundaaa[m]: there have been various ideas floating around to TEST_ONLY without a real buffer
anshuma1 has quit []
<zamundaaa[m]>
Making that possible would be very useful
<daniels>
emersion: there are two distinct usecases I see for that. one is product/platform-specific hacks where you want or need to quirk certain things in a way which can't/shouldn't ever be upstreamed because they're hyper-specific to your usecase, and libliftoff would be a good centralised place to go do those hacks. another is where your hardware is quite complex (cf. colour management where no-one has the same pipeline), and you can
<daniels>
take advantage of that in a lower-level library
<emersion>
yeah
<emersion>
although there would still need to be a stable uAPI libliftoff talks to
anshuma1 has joined #dri-devel
Company has joined #dri-devel
ybogdano has joined #dri-devel
<daniels>
oh yeah for sure; deciding collectively that libliftoff is our closest analogue to the Android HWComposer/gralloc vendor HALs, doesn't mean that our uAPI standard suddenly falls to Android vendor levels!
<emersion>
ahah
<daniels>
but I think it would be nice to have a framework for those kinds of things; whether we like it or not, people do them anyway, because sometimes doing insane heuristics for routing/prioritisation is the only way to make something work well enough to ship a product, and I'd prefer to do them somewhere where the knowledge is shared and transferable, rather than having OEMs come pay us to do it
sigmaris has joined #dri-devel
<javierm>
daniels: we need something like libcamera but for drm then :)
swalker__ has quit [Remote host closed the connection]
<danvet>
daniels, ah yes for sure
<danvet>
emersion, daniels btw just reading the newly added netlink docs
<danvet>
and netlink has extended error attributes
<danvet>
including standard stuff like "this is the prop I don't like"
<danvet>
and piles more
<daniels>
javierm: basically yeah
<danvet>
so I guess if we ever get to make atomic_check more fancy, doing it with netlink or something inspired by it might be reasonable-ish ...
<emersion>
danvet: objects/props are a netlink concept?
<daniels>
danvet: yeah, I had that idea independently a while ago
<emersion>
same P
<daniels>
great minds think alike!
<emersion>
was worried that some failures had multiple faulty props
<daniels>
it didn't get much traction at the time, but also no-one was volunteering to implement it, we were just kicking ideas around randomly on IRC
<danvet>
it would be entirely free-standing, i.e. access control still through drm chardev
<danvet>
but could use it to try out configs in a much more structured way
<daniels>
but I definitely think 'this set of properties are objectionable' is a better framework than trying to express enumerated constraint failures
bmodem1 has quit [Ping timeout: 480 seconds]
<danvet>
daniels, well the real problem is still teaching drivers how to give more meaningful info than EINVAL
* emersion
sees the FB_ID failure elephant in the room
<daniels>
i.e. 'DEST_W and DEST_H and FB_ID on plane 17 are no good' is a more tractable starting point than 'I can't do scaling with AFBC'
<danvet>
it's a ton of work either way, so pragmatic me expects we'll muddle on for a few more years with random enums
<daniels>
emersion: _cough_
<danvet>
yeah I mean that's the issue
<danvet>
if one driver signals "can't scale" by complaining about the fb_id
<danvet>
next about DST_W
<danvet>
third about DST_H
<danvet>
fourth about SRC_W
<danvet>
fifth about SRC_H
<danvet>
sixth about the PLANE_ID just because
<danvet>
we've not really improved the situation
<daniels>
#6 gets slapped down in review
<vsyrjala>
"could have worked with that other plane there"
<vsyrjala>
without actually specifying which plane ofc
<danvet>
daniels, CRTC_ID might be a cool one too
<emersion>
IN_FORMATS :D
<daniels>
#2-5 are addressed by starting out with helpers in drm core which attempt to contain the damage
<danvet>
so we're still back to "you fool, how dare you" and snickering
<emersion>
yeah, forcing drivers to report errors via special-purpose helpers could help
<daniels>
emersion: haha, I mean you could argue that for some hardware, the driver complaining about the read-only data exposed by the driver is actually reasonable
<daniels>
'it's not you, it's me. sorry.'
<emersion>
lol
<danvet>
daniels, that's a bit dramatic for a kernel driver ...
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<danvet>
maybe we need ERELATIONSHIP_COUNSELING_NEEDED or something
<daniels>
anyway, we all know that EINVAL is uselessly vague, and that enumerated errors are also uselessly vague; the mechanism we have is userspace communicating properties forward to the kernel, so coming back with 'yes, yes, yes, no, yes, no, no, yes' is probably the reasonable middle ground
Jeremy_Rand_Talos_ has joined #dri-devel
<daniels>
danvet: 'I'm listening, I'm learning, and I'm trying to be better every day'
<danvet>
daniels, yeah maybe we need a bit of that, EINVAL is a tad brusque
<daniels>
option #4 is that drivers/accel/ inherits DRM's internal-client concept, and we use that to run a NN across the atomic request to figure out the right one
<danvet>
that might actually work
<danvet>
sample bazillion of compositor states from userspace
<danvet>
brute-force them with unlimited cpu time
<robclark>
drive-by: it would be nice if atomic ioctl could at least report which object failed atomic check
apinheiro has joined #dri-devel
<danvet>
then feed that crap to a NN network for quick inferrence in the field
<danvet>
robclark, that's not that easy, see above
<robclark>
or rather first obj that failed atomic test.. that would be something core could report
<danvet>
robclark, like when you run out of scanout bw or fifo space because big upscaling plane ... do you blame that on the plane, the crtc, or the other crtcs already in use?
karolherbst has joined #dri-devel
<robclark>
if memory bw, it would be _one_ of the planes
<vsyrjala>
i'd blame the dotclock, so crtc clearly :P
<danvet>
robclark, if you do the naive helper implementation that might be a plane id you didn't even list
<danvet>
in your atomic ioctl
<danvet>
due to cross crtc lolz
<danvet>
or it's a driver specific atomic state, and then it's just *shrug, whatever*
tzimmermann has quit [Quit: Leaving]
rkanwal has quit []
<daniels>
then you just report that object ID 0 is problematic, so userspace can do strcmp(driver->name, "i915") == 0 and fall back to 1024x768 if so
<robclark>
:-P
karolherbst has quit [Quit: Konversation terminated!]
heat has joined #dri-devel
sigmaris has quit [Ping timeout: 480 seconds]
sigmaris has joined #dri-devel
karolherbst has joined #dri-devel
karolherbst has quit []
karolherbst has joined #dri-devel
karolherbst has quit [Quit: Konversation terminated!]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
karolherbst has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
ybogdano is now known as Guest2763
ybogdano has joined #dri-devel
Guest2763 has quit [Ping timeout: 480 seconds]
ybogdano is now known as Guest2767
ybogdano has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Guest2767 has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
anshuma1 has quit [Ping timeout: 480 seconds]
<DrNick>
instead of returning an integer, the kernel should return a nvlist containing rich error information
vliaskov has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
ngcortes has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
lemonzest has quit [Quit: WeeChat 3.6]
apinheiro has quit [Ping timeout: 480 seconds]
ngcortes_ has joined #dri-devel
ngcortes_ has quit []
ngcortes_ has joined #dri-devel
ngcortes_ has quit [Read error: Connection reset by peer]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
Mangix has joined #dri-devel
chipxxx has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
ngcortes has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
Mangix has joined #dri-devel
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
Wallbraker[m] has joined #dri-devel
khfeng_ has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
vup has joined #dri-devel
apinheiro has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
hikiko has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has joined #dri-devel
foul_owl has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
hikiko has joined #dri-devel
foul_owl has joined #dri-devel
JohnnyonF has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
kumeatsu has joined #dri-devel
hikiko has quit [Ping timeout: 480 seconds]
hikiko has joined #dri-devel
rgallaispou1 has joined #dri-devel
<kumeatsu>
hallo
<jenatali>
Ugh stupid Matrix bridge keeps going out without me noticing
rgallaispou has quit [Read error: Connection reset by peer]
kumeatsu has left #dri-devel [#dri-devel]
kumeatsu has joined #dri-devel
<kumeatsu>
anyone?
<jenatali>
kumeatsu: hello
<lstrano>
karolherbst: was luxmark3 working for you on rusticl with iris there?
ybogdano is now known as Guest2779
ybogdano has joined #dri-devel
<karolherbst>
lstrano: yeah
<kumeatsu>
I am new here
<kumeatsu>
can anyone see my message ?
hikiko has quit [Read error: Connection reset by peer]
hikiko has joined #dri-devel
<lstrano>
karolherbst: anything I need to do for rusticl to find iris? libgl_drivers_path is set to the right location, but clinfo gives me no devices found in platform
<karolherbst>
lstrano: need to point to the ICD file
<karolherbst>
I have that in my wrapper script: export OCL_ICD_VENDORS=${OCL_ICD_VENDORS:-"/home/kherbst/local/etc/OpenCL/vendors/rusticl.icd"}
<lstrano>
karolherbst: OCL_ICD_VENDORS is set (and clinfo shows rusticl)
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
<lstrano>
but clinfo shows cGetDeviceIDs as no devices found (getplatforminfo shows rusticl)
<karolherbst>
ohh, then you just need "IRIS_ENABLE_CLOVER=1", because I still don't enable anything and didn't come up with a proper mechanism and all that :)
<lstrano>
karolherbst: ack, thats it :)
<karolherbst>
I am thinking about having a "RUSTICL_ENABLE=iris" thing or something
kumeatsu has quit [Quit: Powered by WinIRC]
hikiko has quit [Remote host closed the connection]
Guest2779 has quit [Ping timeout: 480 seconds]
hikiko has joined #dri-devel
kumeatsu has joined #dri-devel
mhenning has joined #dri-devel
<kumeatsu>
hi there
zehortigoza has quit [Ping timeout: 480 seconds]
<HdkR>
kumeatsu: Yes?
<kumeatsu>
ah, finally. I am new to here :)
<HdkR>
o7
hikiko has quit [Read error: Connection reset by peer]
hikiko has joined #dri-devel
<kumeatsu>
actually, I'd like to ask about whether zink support glesv3 and if it does how can I configure mesa to build the so :)
danylo has quit [Ping timeout: 480 seconds]
GeorgesStavracasfeaneron[m] has quit [Ping timeout: 480 seconds]
cwfitzgerald[m] has quit [Ping timeout: 480 seconds]
Vin[m] has quit [Ping timeout: 480 seconds]
YaLTeR[m] has quit [Ping timeout: 480 seconds]
Mis012[m] has quit [Ping timeout: 480 seconds]
Guest2365 has quit [Ping timeout: 480 seconds]
Weiss-Fder[m] has quit [Ping timeout: 480 seconds]
Anson[m] has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 480 seconds]
robertmader[m] has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
Wallbraker[m] has quit [Ping timeout: 480 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
egalli has quit [Ping timeout: 480 seconds]
T_UNIX has quit [Ping timeout: 480 seconds]
AlexisHernndezGuzmn[m] has quit [Ping timeout: 480 seconds]
Sumera[m] has quit [Ping timeout: 480 seconds]
tleydxdy has quit [Ping timeout: 480 seconds]
gdevi has quit [Ping timeout: 480 seconds]
DavidHeidelberg[m] has quit [Ping timeout: 480 seconds]
eyearesee has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
zzoon_holidays_until_3rd_Oct[m has quit [Ping timeout: 480 seconds]
michael5050[m] has quit [Ping timeout: 480 seconds]
heftig has quit [Ping timeout: 480 seconds]
kunal10710[m] has quit [Ping timeout: 480 seconds]
Jean[m]1 has quit [Ping timeout: 480 seconds]
znullptr[m] has quit [Ping timeout: 480 seconds]
gagallo7[m] has quit [Ping timeout: 480 seconds]
kunal_10185[m] has quit [Ping timeout: 480 seconds]
DemiMarie has quit [Ping timeout: 480 seconds]
tomba has quit [Ping timeout: 480 seconds]
aura[m] has quit [Ping timeout: 480 seconds]
yshui` has quit [Ping timeout: 480 seconds]
pushqrdx[m] has quit [Ping timeout: 480 seconds]
Strit[m] has quit [Ping timeout: 480 seconds]
viciouss[m] has quit [Ping timeout: 480 seconds]
naheemsays[m] has quit [Ping timeout: 480 seconds]
jekstrand[m] has quit [Ping timeout: 480 seconds]
onox[m] has quit [Ping timeout: 480 seconds]
nyorain[m] has quit [Ping timeout: 480 seconds]
Labnan[m] has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit [Ping timeout: 480 seconds]
moben[m] has quit [Ping timeout: 480 seconds]
PiGLDN[m] has quit [Ping timeout: 480 seconds]
jasuarez has quit [Ping timeout: 480 seconds]
dcbaker has quit [Ping timeout: 480 seconds]
DrNick has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Ping timeout: 480 seconds]
ella-0[m] has quit [Ping timeout: 480 seconds]
xerpi[m] has quit [Ping timeout: 480 seconds]
Dylanger has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
ramacassis[m] has quit [Ping timeout: 480 seconds]
sigmoidfunc[m] has quit [Ping timeout: 480 seconds]
Ella[m] has quit [Ping timeout: 480 seconds]
nielsdg has quit [Ping timeout: 480 seconds]
ralf1307[theythem][m] has quit [Ping timeout: 480 seconds]
r[m] has quit [Ping timeout: 480 seconds]
Andy[m] has quit [Ping timeout: 480 seconds]
KunalAgarwal[m][m] has quit [Ping timeout: 480 seconds]
undvasistas[m] has quit [Ping timeout: 480 seconds]
masush5[m] has quit [Ping timeout: 480 seconds]
knr has quit [Ping timeout: 480 seconds]
kunal_1072002[m] has quit [Ping timeout: 480 seconds]
jenatali has quit [Ping timeout: 480 seconds]
hasebastian[m] has quit [Ping timeout: 480 seconds]
RAOF has quit [Ping timeout: 480 seconds]
halfline[m] has quit [Ping timeout: 480 seconds]
robertfoss[m] has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
sjfricke[m] has quit [Ping timeout: 480 seconds]
martijnbraam has quit [Ping timeout: 480 seconds]
mairacanal[m] has quit [Ping timeout: 480 seconds]
neobrain[m] has quit [Ping timeout: 480 seconds]
Mershl[m] has quit [Ping timeout: 480 seconds]
pac85[m] has quit [Ping timeout: 480 seconds]
frytaped has quit [Ping timeout: 480 seconds]
kallisti5[m] has quit [Ping timeout: 480 seconds]
Soroush has quit [Ping timeout: 480 seconds]
JosExpsito[m] has quit [Ping timeout: 480 seconds]
doras has quit [Ping timeout: 480 seconds]
<kumeatsu>
^BHello World^B
hikiko has quit [Read error: Connection reset by peer]
hikiko has joined #dri-devel
<psykose>
-Dgles2=true
ybogdano has quit [Ping timeout: 480 seconds]
<LaserEyess>
if hardware supports adaptive sync on windows (or claims to?) and does not support it on linux according to drm_info, what would be the cause of that?
<HdkR>
kumeatsu: Yes, it supports GLES 3.3 and GL 4.6