ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
stuarts has quit []
<jenatali>
Dunno though, when we registered the driver name it's a Mesa driver name prefix instead of MSFT
soreau has joined #dri-devel
<anholt>
my understanding is: I would go with msft, spi should be for mesa submissions where there's no other adopter responsible for it.
<Kayden>
yeah
<Kayden>
I think it depends on who's doing the submission, mostly
<Kayden>
anv submissions are done by Intel employees, radv submissions typically aren't done by AMD folks
<Kayden>
if jenatali's involved it probably makes sense just to do MSFT
andremorishita has joined #dri-devel
<jenatali>
Yeah makes sense
<jenatali>
We still need to talk to Khronos to define what conformance requires from a layered VK driver...
<karolherbst>
jenatali: isn't it like to run on two drivers?
<jenatali>
Except our legal group bars us from participating in working group meetings
<karolherbst>
ehh.. pass conformance on two
<karolherbst>
wat...
<jenatali>
karolherbst: it's defined for GL and CL that way
<jenatali>
VK isn't defined yet AFAIK
<karolherbst>
mhhh
<jenatali>
(I expect it'll end up the same, just needs to get into docs)
<karolherbst>
but you are not allowed to do that?
<karolherbst>
or maybe just submit the MR?
<jenatali>
Last time around we got special permission to set up meetings outside of the IP zone
<karolherbst>
uhhh
<karolherbst>
why is legal like this
<jenatali>
Yeah
<Kayden>
:(
kj has joined #dri-devel
<jenatali>
And then once I finish on WARP I need to get a second driver to conformance. Hopefully that's easy but who knows
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
penguin42 has quit [Remote host closed the connection]
columbarius has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
robobub_ has joined #dri-devel
andremorishita has quit []
yuq825 has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
Company has quit [Read error: No route to host]
Company has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
<karolherbst>
dcbaker: soo.. in regards to that isystem situation with bindgen. Do you agree that the bindgen stuff needs to do something similar to what CLikeCompilerArgs.to_native does in regards to isystem arguments?
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
i509vcb has quit [Quit: Connection closed for inactivity]
dtmrzgl has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
dtmrzgl1 has joined #dri-devel
dtmrzgl has quit [Ping timeout: 480 seconds]
dtmrzgl1 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
heat has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<Company>
I need a GL/EGL expert, because versions of eglCreateContext() confuse me.
<Company>
if I want a GL - or actually: GLES - context as new as possible buit at least version 2, what do I pass to eglCreateContext()?
<Company>
because apparently, if I pass 2.0, ANGLE hands out 2.0 and Mesa hands out a 3.2 context
<Company>
even though they both support GLES 3
<HdkR>
Company: Make sure you eglBindAPI before eglCreateContext
<Company>
the code does that
<linkmauve>
Company, what I’ve seen programs do is request the most recent version they want to support, then one before that, then one before that, until the earliest one they support.
<Company>
it passes MAJOR_VERSION 2 attrib, but I thought that'd automatically give me 3 if available
<HdkR>
That too, you usually work your way backward from newest supported to oldest in your application. Changing the ctx_attrib flags as you go, and potentially channging the config you got from eglChooseConfig
<HdkR>
Since eglChooseConfig has an `EGL_RENDERABLE_TYPE` where you specify GL or ES
<Company>
yeah, I know that
<Company>
I'm just confused about versions and min vs max vs actual
<Company>
so there is no way to set a min/max and you're actually meant to try them all
<HdkR>
Also yes, if you're passing in a version ot eglCreateContext, you're not guaranteed to be automatically promoted to a newer version
<linkmauve>
Company, when you request a version, the driver can give you anything from that version up to the most recent compatible version.
<Company>
right, but it's the driver's choice?
<HdkR>
Which Angle might be respecting your decision when you chose version 2, but mesa EGL promotes
<HdkR>
That is yes
<Company>
because I want the most recent one
<HdkR>
Then you'll be wanting to pass in EGL_CONTEXT_MAJOR_VERSION, EEGL_CONTEXT_MINOR_VERSION, and if you are also wanting GL, EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE
<HdkR>
It's a big song and dance
<HdkR>
`The context returned must be the specified version, or a later version which is backwards compatible with that version. Even if a later version is returned, the specified version must correspond to a defined version of the client API`
<Company>
does that work the same with GLX and Apple and Windows GL, too?
<HdkR>
EGL Spec wording around this promotion
<HdkR>
Pretty sure
<Company>
looks like I'm gonna write some code then
<Company>
thx
<HdkR>
Luckily GL/ES is a slow lumbering beast at this point. So even if you hardcode every version you care about, it is unlikely to suddenly have a GL 5.0 or an ES 4.0 :)
<Company>
technically I think I could add code that queries the version via glGetString() and goes from there, but I'm not gonna do that, because then I need to figure out if that'a actually supported
gouchi has joined #dri-devel
dtmrzgl1 has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
DUOLabs[m] has left #dri-devel [#dri-devel]
bmodem has joined #dri-devel
gouchi has quit [Quit: Quitte]
stuarts has joined #dri-devel
kzd has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
jessica_248 has joined #dri-devel
flto_ has joined #dri-devel
flto has quit [Read error: Connection reset by peer]
jessica_24 has quit [Quit: Ping timeout (120 seconds)]
Mangix has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
fab has quit []
Mangix has joined #dri-devel
dtmrzgl1 has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
devilhorns has quit [Quit: Leaving]
Duke`` has joined #dri-devel
dviola has joined #dri-devel
<Venemo>
mareko: I've taken another look at the MR but it seems to me that there are still issues and now I agree with alyssa, it needs more consideration. also I would appreciate some input from gfxstrand
Haaninjo has quit [Ping timeout: 480 seconds]
Zopolis4_ has quit []
bmodem has joined #dri-devel
iive has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
dtmrzgl1 has joined #dri-devel
fab has joined #dri-devel
ubitux has left #dri-devel [WeeChat 3.8]
dtmrzgl1 has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
dtmrzgl has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I'm surprised that nobody ever cared about the bug you are fixing in patch #1
bmodem has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<tzimmermann>
javierm, IGT triggers it while writing near the EOF. i guess that all applications write near the beginning of the framebuffer
<tzimmermann>
and it also shows how this is all badly maintained and obsolete :(
<gfxstrand>
karolherbst, jenatali: Have either of you seen this problem with LLVM 16:
<gfxstrand>
: CommandLine Error: Option 'use-dbg-addr' registered more than once!
<tzimmermann>
thanks for reviewing, BTW
<jenatali>
gfxstrand: Yeah I saw some discussion about it a few days ago