<javierm>
I just did the changes you and others suggested and added a few more talks/articles to the list
maxzor has joined #dri-devel
itoral has joined #dri-devel
nchery has joined #dri-devel
<cwabbott>
anholt: on the last nouveau nir fix, I took the time to fix it properly 2 years ago in RA and sent a patch but no one actually committed it for... reasons?
<cwabbott>
I guess no one had the expertise and time to actually understand it or something, but it only took me a day to write it so it shouldn't actually take that long to review and commit
<cwabbott>
oh wow, it was actually 4 years ago
rasterman has joined #dri-devel
<Venemo>
does NIR allow some intrinsic sources to be NULL, when they are unneeded?
thellstrom has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, sure, keep the a-b
<tzimmermann>
i've now landed the of-device patches
pcercuei has joined #dri-devel
<javierm>
tzimmermann: great, thanks a lot
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
Guest2377 has joined #dri-devel
apinheiro has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
Guest2377 has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
rkanwal has joined #dri-devel
Daanct12 has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
guru_ has joined #dri-devel
itoral has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
dliviu has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
dutty has joined #dri-devel
<karolherbst>
ehhh
<karolherbst>
use_pitches messes things up.. I should add it to the things we test
<dutty>
hi!
itoral has quit [Remote host closed the connection]
ced117 has joined #dri-devel
<dutty>
I have a question, hopefully you can help me! I've built osmesa+llvmpipe on macOS, it's reported via glGetString as "llvmpipe (LLVM 6.0.1, 256 bits)" however, when I try to build a core context for 4.0 it fails, I only get a 3.3 context. On Windows I'm using prebuilt binaries from https://github.com/pal1000/mesa-dist-win and it seems to work fine
<dutty>
My meson config is "meson builddir -Dosmesa=true -Dgallium-drivers=swrast -Dglx=disabled -Dgles1=disabled -Dgles2=disabled -Dshared-glapi=enabled -Dllvm=enabled -Dshared-llvm=disabled -Dprefix=$PWD/builddir/install"
<dutty>
Is there anything specific that I need to do to build llvmpipe with 4.x support?
sdutt_ has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
<MrCooper>
dutty: LLVM 6 might be too old for newer OpenGL
<dutty>
That's good to know, thanks MrCooper! I'll try a newer llvm version
<karolherbst>
jekstrand: nooo.. there are more fails for subtests I didn't caught with my runner :( some of the image tests fail with "use_pitches"
<Venemo>
using LLVM 6 at this point is archeology
<karolherbst>
yeah.. don't use llvm6 if you can use something newer
<karolherbst>
jekstrand: mhhh.. there is one perf issue I am not really sure to solve. So the client can install event callbacks once a certain status is reached, but atm I am calling it directly from the worker thread. As those can be quite expensive it can also end up stalling the entire pipeline (happens in the CTS). Adding another thread for handling those callbacks could be one idea (one for the entire runtime, not per queue)
<karolherbst>
jenatali: ^^ did you do anything about that?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<karolherbst>
the spec at least allows calling the cb async
<karolherbst>
(there are other cbs as well, so maybe it also makes sense to use it for all kinds of callbacks)
<karolherbst>
it does slow down the CTS quite a bit, so that's the annoying part
<karolherbst>
mhh.. I also have an issue where I don't set a perfect local size if the global size is odd
garrison has quit []
i-garrison has joined #dri-devel
kj has quit [Remote host closed the connection]
kj has joined #dri-devel
ramacassis[m] has joined #dri-devel
JohnnyonF has joined #dri-devel
elongbug_ has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
elongbug__ has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
elongbug_ has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
macromorgan is now known as Guest2420
macromorgan has joined #dri-devel
Guest2420 has quit [Ping timeout: 480 seconds]
h0tc0d3 has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
h0tc0d3 has quit [Quit: Leaving]
<jenatali>
karolherbst: I didn't. I didn't really dig into CTS on perf that much, was just focused on making it work
Guest2416 has quit []
<karolherbst>
okay
tagr has joined #dri-devel
jewins has joined #dri-devel
JohnnyonF has quit [Read error: Connection reset by peer]
thellstrom1 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
sdutt has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
<karolherbst>
soo.. what's the deal with pipe_grid_info.grid. do all values have to be pot?
JohnnyonFlame has joined #dri-devel
lemonzest has joined #dri-devel
<karolherbst>
ehh wait
<karolherbst>
no, I just did a mistake
iive has joined #dri-devel
<danvet>
robclark, is the dma-fence deadline stuff stalled or am I blind and it landed?
<robclark>
danvet: oh, I kinda forgot about it and got distracted on other things
<robclark>
iirc a bit of bikeshed about the ioctl but otherwise folks seemed fine with it
<kusma>
bbrezillon: I tried something similar, but I couldn't convince myself that it was an improvement. I think I'm just as unsure here.
<jenatali>
bbrezillon: That doesn't work for command lists. Command lists use modifiable VTables. Doing a snapshot at initialization is broken
<karolherbst>
the heck..
<karolherbst>
the CTS enqueues kernels from event callbacks
<bbrezillon>
jenatali: crap
<jenatali>
:)
<kusma>
Oh, I see. This was about more than just wrapping this a bit more... bespoke.
<bbrezillon>
I need to have access to ID3D12Device10 features, when those are avaibled
<jenatali>
Yeah. I'll say it's clever, but fragile
<bbrezillon>
just wanted to avoid storing a iface version in the wrapper
<kusma>
bbrezillon: So, I've been calling ID3D12GraphicsCommandList1_Foo() functions on ID3D12GraphicsCommandList7 objects without problems...
<kusma>
Not sure if it's a good idea, but it seems to work?
<jenatali>
Yeah that works
<jenatali>
On the C++ side, the interfaces use inheritance so they can seamlessly cast from higher to lower
<bbrezillon>
yeah, I know...
<kusma>
Anyway, if we want to shorten these, maybe we just generate some wrapper functions with a python script or something?
<kusma>
Or does that require us to parse the IDL files or something boring like that?
<bbrezillon>
so, the solution is to have dev[1,X] if we want to support multiple versions?
<jenatali>
You could either store them side-by-side, or you can throw type safety out the window and do a union. I'd store them side-by-side just so you can do null checks to see if the higher interface is available
<bbrezillon>
with the union, you don't know which one is supported
<kusma>
bbrezillon: you can store the version as an integer
<bbrezillon>
unless we also store the iface version somewhere
<kusma>
But not sure if that's a win
<jenatali>
Yep
<bbrezillon>
well, that's a win if we support more than 2 different versions :)
<jenatali>
True
<kusma>
I doubt we'll require that many versions. We're going to add a hard requirement on advanced barriers soon, and that's going to require a recent-ish runtime.
<kusma>
And I believe we can use later interfaces as long as the runtime is recent enough...?
<jenatali>
Right
<kusma>
(just not call the functions that requires specific flags etc)
<bbrezillon>
so dev1 and dev10 without a union?
<bbrezillon>
or should I just require dev10 from the beginning?
<bbrezillon>
I'm tempted to just call QueryInterface() where we need the new iface for now
maxzor has quit [Ping timeout: 480 seconds]
<jenatali>
Keep in mind that a QI also needs a release afterwards, but yeah that sounds fine
<jekstrand>
karolherbst: Yeah, once the SPIR-V back-end is upstream, we can probably drop spirv-llvm-translator
<jekstrand>
karolherbst: I think I've got a plan for integer textures. It's a horrible plan but it's a plan and it should work.
<karolherbst>
ahh.. I need to solve the Send situation :(
<karolherbst>
jekstrand: cool
<karolherbst>
I am already running the real CTS, but "conversions" is soooo slow, but speeding up isn't easy either, because Rust is in the way :)
<jekstrand>
karolherbst: Not sure on callbacks. There's a part of me that thinks having a callback thread isn't a terrible idea but I've not thought through it that much.
Duke`` has joined #dri-devel
<karolherbst>
the CL spec explicitly says that callbacks can be called async
<karolherbst>
I just profiled conversions
<jekstrand>
karolherbst: I need to go read some IMG code before I dive into CL today so I don't forget about it again but I should be available soonish.
<karolherbst>
30% of the time is just spend on calling callbacks or creating the compute state :(
<karolherbst>
and the CPU and GPU just stall each other
<karolherbst>
but before I can send random things into threads, I really have to figure out the Send situation, otherwise it's just unsafe madness we already have today
<karolherbst>
the event work items aren't Send, but I do send them, which.... is okay as I was careful not to mess it up, but rustc can help us telling us what's not safe :)
<karolherbst>
like it can shout at as if we pass in an Arc Ref instead of a clone
maxzor has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<anholt>
all this ntt work is making me wonder what the mtbf is for swapping pcie cards on a motherboard.
<robclark>
would be useful because minigbm/gralloc (ie. we need a way to describe things that are tiled but not necessarily ubwc)
guru_ has quit []
maxzor has joined #dri-devel
<bnieuwenhuizen>
eobclark: wrt the modifier implementation being platform specific, AFAIU waypipe will copy over dmabufs modifier and all
<bnieuwenhuizen>
robclark: ^
<MrCooper>
that's kind of silly though, as there's no generic, well-performing way to get the raw tiled data
<robclark>
it should perhaps not do that
<robclark>
so kinda willing to call that waypipe's problem
<bnieuwenhuizen>
(not sure if there was consensus about needing to keep compat with that)
<bnieuwenhuizen>
and agree it is stupid :)
<danvet>
robclark, for fourcc generally just a mesa+kernel ack and good
<danvet>
which I guess would be someone from qcom here maybe?
* danvet
dunno
jkrzyszt has quit [Ping timeout: 480 seconds]
<danvet>
robclark, bikeshed: you have them out of order, 3 before 2 :-)
<danvet>
robclark, also no idea what this has to do with ubwc? seems like bog standard tiled format modifiers?
<robclark>
3 is the "common" one, 2 is normally just used for GMEM.. maybe that was my reasoning
<robclark>
maybe abhinav__ could ack.. I _think_ display can support tiled but not ubwc
<robclark>
the only thing it has to do with ubwc is that it is _not_ ubwc
<danvet>
in general fourcc.h is explicitly for userspace/mesa internal stuff too, if that was a concern
<robclark>
ubwc implies tiled
<danvet>
oh ubwc isn't some arm caching mode?
<robclark>
it is like ccs/afbc.. a bandwidth compressed format
<danvet>
ah ok, then sounds all good to me
<robclark>
so far we mostly use ubwc for anything allocated by minigbm/gralloc so we hadn't bothered "officially" defining a public modifier for the tiled-by-not-ubwc case
<robclark>
fwiw, these fourcc would replace the FD_FORMAT_MOD_QCOM_TILED hack internal in mesa
<danvet>
yeah add them, that's what this stuff is for
<danvet>
I think both vk and gl specs explicitly mention upstream drm_fourcc.h as registry
<danvet>
and the deal was that we explicitly include anything that uses that (or even internally if it makes more sense)
<danvet>
so "kernel must have a use for it" does not apply to that file
<danvet>
also not really the strict "must be open userspace"
<robclark>
ok, sgtm.. mind pulling that into drm-misc or a-b for going thru msm-next? (I can change the ordering if you want)
maxzor has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
mi6x3m has joined #dri-devel
<mi6x3m>
hey, can anyone help me find where the defines like GALLIUM_I915 are set?
<mi6x3m>
in meson somewhere?
<mi6x3m>
found it thanks
mi6x3m has quit []
oneforall2 has joined #dri-devel
ybogdano has joined #dri-devel
maxzor has joined #dri-devel
<ajax>
has anyone tried to hook up uvesafb to simpledrm?
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
<jekstrand>
karolherbst: Ok, I think I've done enough code review that I can return to commiting grave sins in shaders. :)
ybogdano has joined #dri-devel
anarsoul|2 has joined #dri-devel
anarsoul has quit [Remote host closed the connection]
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #dri-devel
<karolherbst>
jekstrand: yay
<karolherbst>
boah.... my CTS runs aborts all the time as my ssh session dies
<karolherbst>
and screen just killed the session as well
Major_Biscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
but at least no new issue :)
<jekstrand>
:)
<karolherbst>
but conversions takes a ___loooong____
<karolherbst>
time
<jekstrand>
They take a LONG_MAX time? :P
<karolherbst>
probably
<karolherbst>
I started the run like 8 hours ago
<jekstrand>
:(
<jenatali>
Sounds about right
<karolherbst>
yeah.. I just don't use SSH anymore for the CTS run then :)
<karolherbst>
ohh wait
<karolherbst>
I know what killed it
<karolherbst>
systemd-oomd
<karolherbst>
mhhh
<karolherbst>
guess I have to figure out if conversions just eat way RAM
ngcortes has joined #dri-devel
* jekstrand
hates these CTS tests
<karolherbst>
yeah...
<jekstrand>
starting to wonder if we should just make everything unorm
<karolherbst>
jekstrand: what do you mean?
<jekstrand>
karolherbst: The unorm/snorm tests pass
<jekstrand>
it's just integer formats that are broken AFAICT
<jekstrand>
Or maybe the integer tests are just pickier
<karolherbst>
right.. but those are required afaik
<karolherbst>
"Table 19. Minimum list of required image formats for reading or writing"
* jekstrand
installs the Intel driver
* jekstrand
has shader dumps from the intel driver. \o/
<jekstrand>
Ok, maybe this will tell me something.
<karolherbst>
yay
<jekstrand>
Or maybe not. We'll see.
Major_Biscuit has joined #dri-devel
<jekstrand>
No shader workarounds
<jekstrand>
bah
<karolherbst>
jekstrand: I thought intel converts the coords
<karolherbst>
anyway.. wanted to check how they set up the samplers, as that looked a bit different than what happens in mesa
<jekstrand>
karolherbst: We found code for it but not in this test
<jekstrand>
Yeah
<karolherbst>
maybe do the same there and see if at least that works?
* jekstrand
wonders if intel_dump_gpu will work
HankB has quit [Remote host closed the connection]
HankB has joined #dri-devel
<jekstrand>
Nope. The CL driver juggles too many contexts. :-/
<jekstrand>
me tried to fix that many moons ago
<karolherbst>
:(
<karolherbst>
ahh yeah.. we leak memory :)
<karolherbst>
or well.. use more over time
<karolherbst>
"definitely lost: 1,615,036 bytes in 38,508 blocks" :)
<karolherbst>
anholt: it looks like it downloads stuff forever :P
<karolherbst>
jekstrand: okay.. yeah.. so we are leaking like 4.5MB per conversion test case.. I can see how that can end up using tons of RAM :)
nchery has quit [Quit: Leaving]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jekstrand>
:)
Major_Biscuit has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<jenatali>
anholt: Ouch... yeah sounds like this machine is having some problems. I think daniels is trying to help stand up a new one, but was having problems getting a license. We're trying to unblock him on that front
<jenatali>
Hopefully it all clears up soon
<zmike>
jenatali: heya any idea about games that run on windows and use GL?
<zmike>
looking for some examples
<jenatali>
zmike: Minecraft?
<zmike>
hm maybe
<zmike>
any others come to mind?
<karolherbst>
zmike: blizzard games usually allowed to use GL
<jenatali>
(Java edition specifically)
<ajax>
doom3
<karolherbst>
some source based games as well
<jenatali>
Yeah DOOM 3 and DOOM 2016
<daniels>
jenatali, anholt: yeah I'm just going to nuke Windows until it's improved
<karolherbst>
like the CSS and CS 1.6 I think :P
<anholt>
daniels: thanks.
<jenatali>
zmike: Looking for any particular GL version?
<anholt>
it's that or we would need to up marge's timeout to a few hours.
<zmike>
no just any
<karolherbst>
jekstrand: ehh.. I think we leak all over the place :(
<jekstrand>
karolherbst: Still not seeing samplers. :-/
<karolherbst>
ehh..
<karolherbst>
jekstrand: yeah.. no idea, I grabed your patch and nothing changes even after recompiling
<jekstrand>
:(
apinheiro has quit [Quit: Leaving]
<jekstrand>
karolherbst: I think I may have figured it out and I really don't like it
<karolherbst>
oh no, but that kind of sounds like you really figured it out if you don't like it :D
<jekstrand>
The difference between us and the Intel driver isn't the results being returned by the sampler. It's the results from the CTS's SW sampling.
<jekstrand>
I think we're changing the CPU rounding mode out from under them.
<karolherbst>
uhhhh....
<karolherbst>
_maybe_
<karolherbst>
I saw that happening compiling with Ofast, but not with like debug or something
<karolherbst>
does iris change the fp mode in any way?
<jekstrand>
Not intentionally
<jekstrand>
But who knows what all we call
<karolherbst>
yeah.. but I don't think that's it though.. let me try
<karolherbst>
mhh
<karolherbst>
nope
<karolherbst>
that's not it
<karolherbst>
the CTS has code to change the rounding mode though
<karolherbst>
jekstrand: FlushToZero
<karolherbst>
which they call inside conversions
<karolherbst>
ohh wait.. I think they stopped doing it
<karolherbst>
contractions still do
<karolherbst>
jekstrand: btw.. this test passes on iris
<karolherbst>
ehh
<karolherbst>
llvmpipe
<jekstrand>
Yeah, so it could be iris messing something up
<jekstrand>
what I know is that resultPtr is the same between the two drivers. :-/
<karolherbst>
mhhh odd
* jekstrand
builds llvmpipe
<karolherbst>
maybe the GPU changes something on the CPU
<karolherbst>
which.. would be super odd, but...
<jekstrand>
karolherbst: How do I select between iris and llvmpipe?
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
morphis has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. this looks odd, but I am sure there is a good reason
morphis has joined #dri-devel
tzimmermann_ has joined #dri-devel
pcercuei has quit [Quit: dodo]
tzimmermann has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: nope
<karolherbst>
intel does calculate different values
<karolherbst>
for the same sample
<karolherbst>
intel:
<karolherbst>
(gdb) p expected
<karolherbst>
$8 = {103, 61, -27, -40}
<karolherbst>
(gdb) p *(int[4]*)resultPtr
<karolherbst>
$9 = {103, 61, -27, -40}
<karolherbst>
rusticl/iris:
<karolherbst>
(gdb) p expected
<karolherbst>
$10 = {9, -92, 116, 108}
<karolherbst>
(gdb) p *(int[4]*)resultPtr
<karolherbst>
$11 = {103, 61, -27, -40}
<karolherbst>
let me get the float coords though
CATS has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Intel vs. rusticl do different things in get_integer_coords_offset
<bnieuwenhuizen>
jekstrand: did you have branches lying around for the import/export a fence into/from a dma-buf stuff? (hoping to avoid having to apply a bunch of downloaded patches to inevitably the wrong kernel branch)
CATS has joined #dri-devel
<jekstrand>
bnieuwenhuizen: Not rcent
<karolherbst>
jekstrand: because the input is different