<dj-death>
MrCooper: I don't know why, I tried yesterday and it just put the download mail as attachment :)
simon-perretta-img has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
jkrzyszt has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
Akari has joined #dri-devel
bmodem has joined #dri-devel
simon-perretta-img has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lumag_ has joined #dri-devel
saurabhg has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
lemonzest has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
<javierm>
MrCooper: interesting, thanks for that info
<MrCooper>
no worries
hch12907 has quit [Ping timeout: 480 seconds]
<javierm>
MrCooper: the only thing I'm missing in thunderbird is to use an external editor, there's used to be an add-on but unfortunately is not compatible anymore with newer versions
<MrCooper>
that's too bad
<javierm>
guess I could save, edit, then open it again from thunderbird but it's too much churn
bmodem has quit [Ping timeout: 480 seconds]
<MrCooper>
yeah, luckily for me, I'm mostly happy with Thunderbird's composer
hch12907 has joined #dri-devel
bmodem has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest494
rsalvaterra_ is now known as rsalvaterra
Guest495 has quit [Ping timeout: 480 seconds]
Lucretia has quit [Read error: No route to host]
lemonzest has quit [Quit: WeeChat 3.5]
bmodem has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
Lucretia has joined #dri-devel
rkanwal has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
lumag_ has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
Company has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
lemonzest has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
lanodan has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
Error: Error loading EGL library
<alyssa>
^ anyone seen this with glmark2?
camus has joined #dri-devel
bmodem has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
MajorBiscuit has joined #dri-devel
AndrewR has quit [Ping timeout: 480 seconds]
* alyssa
tries apt upgrading
bmodem has quit [Ping timeout: 480 seconds]
<alyssa>
that fixed it. I won't ask questions i don't want answers to!
vjaquez has quit []
ceyusa has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
MajorBiscuit has quit [Quit: WeeChat 3.4]
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
Lucretia has quit []
sarnex_ has quit []
sarnex has joined #dri-devel
Haaninjo has joined #dri-devel
camus has quit [Remote host closed the connection]
Daanct12 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
Daanct12 has joined #dri-devel
Lucretia has joined #dri-devel
X512 has joined #dri-devel
<X512>
Do somebody work on adapting Gallium Vouveau driver to recently opened Nvidia kernel driver?
ella-0_ has quit [Read error: Connection reset by peer]
<karolherbst>
X512: what the heck is the vouveau driver?
sdutt has joined #dri-devel
<X512>
nouveau nvc0
<karolherbst>
ahh
<karolherbst>
I thought at first there were a bunch of people creating a new driver :P
<karolherbst>
X512: anyway, there are no plans, because there are also no plans on detting the nvidia driver upstream, so it's kind of pointless. One could port libdrm_nouveau to it and make it work though
<karolherbst>
but it would only be useful as a debugging tool
Daaanct12 has joined #dri-devel
<karolherbst>
there is work going on to make use of nvidias published firmware within nouveau
<karolherbst>
so that should give users what they need (performance and a more stable driver and stuff)
<X512>
I am intersted in adapting Nouveau driver to use on Haiku operating system.
<karolherbst>
X512: probably easier to port all of drm over
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest519
rsalvaterra_ is now known as rsalvaterra
<karolherbst>
BSD folks are doing it with some success
<X512>
I already compiled nv-kernel.o easily. So kernel driver should work if implement OS abstraction layer for Haiku.
<karolherbst>
well, they got it working, but they seem to be slow with updating it
<X512>
Nvidia driver have good portable architecture.
<karolherbst>
right
<karolherbst>
but whatever nvidia will or will not get upstream would use DRM directly anyway
<karolherbst>
so porting the current driver over is just a waste of time
<karolherbst>
unless it's using a DRM port to haiku
<X512>
Porting Linux kernel DRM driver is very hard and it will need big Linux compatibility layer. Something like Wine, but for kernel.
<karolherbst>
well yes
<karolherbst>
but it's possible
<karolherbst>
and gives you access to _all_ GPU drivers
<karolherbst>
ask the BSD folks who did this already
<X512>
I already made some simple but finctional Radeon SI GPU control driver for haiku that can work with RADV driver.
<karolherbst>
ohh, well.. you can also just create completely new drivers having the same UAPI, sure
<karolherbst>
but...
<X512>
It expose amdgpu compatible ioctl.
<karolherbst>
honestly, porting over DRM is time better spent
Guest520 has quit [Ping timeout: 480 seconds]
<X512>
But surrently supports only Southern Islands.
<karolherbst>
yeah, and it won't really support anything well
<karolherbst>
I am not questioning that you all could get something to work
<karolherbst>
but working on GPU drivers is a _very_ _huge_
Daanct12 has quit [Ping timeout: 480 seconds]
<X512>
Porting Nvidia driver seems to be much easier then Linux DRM drivers.
<karolherbst>
sure, but that's up to you to support then
<karolherbst>
and it will probably go away sooner or later
<karolherbst>
or maybe not
<karolherbst>
who knows
<karolherbst>
anyway, from a linux perspective there is no real incentive to use it
<karolherbst>
so if you want to use it, you'd have to work on it
<X512>
Nonestly I hope thet Nvidia will keep current portable driver arctivecture and will not make driver hardcoded to Linux.
AndrewR has joined #dri-devel
<karolherbst>
X512: well.. you are free to discuss this with Nvidia directly
<X512>
Many OSes like *BSD, Solaris, Haiku will benefit.
<karolherbst>
sure, they all can create their own GPU drivers :P
<karolherbst>
I just don't think this is going to fly
<X512>
Too much work.
<karolherbst>
anyway, the nvidia driver won't go upstream, so there is literally no interest for us to work on it
Daaanct12 has quit [Remote host closed the connection]
<X512>
Why kernel upstream is so important?
<karolherbst>
because we don't like to waste time
<X512>
DKMS etc. exists.
<karolherbst>
dkms is pain
<X512>
It is possible to compile binary kernel modules for distributives.
<karolherbst>
X512: ohh... btw, the open source nvidia driver is version locked
<karolherbst>
there is _no_ stable UAPI
<karolherbst>
it can change with every release
<emersion>
BSD already has the DRM compat, so they'd be happier with proper upstream DRM drivers
<karolherbst>
some BSD
<karolherbst>
you make it sound like there is just one BSD :P
alyssa has left #dri-devel [#dri-devel]
<emersion>
BSDs*
<X512>
Then adapt for changed kernel interface. I feel that it should be not soo hard compared to maintaining Linux compat layer.
<karolherbst>
not sure how many have DRM ports, but they get outdated fast, because nobody really cares after getting the initial port done
<karolherbst>
it's super sad
<karolherbst>
X512: lol
<karolherbst>
you have no idea how much work that is
<karolherbst>
you'd have to support all UAPIs for ever
<X512>
Also Haiku have some level of kernel driver stability so kernel modules can be distributed externally in binary packages.
<karolherbst>
changing UAPIs, good idea
<X512>
No problem.
<karolherbst>
(main reason we want everything to be upstream, because then you can't break it)
<emersion>
FreeBSD, DragonFlyBSD, NetBSD, OpenBSD all have DRM ports
<X512>
Distribute kernel + user driver pair.
<karolherbst>
X512: ehhh, that's a different thing
<karolherbst>
I meant the UAPI
<karolherbst>
not kernel ABI
<karolherbst>
you know, that stuff userspace uses from the kernel
<karolherbst>
if you think changing that on a whim is a good idea? yeah well... think about it again and come to the conclusion it's a nightmare to support unless you have spare money
<karolherbst>
X512: yeah.. good luck with that
<X512>
Programs do not need to directly interact with Nvidia kernel driver API. Only Vulkan/OpenGL drivers and windowing system driver.
<karolherbst>
sure
<karolherbst>
still a nightmare
<karolherbst>
did you look at nvidias UAPI even?
<X512>
It can be distributed in one package with kernel driver like Nvidia does.
<karolherbst>
yeah.... I want to see that first :)
<karolherbst>
but then don't complain I didn't warn you if you give up after 3 releases
<X512>
Haiku do not force to keep all kenrel drivers in OS source tree.
<karolherbst>
well.. do they have GPU drivers?
<X512>
Why have?
<karolherbst>
I mean.. is there any GPU driver for haiku now that existed for a longer period of time and is useful?
<X512>
Except my experimental RadeonGfx driver that works with RADV only modesetting drivers are currently availble for Haiku.
<karolherbst>
well.. all linux drivers are "modesetting", so it kind of depends on what you mean by that
<karolherbst>
do you mean "it's only firmware fb based" or are there GPU drivers enough to change resolutions?
<X512>
By modesetting I mean detect monitors and setup screen resolution/framebuffer etc. No 3D acceleration.
<karolherbst>
can you change resolutions and hot plugging?
<karolherbst>
*support
<X512>
Can change resolution, hot plugging currently not suppot because of lacking windowing system API support.
hch12907 has joined #dri-devel
<karolherbst>
seriously.. just port over DRM
<X512>
In theory my RadeonGfx can detect hotplugging, but nowhere to send that events.
<karolherbst>
I think you heavily underestimate how much work all of that means
<X512>
Haiku need its own native graphics stack. Haiku is not Linux.
<karolherbst>
yeah, good luck with that
<karolherbst>
I am just wondering where you get those 150+ people to work on it though
<X512>
Designing it is a lot of fun.
<karolherbst>
it sure is
<karolherbst>
if anybody wants to do it, please go ahead and have fun, but don't think it will be usefull
<X512>
My main idea is plugin based architecture and no stable kernel GPU ioctl API.
<karolherbst>
unless there is a bigger group of people wanting to work actively on it
<karolherbst>
like full time
<X512>
So each driver can expose its own interfaces it wantsw like Nvidia.
<karolherbst>
we do have that with DRM
<karolherbst>
just
<karolherbst>
in stable
<karolherbst>
stable is key here btw
<X512>
GUI server will load GPU client plugin that will interact with kernel driver.
<karolherbst>
but you can just do whatever you think it's best
<karolherbst>
it's a waste of time and won't work out if you ask me
<X512>
DRM enforce common ioctl set.
<karolherbst>
X512: done that, didn't work
<karolherbst>
X512: for a _good_ reason
<X512>
KMS enforce even more.
camus has quit [Read error: Connection reset by peer]
<karolherbst>
you can assume that what DRM is doing is the correct (tm) thing, because everything else failed in the past
<X512>
Actually there are no meaning to implement modesetting in kernel.
<karolherbst>
:D
<karolherbst>
yeah
<karolherbst>
you want to do the same mistakes we did
<karolherbst>
okay
<karolherbst>
we were at userspace modesetting
<karolherbst>
it was a mistake
<X512>
Haiku currently do modesetting in GUI server plugin, kernel drivers are very trivial. It mostly detect hardware and map memory.
<X512>
What is the problem with user modesetting?
<X512>
Less code in kernel -- less vulverabilities and more stable system.
<karolherbst>
:)
<emersion>
microkernels is where it's at ;)
<karolherbst>
I know
<karolherbst>
again: have fun doing the same mistakes. It's educational
<X512>
In theory both can be support, GUI system plugin should expose common API.
<X512>
Reasoning?
<X512>
So I see I have a chance to run Nouveau Gallium driver on Nvidia driver first :)
<karolherbst>
because if you do that stuff in userspace, how are you making sure that userspace doens't do dumb shit?
camus has joined #dri-devel
<karolherbst>
also you get a huge amount of code sharing with kms
<karolherbst>
and userspace can rely on _one_ UAPI
<karolherbst>
not twenties
<karolherbst>
*twenty
<X512>
Userland can rely on userland driver shared library plugin.
<karolherbst>
I am sure others can explain it better than me anyway
<X512>
Like Vulkan ICD for example.
<X512>
It is more flexible and not force specific driver architecture, allow to run multiple drivers with totally different architecture on the same system.
<karolherbst>
it's all great in theory, yes
<X512>
Actually Vulkan already have VK_KHR_display.
<karolherbst>
I think you forget, that the DRM linux community isn't here since yesterday, but that stuff is being worked on for ~25 years. If you can come up with some working reasonably well doing your own architecture and evertyhing? great, we might be able to learn from that, but if DRM dropped userspace modesetting and uses KMS now there are _good_ reasons for that
plombo has joined #dri-devel
<karolherbst>
I know how much fun it can be to create your own stuff
<karolherbst>
but if you want something which works for users? DRM is the way to go
<X512>
I feel that KMS was introduced because of attempts to go away from X11. And nobody made not X11 dependent userland GPU driver API.
<karolherbst>
KMS is much older than the idea of dropping X11
<X512>
Linux tends to implement everything in kernel. Monolitinc kernel.
<karolherbst>
so?
<X512>
Can't agree on userland API? Put it in kernel.
<karolherbst>
Linux seems to be successful with what it is doing
<X512>
I feel that KMS is purely organizational problem, not technical.
<karolherbst>
not going to discuss linux vs failed attempts at microkernels with you
camus has quit [Ping timeout: 480 seconds]
<karolherbst>
if microkernels are so great, then come up with one that works :)
<karolherbst>
then we can talk
<X512>
I will glad to hear techinical reasons of KMS and not some gpu-daemon for example.
<karolherbst>
theory is all great until it conflicts with experience and reality
<karolherbst>
we've done that, didn't work, we moved on
<X512>
Why it didn't work?
<X512>
Any materials to read?
<karolherbst>
I mean.. X was just that in the past, no?
<X512>
Something being in past is not techinical reasining.
<karolherbst>
not sure how technical reasoning helps here, because in the end it's also just opinions but framed as being "technical"
<karolherbst>
people agreed that kms is the way to go, so we did just that
<karolherbst>
end of story really
<karolherbst>
you can come up with "technical reasons" for both sides until the shed you want to bike is fed up with all the bikeshedding
<karolherbst>
but practically speaking we've done what we thought is best
<karolherbst>
I am sure there are tons of mailing lists emails and discussions to read all that stuff about, but that doesn't change the fact, that UMS was considered bad
<X512>
Another problem is when I tried to reload Linux amdgpu driver it caused kernel panik with -1 reference count. My userland driver restart without problem. How Linux DRM drivers are usually developed and tested? In a virtual machine and reboot after each test?
<karolherbst>
well.. people usually don't have to reload the driver
<karolherbst>
sure, it's badly tested but normally machines are simply rebooted
<karolherbst>
module unloading is always a best effort thing, because usually there is no practical reason having to do it
<javierm>
X512: one advantage that KMS in the kernel has it's the ability to do atomic modsettings
<X512>
For example I am developing kernel and I want to test changes to code I made.
<karolherbst>
sure it helps with developing and I think it's a good thing fixing module unloading/loading bugs
<karolherbst>
but it's not inside the scope of "supported features"
<X512>
Tothing stops to implement atomic modesetting in UMS, it's API design problem.
plombo has quit [Ping timeout: 480 seconds]
<karolherbst>
anyway.. if people find bugs within module unloading code and fixes them, we would welcome such contributions
<javierm>
X512: if all your graphics logic is in user-space and the kernel is only about HW access, I guess so
<karolherbst>
javierm: sounds very insecure to me tbh :P
<X512>
I am just interested how kernel developers develop their driver. They are so perfect so written code works from first attempt?
<karolherbst>
X512: well.. you can always reboot
<javierm>
X512: but from Linux POV that's not a microkernel, there isn't other way to do it that wouldn't require many calls to the kernel
<karolherbst>
anyway.. module unloading is something linux allows you to di
<karolherbst>
and fixing bugs there is valuable
<karolherbst>
it's just not the focus
camus has joined #dri-devel
<X512>
<javierm>: it is the case for Haiku. Kernel GPU driveer tasks are: detecting hardware, mapping memory, devivering interrupts to userland.
<karolherbst>
X512: how do you deal with DMA?
<javierm>
X512: yes I know but I'm talking about Linux. A different OS architecture can take different design decisions of course
<X512>
My userland driver use special kernel API to get physical page addresses and map it with GPU MMU.
<javierm>
X512: my point being that KMS *on Linux* is a technical decision
<karolherbst>
there are features on nvidia GPUs which are not supposed to be advertised to userspace by design and with _very_ good reasons
<karolherbst>
X512: you do that in userspace?
<X512>
Nvidia kernel driver has advanced privelege check system.
<karolherbst>
so.. you allow userspace to trash kernel memory?
<X512>
GPU userland driver run in dedicated process as rootr user and controlled via IPC.
<X512>
It is not loaded to GUI server process.
<karolherbst>
X512: sure.. but userspace can map physical memory into GPUs and overwrite kernel memory, no?
<karolherbst>
I am just wondering how that's considered secure? :D
<javierm>
X512: I honestly don't understand the goal of this discussion anymore :)
<X512>
Yes it can.
<karolherbst>
X512: okay.. so why is this design more secure than linux'?
<javierm>
convincing us of the advatanges of a micro kernel OS architecture ?
<karolherbst>
you allow userspace to trash kernel memory
<X512>
Of course kernel driver is less secure because it have no protections at all.
<karolherbst>
sounds like CVE material to me tbh
<X512>
GPU driver can be protecteed with IOMMU, gut not implemented yet.
<karolherbst>
X512: you miss the point.. the GPU can access _all_ memory
<karolherbst>
and it will
<karolherbst>
trashing kernel memory is no problem for the GPU if you let userspace to configure that stuff
<karolherbst>
X512: what if you don't have an IOMMU
<karolherbst>
like many x86 systems don't have
<karolherbst>
no GPU accel for those?
<X512>
GPU driver IPC interface will not allow to map soimething wrong to GPU or start DMA operation with bad address.
<karolherbst>
how sad
<karolherbst>
X512: ehhh.. that's not the point
<karolherbst>
there can be bugs
<karolherbst>
and you allow userspace to trash kernel memory
<karolherbst>
how is that not a CVE?
<X512>
Radeon SI GPU have virtual memory support and client processes pass GPU vidrual addresses.
<karolherbst>
in Linux it would always be a valid reason to file CVEs
<karolherbst>
X512: sure
<karolherbst>
but you can map physical memory in userspace :)
<karolherbst>
I just don't see how that's any secure
<X512>
Of course in kernel GPU driver it can be also bugs, and it will have much more disasterous consequences.
<karolherbst>
uhm...
<karolherbst>
what's worse than full access to kernel mem in userspace?
<karolherbst>
why having a kernel at all then?
<X512>
User memory management driver is not perfectly secure but kernel driver is obviously less secure because higher probability to overwrite some kernel structures.
<karolherbst>
I am not talking about that
<karolherbst>
I talk about why is it not insecure to let userspace map kernel memory :)
<karolherbst>
it's obviously insecure, no?
<X512>
Riunning driver in userland give some level of protrection and reduce hacking probability.
<karolherbst>
dude.. userspace owns kernel memory,.. your system is already owned
<X512>
If IOMMU is implemented it is perfectly fine.
<karolherbst>
and if there is no IOMMU?
<X512>
Problem of probability.
<karolherbst>
what do you mean? it's 100% owned
<karolherbst>
your gpu service can just read out private ssh keys or passwords and hand it to any other userspace process
<X512>
You need to exploit userneld GPU driver process first.
<karolherbst>
I don't see how that is a secure system
<karolherbst>
okay, sure, but then I have full kernel mem access
<X512>
Linux kernel DRM driver also can steal SSH keys and pass it to some hacker program or to Internet.
<karolherbst>
uhm.. but not through the GPU at least
<karolherbst>
so less attack surface
<karolherbst>
we don't expose DMA stuff to userspace because it's a terrible thing to do
<karolherbst>
honestly
<X512>
If Linux GPU DRM driver has some vulnerability it is of course possible to hack system with GPU DMA.
vyivel_ is now known as vyivel
<karolherbst>
maybe, maybe not
<X512>
Some older GPUs do not have full vfirtual memory support and need relocating buffers passed from userland. Relocating code can have bugs...
<karolherbst>
not sure why your microkernel is any better here then :)
<karolherbst>
ohh sure there can always be bugs, but we don't allow userspace direct access to private kernel memory at least
<karolherbst>
at least not intentional
<karolherbst>
but you do that on purpose
<karolherbst>
hey, I am a kernel, and I have my own memory, but I do allow any userspace process to allow DMA mappings to physical mem thorugh UAPI, I am so secure :P
<X512>
Userland GPU driver process also do not allow arbitrary kernel memory access by IPC interface. It can happen only because of bugs.
<karolherbst>
X512: okay, and how do I make sure, that not other userspace processes are just using the UAPIs and do things on their own?
<karolherbst>
but anyway
<karolherbst>
I think it's a stupid idea :P
<X512>
Physical page mapping ioctl API is root only.
<karolherbst>
well
<X512>
Recular programs can't use it.
<karolherbst>
so any root application can do it?
<karolherbst>
like "sudo ls" :P
<X512>
Root can do everyting including altering kernel memory.
<karolherbst>
uhm.. sounds insecure to me
<X512>
I feel that Linux also allow to alter physical memory from root user.
<karolherbst>
well.. you can configure your kenrel to be like that, but distributions stop allowing that
<karolherbst>
and with secure boot it's forbidden anyway
<karolherbst>
so we have the infra in place to not allow root to touch everything
<karolherbst>
on my system I don't even have /dev/kmem anymore
<karolherbst>
there is /dev/mem, but that's proteced stuff
<X512>
One of great benefits of userland driver is ease of development. It can be restarted a lot of times when testing.
<karolherbst>
sure
<karolherbst>
I can restart X/gdm/kwin as well
<karolherbst>
but yeah.. we should fix module unloading :P
<X512>
I also used dual Intel/Radeon GPU configuration at beginning. And connected screen to Intel GPU.
<karolherbst>
I used it with nouveau for a long time as it was quite stable there though
<karolherbst>
generally it does work, just if no developer uses it, bugs fall through the cracks
<X512>
What is about GPU clock reconfiguring problem?
<karolherbst>
device unbind/bind is a supported thing though
<X512>
People suffer with Nouveau because it run with very low clock speed for some new hardware.
<karolherbst>
sure, nothing we can do about it unless nvidia allows us to
<X512>
Nvidia open driver can solve that.
<karolherbst>
the _firmware_ solves that
<karolherbst>
and nouveau will use that one
<karolherbst>
there is nothing inside the driver doing that stuff really
<karolherbst>
it's all firmware
<X512>
GSP firmware?
<karolherbst>
yes
<karolherbst>
on maxwell2 hw only allows fan controls through signed firmware
<karolherbst>
pascal restricted voltage control on top
<karolherbst>
so.. even if there would be code, the hw refuses accesses
<karolherbst>
gsp will solve this problem for us
<karolherbst>
it's a 40 MB RISC-V blob
<karolherbst>
it does tons of stuff
technopoirot has quit [Ping timeout: 480 seconds]
<X512>
I am not sure but it seems that GSP firmware have similar object oriented system like NVRM.
<karolherbst>
yes
<karolherbst>
mostly because the hw is like that
kts has joined #dri-devel
<X512>
With my driver I even managed to run some Wine DXVK games on Haiku. Its fun that there are Vulkan and DirectX support, but no OpenGL Wine support yet.
plombo has joined #dri-devel
<karolherbst>
just use zink :P
<X512>
Zink works fine, I recently managed to run Kopper. But Wine need its own OpenGL intergation code.
<karolherbst>
huh? I guess if there are bugs with zink it would make sense to look into that
<karolherbst>
not sure if that's within scope of zink though
<X512>
Kopper crash for me if resizing window a lot here:
<X512>
Not sure is it a problem in my Haiku intergation code or Zink itself.
jimjams has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. probably the integration code then though.
<X512>
Looks like some locking is missing. Do not crash if set GALLIUM_THREAD=0.
<X512>
I can't find documentation how to write Gallium frontends.
<karolherbst>
the reason for that is that we suck at documentation
nchery has joined #dri-devel
<hch12907>
writing good documentation is pretty hard
<karolherbst>
I wished we would have people writing documentation :(
<X512>
Finding someone I can ask about Gallium will be also great.
<hch12907>
an ARCHITECTURE.md that has a high-level overview on gallium would be very helpful
khfeng has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
Wally has joined #dri-devel
luckyxxl has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<Wally>
Should libdrm only include drm ioctls and code?
Wally has quit [Remote host closed the connection]
Wally has joined #dri-devel
plombo has quit [Ping timeout: 480 seconds]
<jenatali>
daniels: FYI, I'm trying to get the Windows CI back up and running on Server 2022
lumag_ has joined #dri-devel
Wally has quit [Remote host closed the connection]
Wally has joined #dri-devel
<daniels>
jenatali: great!
<jenatali>
Looks like Chocolatey is pointing to a version of the Vulkan SDK that's been removed...
frankbinns has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
technopoirot has joined #dri-devel
technopo1rot has joined #dri-devel
* jekstrand
can never remember what gl_program is
saurabhg has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
<jenatali>
Wee catching real build breaks now
ybogdano has joined #dri-devel
<jekstrand>
Woo!
<jenatali>
Why is MSVC the only compiler that complained about 'return NULL;' from a bool-returning function?
<jekstrand>
It is a valid auto-cast
<jekstrand>
Not what anyone wants but I've seen that not get caught many times
<jenatali>
Yeah that's unfortunate
<jenatali>
Cool, on to running tests... let's see how far the baseline has drifted and what the server 2022 machine does for the results
<jenatali>
Yay, >1000 new passes and only a few fails, I'll take it
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #dri-devel
<jekstrand>
Nifty! What're you hacking on now?
<jenatali>
Just CI
<jenatali>
Server 2022 fixed a bunch of bugs in the software rasterizer that clean up a bunch of dumb fails
<jenatali>
I'm pushing our WARP team to get me a redistributable version so that I can fix even more - those thousands of gather fails because WARP does swizzling wrong are really embarrassing
saurabhg has quit [Ping timeout: 480 seconds]
<jekstrand>
:-/
X512 has quit [Quit: Vision[]: i've been blurred!]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<jekstrand>
dcbaker, jljusten: This is your regular ping for a waffle release.
* jekstrand
should set up a systemd time to auto-bug them by e-mail. :-P
<airlied>
yay lavapipe is offically 1.2 conformant
<jekstrand>
\o/
<zmike>
hooray at last
<jekstrand>
1.3 when? :P
<zmike>
need 21.1.1
<zmike>
then submit
<jekstrand>
21.1.1?
<airlied>
yeah we just fixed last bug a few days ago
<jekstrand>
ah
<airlied>
and only submit from released branches
<airlied>
but i have to cherrypick over your cts fixes
<zmike>
smh michael phoronix hasn't even picked up the most important news of the day yet
Wally has quit [Remote host closed the connection]
mclasen_ has joined #dri-devel
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
Wally has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Wally has quit []
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali>
\o/
technopo1rot has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
<anarsoul>
would it be acceptable to modify piglit/tests/spec/nv_texture_barrier/blending-in-shader.c to use multiplication by 0.5 instead of sqrt? This test fails on lima because fragment shader on Mali4x0 is fp16-only
<anarsoul>
mareko: ^^
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #dri-devel
<jekstrand>
anarsoul: 3 sqrts don't seem like they should flush out on fp16.
<jekstrand>
anarsoul: Is it far off or is it just off a bit because of precision?
mvlad has quit [Remote host closed the connection]
<jekstrand>
Looks like piglit defaults to a tolerance of 0.01 which is 2 or 3 in UNORM8