<mlankhorst>
sima: shall I reset next-fixes to v6.10-rc1?
Company has joined #dri-devel
<sima>
mlankhorst, chat with mripard
<mripard>
mlankhorst: the drm-misc-next-fixes should be solved now
<mlankhorst>
ok good. :)
kts has quit [Quit: Konversation terminated!]
warpme has joined #dri-devel
rcf has joined #dri-devel
vliaskov has joined #dri-devel
rasterman has joined #dri-devel
warpme has quit []
<jani>
mripard: EDIDs are horrible crap, news at 11 :p
Company has quit [Read error: Connection reset by peer]
<mripard>
jani: so should we rename your job title as horrible crap expert ? :D
<jani>
mripard: sounds about right
Company has joined #dri-devel
<pq>
sima, so if kernel cmdline is the only intended way to use the TV mnochrome mode thing, does that waive all requirements of KMS UAPI? I mean, doesn't patch add the new thing to both? Maybe the KMS property should be removed completely?
<pq>
or is literally implemented only for the cmdline?
coldfeet has joined #dri-devel
samuelig has quit []
samuelig has joined #dri-devel
pcercuei has joined #dri-devel
yyds has quit [Remote host closed the connection]
davispuh has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
<sima>
pq, it's still for both, but it's also only for analog TV out connectors, which has a real world impact going forward of ... pretty much nothing
<pq>
ok
<sima>
like if people would come with something like this for hdmi or dp I think it's a totally different story
<karolherbst>
but it also downloads an image for 5 minutes?
nerdopolis has quit [Ping timeout: 480 seconds]
<Company>
pq: did you see my question yesterday about GL_SRGB?
<pq>
Company, I did, but way after you asked them.
<Company>
I'm still wondering if my analysis is correct
<Company>
that premultiplied and GL_SRGB don't mix
<pq>
it depends, I think...
<pq>
I'm not sure I remember GL_SRGB operation correctly.
<Company>
afaiu it just maps the float to U8 values according to the srgb tf
<Company>
for the rgb channels
<pq>
and literally nothing else? only r, g, b, not alpha?
<Company>
yeah
<pq>
when sampling a texture, before filtering?
<Company>
I don't actually know the order for that
<Company>
because I was just concerned with writing
<pq>
oh, writing side, ok
<Company>
my assumption was I end up with a premultiplied linear rgb value
<Company>
my example is always vec4 (0.25, 0, 0, 0.5)
<Company>
ie semi-transparent semi-red
<pq>
yeah, I think you cannot produce premultiplied-in-electrical with GL_SRGB writing. You can only produce premultiplied-in-optical, if you multiply in the frag shader.
<pq>
color-representation extension would allow you to use premultiplied-in-optical in Wayland
<Company>
the question came up because I want to switch GTK to linear compositing
<Company>
but not lose performance
<Company>
and that only works when using GL_SRGB
<Company>
because otherwise I need to do the conversion in a shader and old GPUs don't like that
<pq>
right, not working as a Wayland client without color-representation, or an additional premult pass after writing
<Company>
(not sure they like GL_SRGB more, but I'm optimistic)
<zamundaaa[m]>
Company: the shader isn't the problem, the shadow buffer you need is
<zamundaaa[m]>
I've been thinking about switching KWin back to gamma 2.2 compositing for that reason. It doesn't always get rid of the shadow buffer, but in the most simple cases it does
<Company>
zamundaaa[m]: probably, yeah
fab has quit [Ping timeout: 480 seconds]
<pq>
you may not need shadow buffer, if you can write a blending shader that decode-blend-encode for each fragment...
<FL4SHK[m]>
how does Mesa work regarding compiling shader code for a typical GPU?
<zamundaaa[m]>
pq: that doesn't work with older OpenGL
<pq>
swick actually wrote that code for weston a long time ago, but we haven't used it
<pq>
zamundaaa[m], yeah, probably doesn't
<FL4SHK[m]>
what does the compiler backend consist of?
<FL4SHK[m]>
and the compiler front end
<Company>
it's also too slow
<Company>
if you do too many srgb<=>linear conversions, the rpi slows down
<Company>
a desktop gpu doesn't care
<FL4SHK[m]>
Neat, you're discussing RPi's?
<Company>
but somewhere in the 2010s is the point where GPUs get slow
<Company>
these days memory is the slow stuff (just like on CPUs), but back then...
<FL4SHK[m]>
that's what caches are for
<FL4SHK[m]>
but... they only work so well
<pq>
keeping electrical blending as an option for old hardware seems like a practical solution to me
<Company>
pq: so I think I'll just use GL_SRGB anyway and not care about that mismatch, because most GTK apps are mainly opaque
<Company>
and pretty much all the inputs are non-premultiplied, so that's not an issue anyway
<FL4SHK[m]>
I'm developing an FPGA-based system. I wrote a GCC backend for the CPU, and I wrote a software rasterizer to learn how 3D rendering works.
<pq>
Company, do you do drop shadows or such? Maybe you can special-case and pre-render those?
<pq>
window shadows in client side
<zamundaaa[m]>
pq: I didn't mean it as an option, but just as what KWin will always do
<Company>
yes, but I think it's not worth it
<FL4SHK[m]>
though the CPU doesn't have virtual memory defined for it yet
<Company>
like, the shadows will be slightly off, but so what
<pq>
zamundaaa[m], in HDR mode, too?
<zamundaaa[m]>
Yes
<FL4SHK[m]>
What I want to do is port one of the open source Unix systems to the CPU, and also port Mesa
<zamundaaa[m]>
There we still need the shadow buffer, but it could be dropped down to ARGB2101010 instead of FP16
<FL4SHK[m]>
apologies, you all are having another conversation while I discuss my project.
<pq>
zamundaaa[m], so you'd re-code all content, HDR included, to gamma 2.2, blend, then re-code to display TF?
<zamundaaa[m]>
Or offload gamma 2.2 -> PQ to KMS with the ARGB2101010 buffer
<zamundaaa[m]>
Yeah
<pq>
interesting
<pq>
let me know how that works out
<zamundaaa[m]>
Will do
<FL4SHK[m]>
does Mesa outright require that a GPU it targets can run code in some way?
<FL4SHK[m]>
or can it somehow target a fixed function GPU
<FL4SHK[m]>
need to know so I can figure out how much work to do on my GPU
<Company>
zamundaaa[m]: what's the minimum GL version Kwin needs?
<FL4SHK[m]>
I'd certainly like to go all the way and make a SIMD machine
<karolherbst>
FL4SHK[m]: fixed function is usually pre OpenGL 2, and I think we only have one driver (nv30) supporting hardware like that still around.. maybe there is more?
aravind has quit [Ping timeout: 480 seconds]
<FL4SHK[m]>
But that's more work than just the fixed function components
krushia has joined #dri-devel
<pq>
FL4SHK[m], unless I'm mistaked, all the fixed-function drivers were left in the amber branch. Gallium framework does not do fixed-function, I think.
<karolherbst>
so no shaders == no OpenGL 2 or newer
<FL4SHK[m]>
ah
<zamundaaa[m]>
Company: 2.0, both desktop and ES
<FL4SHK[m]>
I'll go ahead and make a full programmable GPU then
<karolherbst>
pq: nv30 supports fixed function hardware, shaders got added with nv40+ class hardware
<FL4SHK[m]>
but then, my question is, what is the compiler side of Mesa like for compiling shader code to target the GPU?
<karolherbst>
none for fixed function
<karolherbst>
ohh wait, for programmable
<FL4SHK[m]>
Yes
<pq>
karolherbst, and it's still in Mesa main? And non-gallium?
<karolherbst>
for OpenGL: glsl source code -> glsl ir -> nir -> driver
<Company>
zamundaaa[m]: so you want to run on pretty slow machines anyway I suppose and can't require too much - at least in your most generic path
<FL4SHK[m]>
do I only need to write a compiler backend for this?
<pq>
oh, ok
LaserEyess has quit [Quit: fugg]
<karolherbst>
(which.. might not be a good idea, but ambering a single gallium driver is something we haven't done yet)
<FL4SHK[m]>
And is the compiler backend stuff in the Mesa driver?
<Company>
zamundaaa[m]: what I don't want in GTK is that HDR and SDR mode composite differently, because then your (sdr) app might change how it looks when you move it between monitors
<karolherbst>
FL4SHK[m]: correct
LaserEyess has joined #dri-devel
<FL4SHK[m]>
cool
<Company>
zamundaaa[m]: and I'm currently trying to figure out if I can achieve that by going linear everywhere
<FL4SHK[m]>
I'll look into that once the hardware is complete
<karolherbst>
you can also just go from nir straight to your ISA as the first step
<zamundaaa[m]>
Company: yeah, we need to have everything run smoothly on like 10+ year old Intel iGPUs that are connected to a 4k screen for some reason
<FL4SHK[m]>
Oh
<FL4SHK[m]>
That would be nice
<FL4SHK[m]>
I've done GCC backends before, as I've mentioned
<karolherbst>
no need to write a full backaned compiler, but you might ahve to run a lot of nir passes to make it convertable to an ISA
<FL4SHK[m]>
so hopefully the process is at least somewhat similar
<karolherbst>
yeah, should be, just a different API
<FL4SHK[m]>
cool
<FL4SHK[m]>
that makes me happy
orbea1 has joined #dri-devel
<zamundaaa[m]>
I have that same goal, blending needs to look the same on HDR and SDR screens. Right now it doesn't, and that doesn't just not look nice but causes actual problems
* karolherbst
wished things would run smoothly on 4K displays on 3 year old iGPUs
<FL4SHK[m]>
I bought a fancy FPGA dev board that I want to make a soft CPU and GPU for
<FL4SHK[m]>
500k logic cells
<FL4SHK[m]>
So it should be a good project
<FL4SHK[m]>
I'm not crazy enough to also write an OS and compiler from scratch
<karolherbst>
yeah.. though I can expect that unless your ISA is pretty trivial it might be hard to do much there
orbea has quit [Ping timeout: 480 seconds]
<karolherbst>
but...
<karolherbst>
nir allows you to lower a loooot of instructions
<FL4SHK[m]>
neat
<zamundaaa[m]>
karolherbst: the "triple buffering" I implemented achieves that on even older processors
<karolherbst>
ah nice
uis[m] has joined #dri-devel
<Company>
zamundaaa[m]: it's gonna be a fun place, because pinephone and librem5 are right at the edge of "too bad to support this"
<FL4SHK[m]>
uis: It was not that hard since I designed the instruction set to be easier to write a GCC backend for
<karolherbst>
currently on gnome though, but I might even stretch it a little by not having just one 4K, but two 4K displays 🙃
<FL4SHK[m]>
It's on my github
<karolherbst>
I have nobody else besides me to blame for expecting this to run smoothly :D
<pq>
zamundaaa[m], where does your blending difference on SDR vs. HDR come from?
<zamundaaa[m]>
Company: that's why I want gamma 2.2. It means that we don't have any additional computations un such low end devices
<FL4SHK[m]>
uis: search for flare32 gcc backend on my github, username fl4shk
<FL4SHK[m]>
I don't have the link handy right now
<Calandracas>
the iGPU on my i9 149000k struggles to drive two 4k monitors :P
<karolherbst>
damn users
<zamundaaa[m]>
pq: blending with color management (HDR / ICC profile / EDID profile / fallback path for night light) is linear, without it it's gamma 2.2
LaserEyess has quit [Quit: fugg]
<karolherbst>
shouldn't get 4K displays
LaserEyess has joined #dri-devel
<pq>
zamundaaa[m], I thought you'd do CM on both?
<FL4SHK[m]>
uis: and if you want to check out the instruction set, see flare32_cpu on my github
<FL4SHK[m]>
I also wrote a Binutils port
<Company>
karolherbst: it's better than Windows, so for now it's good enough
<FL4SHK[m]>
the CPU's FPGA code isn't complete
mohan43u has quit [Quit: WeeChat 4.2.2]
<karolherbst>
yeah, the performance is terrible, just noticebly laggy in a few cases, e.g. when animations happen
<karolherbst>
*isn't
<FL4SHK[m]>
Neat, have fun
<zamundaaa[m]>
pq: sort of, it does do color space and TF conversions in the shader if necessary, but it doesn't use the shadow buffer without any color management features enabled on the screen
<zamundaaa[m]>
I really really wanted to change that, but the terrible performance of the FP16 shadow buffer on especially older GPUs stopped that
<pq>
zamundaaa[m], hmm, but do you have HDR where FP16 sucks?
<Calandracas>
turning an FPGA into a subleq machine sounds pretty easy
<zamundaaa[m]>
No, but we'd need the shadow buffer for linear blending on SDR screens too
<pq>
zamundaaa[m], I'm thinking, if any output is HDR or otherwise needs CM at all, then turn CM on for everything. What's the problem doing that?
<Company>
karolherbst: I think the biggest problem in the desktop stacks is that there's no good GPU paths through the whole stack yet, so you end up copying too much at the interfaces between different APIs.
<FL4SHK[m]>
Calandracas: yes, it's easy to do something like that
<karolherbst>
Company: yeah...
<Company>
karolherbst: which makes everything look way worse than it should be
<FL4SHK[m]>
but you can go farther than that
<karolherbst>
it especially shows when doing screencasting, which... just doesn't work with 4K on my system
<Calandracas>
lol ik
<Calandracas>
i wrote a subleq machine with MMIO in about 50 lines of lua
<Company>
I should play with that with the newest pipewire/gtk/mutter/etc stuff
<karolherbst>
I also wished we'd have a better story for prime and drivers accepting foreign non linear images by just detiling with shaders on demand or something.
<zamundaaa[m]>
pq: the problem is that all the apps and theming need to be designed for one form of blending. Our logout screen has badly readable text with linear blending for example, and the background opacity slider in Konsole is made for gamma 2.2 blending and confuses users when 90% opacity looks like 50%
<Company>
I think that needs a proper library
<Company>
some libdmabuf or so
<karolherbst>
yeah...
<Company>
no idea who'd get that pushed to all the important tools though
<karolherbst>
need to write software emulation for tiling and detiling, or declare tiling formats and have code generated or something like that
<karolherbst>
oh well.. if we'd just had 100 people more for doing random things like that 🙃
<FL4SHK[m]>
uis: honestly I don't know the answer to that question
<pq>
zamundaaa[m], I see.
<Calandracas>
zamundaaa[m], are there any good colour managed compositors? my solution to having a colour managed workflow was "buy a monitor which doens't need calibrating"
<karolherbst>
oh btw
<karolherbst>
uis can't be seen on this side
<FL4SHK[m]>
oh
<karolherbst>
matrix moment
<pq>
zamundaaa, sounds like a lot more blending off-loaded to the compositor than I expected.
<FL4SHK[m]>
huh
<FL4SHK[m]>
Well at least I can be seen
<karolherbst>
or maybe something else? dunno honestly :)
<FL4SHK[m]>
I'm using Matrix
<Company>
it's a matrix thing
<zamundaaa[m]>
Calandracas: KWin is a good color managed compositor. Still lots to do ofc, like this blending annoyance, but it works really well already :)
<Company>
the bridge sometimes decides to break and not forward some people
<FL4SHK[m]>
I do have a machine that I had set up as an IRC client box about half a year ago
<FL4SHK[m]>
hmm
<Company>
rejoining usually fixes it for affected people
uis has joined #dri-devel
<Calandracas>
hum i might consider trying it out. I like sway but having "proper" colour managment would be nice
<Company>
*rejoining the matrix channel
<Calandracas>
also weston i guess
<zamundaaa[m]>
pq: it's exclusively background transparency, but that's used a lot
<Company>
at least that was how it was when libera hand't kicked the bridge yet
<FL4SHK[m]>
uis just rejoined
<uis>
Because IRC server doesn't count my matrix account as logged in
<pq>
zamundaaa[m], aha, yeah.
* Calandracas
tries to write his own weston plugin to make it actually useable as a desktop
<uis>
And dri-devel is logged-in only
<karolherbst>
I wished users would get some kind of feedback when that happens
<uis>
I think this is channel settings thing
<FL4SHK[m]>
uis @_oftc_uis:matrix.org: so I wrote my software renderer so I could learn how the fixed function parts of 3D renderers/GPUs work
<karolherbst>
it's bad enought that apparently on the matrix side people can remain even though they aren't on the IRC side of things
<FL4SHK[m]>
that's unfortunate
<FL4SHK[m]>
uis is saying it's because dri-devel is logged in only on the IRC side
<karolherbst>
uis: well it's not really. It's a matrix (client/bridge/whatever) bug
<FL4SHK[m]>
I am unsure if this can be seen on the IRC side
<uis>
karolherbst: I am on IRC side as uis[m], but IRC thinks I am guest
<karolherbst>
yeah.. and the matrix stuff has to cope with the fact a channel is logged in only and prevent people to post messages if they aren't permitted (by whatever means) on the IRC channel
<FL4SHK[m]>
Gotcha
<uis>
Look, here I write as logged in user(not from matrix)
<karolherbst>
sure
<uis>
And I wrote from matrix. But you didn't see.
<karolherbst>
but you shouldn't be able to join on the matrix side if you aren't registered with your matrix identity
<uis>
I'll try to logout from nickserv and write again.
<karolherbst>
(or at least get some kind of error)
<karolherbst>
anyway...
uis is now known as uistest
uistest has left #dri-devel [#dri-devel]
uis has joined #dri-devel
<uis>
I wrote test as uistest
<uis>
And you didn't see it too.
<karolherbst>
yeah, but you got an error, no?
bolson has quit [Remote host closed the connection]
<f_>
I didn't see it either
<uis>
No
karolherbst_tes has joined #dri-devel
<karolherbst>
I get this: "== #dri-devel Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)"
karolherbst_tes has quit []
<uis>
It showed message in channel for me, but not for rest
funderscore1 has joined #dri-devel
<uis>
Ah, yes. Not in channel though.
<f_>
:kinetic.oftc.net 415 funderscore1 #dri-devel :Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)
<f_>
uis: That's on matrix right?
<f_>
I'm pretty sure the Matrix bridge just ignores those errors and doesn't return anything.
<f_>
Either that, or mutes the channel completly.
<f_>
Let me check.
funderscore1 has quit [Remote host closed the connection]
<uis>
f_: matrix doesn't show it for me
f_[mtrx] has joined #dri-devel
<uis>
The thing is when I log in on matrix and join channel, for IRC I am guest
<karolherbst>
yeah.. it's really annoying, because I've heard it has caused severe misunderstandings in the past...
<f_>
uis: ok it doesn't return anything, as expected.. The bridge isn't that great..
<f_>
But IRC clients should return something.
<f_>
Let me check
f_ is now known as funderscore
funderscore is now known as funderscore1
funderscore1 is now known as f_
<f_>
uis: > Error (code 415): #dri-devel Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)
<Company>
hrm, can GL remap a texture? Like, can I use the same mekmory with GL_RGB and GL_SRGB somehow?
<uis>
Yes
<f_>
Am using senpai as my irc client along with soju bouncer
<uis>
f_: yes
f_[mtrx] has left #dri-devel [#dri-devel]
<uis>
Not to Company's question
KarenTheDorf has quit [Remote host closed the connection]
tanty has quit [Ping timeout: 480 seconds]
<pq>
Company, isn't there a toggle to turn the SRGB processing on and off? IIRC there were awfully many bits to get right, before the processing actually happens.
<zamundaaa[m]>
pq: yes, you have to turn the sRGB framebuffer thing on and off
<karolherbst>
apparently that's core with 2.1
bmodem has joined #dri-devel
<Company>
it's passed with glTexture2D()
<Company>
but then I can't change it later
Leopold_ has joined #dri-devel
<pq>
the framebuffer thing is a separate toggle
<Company>
yeah
<Company>
I was thinking about regular textures now
<Company>
sry, I should have made that clear
<Company>
I was thinking about apps passing GL textures to GTK for rendering
kts has joined #dri-devel
<Company>
and those come in as GL_RGB
<karolherbst>
GL_EXT_texture_sRGB_decode should let you sample an sRGB texture as linear
<karolherbst>
and it's just a property on the sampler
<karolherbst>
ehh I mean read out the content directly
<karolherbst>
undecoded
<karolherbst>
but not sure if that helps in your use case
<Company>
oh, that's a sampler parameter
<karolherbst>
yeah
<Company>
does Vulkan have that step?
<Company>
because I only found the srgb format stuff so far
<Company>
"If image was created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag, and if the format of the image is not multi-planar, format can be different from the image’s format"
<Company>
I suppose I can just create an srgb vkImageView?
<vsyrjala>
wasn't it so that vulkan only has the srgb formats for 8bpc but not for eg. 10bpc?
<Company>
yes
kts has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
nerdopolis has joined #dri-devel
<FL4SHK[m]>
what is bpc short for?
<FL4SHK[m]>
bits per channel perhaps?
<FL4SHK[m]>
per RGB channel I guess
<FL4SHK[m]>
24-bit RGB
kts has joined #dri-devel
kzd has joined #dri-devel
Haaninjo has joined #dri-devel
Haaninjo has quit []
bmodem has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<FL4SHK[m]>
Also I have a question: is there a list of IR instructions that I can look at so I can tailor my ISA to Mesa (to make writing the Mesa backend easier)
<FL4SHK[m]>
That's the process I went with to make development of my GCC backend easier
LeviYun has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
does vulkan offer a way to query the extensions enabled on an existing instance/device ?
mripard has quit [Quit: mripard]
<pepp>
silly question around vblank events: if the compositor commits a new state, it will be visible on screen after 1) flip event/fence is signaled *and* 2) the next vblank event after that... is that about right?
<pepp>
(ignoring the delay introduced by the display hardware)
<MrCooper>
pepp: the timestamp in the flip / atomic commit completion event corresponds to when the HW starts scanning out the new FB / using the new state
<pepp>
MrCooper: oh ok. So I can ignore the vblank (tracepoint) event
<MrCooper>
yes; note that events may be sent out earlier than that timestamp
epoch101 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<pepp>
MrCooper: thx. AFAICT the flip event is sent by drm_crtc_send_vblank_event
<MrCooper>
sounds right
sgruszka has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
KarenTheDorf has joined #dri-devel
coldfeet has joined #dri-devel
Duke`` has joined #dri-devel
tanty has joined #dri-devel
epoch101 has joined #dri-devel
frankbinns2 has quit [Ping timeout: 480 seconds]
<mattst88>
FL4SHK[m]: nir_opcodes.py is probably your best bet
<FL4SHK[m]>
mattst88: thanks
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
mohan43u has joined #dri-devel
LeviYun has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
jhli has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
linkmauve has left #dri-devel [Mise à jour !]
frankbinns2 has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
linkmauve has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
epoch101 has quit []
feaneron has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
LeviYun has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<Venemo>
DavidHeidelberg: ping. I now managed to build ANGLE but I can't figure out how to make the GL CTS use it
<Venemo>
DavidHeidelberg: can you help pls?
Duke`` has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Venemo>
DavidHeidelberg: I've tried both LD_LIBRARY_PATH and LD_PRELOAD, but the GL CTS is still somehow searching for RadeonSI
<Venemo>
I don't see how it could possibly work, considering that ANGLE only has a libEGL and libGLESv2, so... how the hell is it supposed to work with deqp, which is linked to libGL and libGLX (but not to libEGL or libGLESv2)
LeviYun has joined #dri-devel
odrling has quit [Remote host closed the connection]
feaneron has joined #dri-devel
<Venemo>
I don't even understand why deqp-gles31 is linked to libGLX when I set DEQP_SUPPORT_GLX=OFF
LeviYun has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<mattst88>
Venemo: I think I have some notes on this from anholt. let me find them
<mattst88>
I think specifically the thing you need is
<mattst88>
> Change src/tests/perf_tests/ANGLEPerfTest.cpp ModuleDir references to SystemDir, so that you can use LD_LIBRARY_PATH to switch to Mesa or switch which Mesa is used.
soreau has joined #dri-devel
<dj-death>
Venemo: I usually just run the gtest binaries : ./angle_deqp_gl46_tests
mvlad has quit [Remote host closed the connection]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<Venemo>
thx
<Venemo>
dj-death: the gtest binaries are not going to cut it, I have a radv regression that only affects the glcts with angle
<Venemo>
mattst88: I already found that, this is not helpful
<mattst88>
well, sorry then
<Venemo>
mattst88: the trouble is, I already managed to build angle, but the gl cts isn't picking it up even if I specify LD_LIBRARY_PATH or LD_PRELOAD
<dj-death>
Venemo: I thought they ran the cts
<Venemo>
dj-death: really? I didn't realize that
<dj-death>
yeah
<dj-death>
there are gles2/gles3/gles31 version etc...
<dj-death>
I was stuck like you
<dj-death>
I think you need your app to link against angle
<dj-death>
there is no way around it afaict
<dj-death>
which is why they have those gtest cts variants in there I suppose
orbea1 has quit []
orbea has joined #dri-devel
jhli has joined #dri-devel
<Venemo>
dj-death: how do you run a specific test case with those ones then?
<dj-death>
--gtest_filter=
<dj-death>
you might need some * to figure the actual prefix added by the gtest wrapping
<Venemo>
dj-death: ./run_angle_deqp_gles31_tests gives me this: /usr/bin/env: ‘vpython3’: No such file or directory
LeviYun has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
riteo_ has joined #dri-devel
<dj-death>
Venemo: I run the binary directly from the out/Release|Debug directory