ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery is now known as Guest1957
nchery has joined #dri-devel
<kisak>
just to check, if spirv-llvm-translator becomes important, mesa's meson bits will tell me there's trouble or someone will hopefully let me know?
<karolherbst>
isn't it already?
<kisak>
apparently no resistance to libllvmspirvlib## missing in debian style packaging
Guest1957 has quit [Ping timeout: 480 seconds]
<kisak>
rechecking, llvm is optionally looking for llvm-spirv of any version, but not version-matched to the main llvm build
<kisak>
(and missing entirely for Ubuntu 18.04)
<karolherbst>
ehh
<karolherbst>
that's... annoying
<kisak>
maybe it's not an issue for tjaalton for the main repo packages. I just haven't seen any feedback to make sure that part is sane while backporting
<karolherbst>
well, it's not really used in the foss software stack except mesa
alyssa has quit [Quit: leaving]
ngcortes has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
<karolherbst>
ahh 1d buffer :)
<karolherbst>
maybe I should implement that
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
ROw has quit [Ping timeout: 480 seconds]
SR_71 has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<karolherbst>
soo.. IMAGE1D_BUFFER
pnowack has quit [Quit: pnowack]
h0tc0d3 has joined #dri-devel
mhenning has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
h0tc0d3 has quit [Remote host closed the connection]
DanaG has quit [Quit: Leaving]
mbrost has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
icecream95 has joined #dri-devel
<jenatali>
karolherbst: that's equivalent to TBO in GL
nchery has joined #dri-devel
pendingchaos_ has joined #dri-devel
tales_ has joined #dri-devel
mbrost_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
tales-aparecida has joined #dri-devel
pallavim has joined #dri-devel
tales_ has quit []
tales-aparecida has quit []
tales-aparecida has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
AndrewR has joined #dri-devel
<karolherbst>
jenatali: yeah.. I just have to understand how the gallium interfaces work, but I think I just need to fill in the buf union field instead of tex in pipe_image_view/pipe_sampler_view. That's not the huge problem, I am just a bit wondering how I should design the buffer reference thing in rusticl
nchery has quit [Read error: Connection reset by peer]
mbrost_ has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
mhenning has quit [Quit: mhenning]
mbrost has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
nchery has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
pallavim_ has joined #dri-devel
Duke`` has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
AndrewR has quit [Remote host closed the connection]
<tjaalton>
someone was asking for a multi-arch installable mesa-utils for debian, and that is now in the NEW queue, and included in ubuntu jammy
JohnnyonFlame has joined #dri-devel
Johnny has quit [Ping timeout: 480 seconds]
jewins has quit [Read error: Connection reset by peer]
jewins has joined #dri-devel
dj-death has joined #dri-devel
Company has quit [Quit: Leaving]
i-garrison has joined #dri-devel
garrison has quit [Read error: Connection reset by peer]
JohnnyonF has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
pallavim has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pallavim_ has quit [Ping timeout: 480 seconds]
tales-aparecida has quit [Quit: Leaving]
sdutt has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
h0tc0d3 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
neonking has joined #dri-devel
mvlad has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
maxzor has joined #dri-devel
Thaodan has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Read error: Connection reset by peer]
<icecream95>
Am I just reading the code wrong, or is the list_for_each_entry_from macro often misused in Mesa?
<mattst88>
probably best to describe what problem you think there is
pallavim has quit [Ping timeout: 480 seconds]
<icecream95>
The third argument to the macro is supposed to be the list_head for the first entry, but instead the pointer to the entry itself is often used
<icecream95>
But this is not usually much of a problem, as the list_head is usually the first item in the struct
<emersion>
i'm surprised this doesn't cause type checking issues
<emersion>
is there a cast in the macro or something?
<icecream95>
emersion: LIST_ENTRY does (char *)(__item)
<emersion>
oh great, there is an uppercase and a lowercase version
<emersion>
i think LIST_ENTRY has been specifically designed to get back the containing struct from the list_head
<emersion>
so yeah, sounds like you are correct
<emersion>
it would be really nice to have better type safety here…
<emersion>
hm, although LIST_ENTRY has an offsetof in it?
<emersion>
hm, i guess the issue is that __item can be literally anything and it doesn't care
Daanct12 has quit [Remote host closed the connection]
<karolherbst>
krh: so we should add alignment to BITSET :)
<karolherbst>
potentially
Daanct12 has joined #dri-devel
<krh>
whoops, I got lost in the CUDA and OpenCL C options of godbolt
<karolherbst>
:D
<karolherbst>
would be interesting to see what we generate in mesa and if adding that alignment causes many regressions in terms of "bigger struct sizes" vs "faster code", but I usually don't do things like compare the compiled assembly :)
<karolherbst>
but I generally trust compilers to do the correct things with trivial opts like that
<karolherbst>
gcc is able to optimize it, clang fails
<karolherbst>
krh: _but_ this only counts for aligned fields. If I put a uint8_t in front I need to add "__attribute__ ((aligned (8)))" again to make it use vectors
<krh>
if you write it back to *dst instead of returning it, also fails, except for trunk where it uses sse
<karolherbst>
yeah, so I see two solutions: either make two variants: one int, the other long, or/and add alignment specifier
<karolherbst>
using long does change alignment though, so I don't know if that's the only difference or not. But we would rely less on compiler optimizations
<karolherbst>
we need bitset for 128 bit fields as well, so putting in alignment regardless isn't a bad idea
konstantin has quit [Remote host closed the connection]
<krh>
karolherbst: actually, I suspect it's fine. The way BITSET_OR is defined, it operates on an array and calls __bitset_or which takes pointers but is static inline
<karolherbst>
==3348095==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fffd0be3a00 at pc 0x7ffff7619b00 bp 0x7fffd11baa80 sp 0x7fffd11ba230
<karolherbst>
sounds like something something with array
<jekstrand>
Of course it works under valgrind....
h0tc0d3 has quit [Quit: Leaving]
<jekstrand>
Nope. -EINVAL again but no valgrind errors. :(
<karolherbst>
jekstrand: what about asan?
<karolherbst>
huh.. no valgrind error
<karolherbst>
annoying
<karolherbst>
it dies on z == 4... something is not right
Duke`` has quit []
<karolherbst>
320000 bytes... mhh
cheako has joined #dri-devel
<karolherbst>
ehhh
<karolherbst>
llvmpipe allocates without a stride, but then copies with one?
pendingchaos_ is now known as pendingchaos
* jekstrand
wonders if iris' validation list uniqueness algorithm isn't really threadsafe
* jekstrand
adds an assert
* jekstrand
doesn't have a 2nd machine to debug this. :(
* jekstrand
has no idea what iris is messing up with this execbuf. :-/
<karolherbst>
p0[-1] :(
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: ohh.. I think the lower image stuff is broken
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
<karolherbst>
jekstrand: yeah.. soo... the intel compiler messes up kernels with readonly and writeonly images mixed :(
Major_Biscuit has quit [Ping timeout: 480 seconds]
morphis has quit [Read error: No route to host]
morphis has joined #dri-devel
<karolherbst>
ehhh
<karolherbst>
I think it's shader_clone :(
<karolherbst>
ehh no, it's iris_setup_binding_table :)
<karolherbst>
I add this to the "mixed samplers/texture/images" bug
Major_Biscuit has joined #dri-devel
rasterman has joined #dri-devel
mszyprow has joined #dri-devel
<dcbaker>
jekstrand: lavapipe is failing to compile on windows in the staging/22.0 branch. because of your change to use VK_OUTARRAY, which was picked. Then you had commit `lavapipe: Drop GetPhysicalDeviceQueueFamilyProperties` which wasn't pulled, and then bbrezillon fixed the remaining use of VK_OUTARRAY in main, and I've pulled that. Would it be safe for me to pull the Drop GetPh=ysicalDeviceQuerryFamilyProperties as well?
<jekstrand>
dcbaker: I think so. Depends on if vk_common_GetPhysicalDeviceQueueFamilyProperties exists in main
<jekstrand>
karolherbst: Right. I need to fix that too
<jekstrand>
karolherbst: Nice that you've got a test case that hits it now. :)
<dcbaker>
jekstrand: does not exist in the 22.0 branch
<karolherbst>
jekstrand: yeah... I don't know if I should be worried or not... the CTS just feels like "if you pass the CTS, there is a chance you are also able to run some demo app"
<dcbaker>
is it safe to do `VK_OUTARRAY_MAKE(out, pQueueFamilyProperties, pCount);` -> `VK_OUTARRAY_MAKE_TYPED(VkQueueFamilyProperties, out, pQueueFamilyProperties, pCount);` instead?
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jekstrand>
dcbaker: Yeah, that'll work.
<jekstrand>
dcbaker: And probably the simpler fix
* jekstrand
wishes MSVC would get typeof()
<karolherbst>
MSVC doesn't have typeof?
<jekstrand>
No
<jekstrand>
It sucks
<karolherbst>
:'(
<karolherbst>
why are we even caring about such a toy compiler?
<dcbaker>
and the C committee said "theres to few valid uses for `typeof` so we we wont add it" :(
<dcbaker>
s/to/too
<karolherbst>
....
<ajax>
uh
<karolherbst>
C++ even has decltype ...
<dcbaker>
yeah, which is super useful
<dcbaker>
just like `typeof`
ybogdano has joined #dri-devel
* jekstrand
is tempted to write an execbuf validator in userspace
<karolherbst>
uhm.. does CL 3.0 require read_write images?
<karolherbst>
might be only CL C 3.0
<karolherbst>
ohhh nooooo
<karolherbst>
jekstrand: so.. clang enables read_write image support for CL C 3.0 if the spirv target is used .... :(
<karolherbst>
maybe we get away by only exposing CL C 1.2
<jekstrand>
karolherbst: :-/
<karolherbst>
ahh well.. if we expose CL 3.0 we also require CLC 3.0...
<karolherbst>
it also enables some atomic features.. it's very annoying
<karolherbst>
I will see if I can cheat around it somehow
<karolherbst>
"PASSED test." at least
<karolherbst>
annoying :(
<karolherbst>
it sounds like they assume llvm being used down to the hardware :D
<karolherbst>
or well.. they stop caring after they returned their binary
<jekstrand>
Yes, that's the way they assume LLVM is used. :-(
neonking has quit [Remote host closed the connection]
<karolherbst>
I really don't want to ship our own opencl-c-base.h file though...
<jekstrand>
:(
<karolherbst>
maybe I write a patch and add a #if !defined(__DISABLE_IMPLICIT_SPIRV_FEATURES__) or something
<karolherbst>
and then it's up to us to set that define
neonking has joined #dri-devel
* jekstrand
has a theory as to what's going wrong
<jekstrand>
Ok, found it. Now to figure out why
<karolherbst>
jekstrand: using opencl-c-base.h isntead of opencl-c.h: CTS run 08:35 -> 06:19
<karolherbst>
especially those not executing kernels
<karolherbst>
C parsing is expensive :)
<Venemo>
why does nir_intrinsic_instr::num_components exist?
<jekstrand>
Mostly validation
<jekstrand>
I think there are a few intrinsics that need it apart from validation but I'm not remembering examples immediately.
<karolherbst>
yeah.. I wanted to say there are some intrinsics which are variable in this regards and one has to set it there...
<karolherbst>
but things might have changed
<jekstrand>
Most of the time, it's just validated against dest.ssa.num_components or src[i].ssa->num_components
<jekstrand>
But I think there are a few intrinsics which don't have a variable-size source/destination and it controls something.
<jekstrand>
I've thought about trying to remove it. It's usually redundant information.
maxzor has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<Venemo>
jekstrand: yeah, I was thinking what information this may hold that the dest's num_component doesn't
gouchi has quit []
<karolherbst>
jekstrand: yeah.. seems like we have to fix llvm
<karolherbst>
it's also enabling a bunch of extensions we might not want to support outright
<karolherbst>
okay..
<karolherbst>
let me fix printf then :'( *sigh*
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
Venemo: In some cases, it's nice to have it because it might be in the dest or one of the sources and you don't want to have to figure out which.
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<Venemo>
does Crocus have its own compiler or does it share the compiler with other Intel drivers?
<jekstrand>
shared
<Venemo>
is it the thing in src/intel/compiler?
<jekstrand>
yup
<Venemo>
ok, that's weird. it seems that my changes regressed crocus but not iris
<jekstrand>
That's entirely possible, especially if they somehow affect vec4
<Venemo>
vec4 what?
<jekstrand>
That's now crocus-specific (and old HW with ANV)
<jekstrand>
Venemo: Intel has two back-ends. A vec4 back-end which is used for vertex/geometry on Haswell and earlier, and a scalar back-end that's used for fragment and compute on all hardware and vertex/geometry on Broadwell+
<Venemo>
oh, okay
<Venemo>
I assume brw_vec4_* is the vec4 backend right?
<jekstrand>
yup
<jekstrand>
Kayden: I don't think iris_bo_screen_deps is threadsafe....
<Venemo>
is it possible that this old backend ignores or mishandles the nir_intrinsic_component?
<jekstrand>
Venemo: Very
<Venemo>
:(
<jekstrand>
Why? What'd you change?
<Venemo>
I made an improvement to nir_opt_shrink_vector to shrink the start of the vector, not just the end
<Venemo>
this breaks the CI on a few drivers
<Venemo>
s/breaks/fails
ybogdano has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<jekstrand>
Kayden: Looking at this, I'm not sure how to make it correct, TBH.
<jekstrand>
Venemo: I could totally believe that it's ignoring the component offset on some things.
ngcortes has joined #dri-devel
<Venemo>
jekstrand: I've never looked at that code before so I don't have high confidence, but if I go to brw_vec4_nir.cpp and search for nir_intrinsic_load_ssbo it doesn't seem to care about the component
<jekstrand>
load_ssbo has a component?!?
<Venemo>
let me check
<jekstrand>
It doesn't
<jekstrand>
Only inputs and outputs should have a component
<Venemo>
hmm
<jekstrand>
If you want to shift load_ssbo, you just add to the offset
<Venemo>
indeed, right now I only handle things that have a component offset
<Venemo>
I suppose I could also add things that have a base offset, but I haven't done that yet
<Venemo>
then I'm not really sure what to look for. the brw_vec4_nir code seems to handle the component offset for load_input fine
<jekstrand>
It's failing deeper. The generated shader assembly is failing validation. It's probably a vec4 compiler bug. You'll probably need me or an Intel person to look at it.
Sanskar_Bhushan has quit []
<Venemo>
maybe it's better to just add a bool that would let it opt out from this optimization
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<karolherbst>
jekstrand: iris_slab_free races on the deps, no?
<jekstrand>
karolherbst: Not sure
<jekstrand>
Probably not if it's freeing things
<karolherbst>
yeah.... that would be my assumption, but...
<karolherbst>
maybe stick an assert in there to make sure the lock is not locked?
<karolherbst>
but... if there is a race on that, there should be a bug elsewhere
<karolherbst>
interesting
<karolherbst>
jekstrand: which test is triggering traces?
<jekstrand>
karolherbst: math_bruteforce fdiv
<karolherbst>
ahh
<karolherbst>
right.. we have to solve those before running the real CTS :)
<karolherbst>
jekstrand: maybe ignore the race for now as it could be that rusticl is racy as well
<jekstrand>
karolherbst: Can't. It's causing -EINVAL from i915. But I've got a fix now
<airlied>
karolherbst: I've had a few discussion with llvm folks about that stupid, they had some suggestions on how to proceed, but I never got back to doing it
<karolherbst>
I probably have to use it at some point
<karolherbst>
but the issue is printing the vectors
Lyude has quit [Quit: WeeChat 3.4]
Lyude has joined #dri-devel
Haaninjo has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: it does the vectors
pcercuei has joined #dri-devel
<airlied>
oh actually you might need to rip code out of clover
<airlied>
could try and port clover print_formatted to C and reuse it
<karolherbst>
yeah...
<karolherbst>
something like that
<karolherbst>
but I already have the parsing code... :D
<karolherbst>
in case you have questions about the ISA
<karolherbst>
jekstrand: I can imagine that the unordered comparision makes the difference
<jekstrand>
karolherbst: The constants are very different
<karolherbst>
they aren't?
ngcortes has quit [Read error: Connection reset by peer]
<jekstrand>
Oh, you're right
<jekstrand>
Not sure then
<karolherbst>
nir_flt vs NEU
<jekstrand>
Ok, I've got the pass ported
<karolherbst>
ehh GEU
h0tc0d3 has quit [Read error: No route to host]
<karolherbst>
might be that the second flt needs to be fltu
<karolherbst>
in case we support that
<jekstrand>
PASSED 2 of 2 sub-tests.
<karolherbst>
nice
<karolherbst>
so what did you had to change?
<jekstrand>
I ported it properly? Called it in the right spot?
<karolherbst>
:D
<karolherbst>
okay
<karolherbst>
yeah no idea what I messed up
<jekstrand>
karolherbst: You have to call it really early
<jekstrand>
Before the first nir_opt_algebraic
<karolherbst>
probably
<karolherbst>
ohh yeah.. I called it after linking
<jekstrand>
:D
<karolherbst>
because you know.. libclc also might have fdivs and...
<jekstrand>
We can call it on libclc if you want
<jekstrand>
But, yeah, I get your point
<karolherbst>
I don't think we have to
<karolherbst>
otherwise other tests would have failed already
<jekstrand>
Ok, so those tests are working now.
<karolherbst>
\o/
* jekstrand
drops the -w just for curiosity
<jekstrand>
Yup. Passes without -w
<karolherbst>
cool
<jekstrand>
Maybe it's time to attack images?
<karolherbst>
yeah
<karolherbst>
that's like the only bug left after I fix printf
nchery has quit [Ping timeout: 480 seconds]
<karolherbst>
well
<karolherbst>
if you want something small there is always isnormal
<jekstrand>
How many images/samplers are we required to support?
<karolherbst>
I'd start with splitting the table for now, but I think 128 images
<karolherbst>
but not 128 images
<karolherbst>
it's a bit complicated
<karolherbst>
read images: 128
<karolherbst>
write images: 64
<karolherbst>
samplers: 16
<jekstrand>
Ok, 128 textures, 64 images. WFM.
<karolherbst>
yeah, but that's not critical atm. Embedded allows lower limits, so we can accept our 32/32 for now. What's more annoying is, that iris has this merged list
<karolherbst>
so I'd like to get this part fixed first if possible
<jekstrand>
karolherbst: Ok, fisnormal fixed
<karolherbst>
\o/
<karolherbst>
profiling execute mixes them
* jekstrand
makes MRs
<karolherbst>
and the store_image operates at binding 1, even though there is one readonly and one writeonly image
<karolherbst>
not sure if I have to fix rusticl there or if iris is just wrong :)
<jekstrand>
Ok, images time.
Major_Biscuit has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<jekstrand>
Ugh... I really don't like the way we're handling textures_used
Duke`` has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit []
SR_71 has quit [Ping timeout: 480 seconds]
h0tc0d3 has joined #dri-devel
Daaanct12 has joined #dri-devel
<dj-death>
jekstrand: don't know if you have any interest in looking into lower_shader_calls() issues, I just ran into one that is : for (...) { call(); continue; }
<jekstrand>
dj-death: In theory, that should work....
<jekstrand>
But I could believe it's busted. :)
<jekstrand>
dj-death: Sadly, I don't know how I would test any fixes. :-/
<jekstrand>
zmike: Why does zink_compiler scan for images_used itself? Why not trust nir?
<dj-death>
the control flow code is assume you can't have a jump at the end of the block you going to paste code into
<dj-death>
which is fair
<jekstrand>
dj-death: It shouldn't. It should just assume you don't paste after a jump
<dj-death>
jekstrand: I'll look into it soon, unless someone beats me to it
<dj-death>
jekstrand: yeah it's probably something to update in the lowering pass
nchery is now known as Guest2032
nchery has joined #dri-devel
Guest2032 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
maxzor has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
xroumegue has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
<dj-death>
jekstrand: I think it's when we copy the loops
<dj-death>
jekstrand: then the second loop's post call gets pasted before the first one
* dj-death
looking
ngcortes has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
jfalempe has quit []
rasterman has quit [Quit: Gettin' stinky!]
mbrost has joined #dri-devel
<zmike>
jekstrand: don't remember off the top of my head but might be for use with other frontends
<zmike>
jekstrand: top of my head was right
<mattst88>
win 31
<zmike>
"trust nir" smh who would ever do that
<jekstrand>
mattst88: Dang... I know google cares about backwards compat, but that's a bit hash don't you think?
<mattst88>
lol
<mattst88>
don't worry! it's NT 3.1, not plain old windows 3.1
<jekstrand>
Good. As long as it's for workgroups!
* urja
literally has Finnish WFW 3.11 running right now, on hardware
ybogdano has quit [Ping timeout: 480 seconds]
<krh>
we need windows for subgroups
h0tc0d3 has quit [Read error: No route to host]
jewins has quit [Ping timeout: 480 seconds]
HankB__ has quit [Remote host closed the connection]
HankB__ has joined #dri-devel
icecream95 has joined #dri-devel
<jekstrand>
karolherbst: Ugh... If we're going to do this, we're going to have to bump PIPE_MAX_SHADER_IMAGES and friends. :-/
<karolherbst>
yeah...
<karolherbst>
nine needs it anyway
<karolherbst>
nobody bothered though
<jekstrand>
karolherbst: I think it's actually ok. It doesn't look like it'll break much
<jekstrand>
famous last words...
<karolherbst>
there are some games which actually need more than 32
<karolherbst>
so atm it's just broken with nine :)
<jekstrand>
karolherbst: nine doesn't use images
<karolherbst>
it uses textures
<jekstrand>
That's PIPE_MAX_SHADER_SAMPLER_VIEWS which is already 128
<karolherbst>
ohh, so somebody fixed that already?
<karolherbst>
yeah.. the CTS is kind of crappy testing all of that
<karolherbst>
I'll make the code work with the cTS firs though.. but I meant it's just... super annoying to port to C
<karolherbst>
I essentially write it from scratch :(
<airlied>
i can pretty much say the code works in clover
<karolherbst>
ohh sure, I am convinced it works
<karolherbst>
but I am also convinced you can crash the runtime
<airlied>
the piglit tests should cover a lot of corner caes
<airlied>
passing cts is pretty low bar
<karolherbst>
true
<karolherbst>
I'll work through the crashes with piglit next, but for now I just want the CTS to pass :D
eukara has quit []
<airlied>
yeah as long as you dont forget :-p
<karolherbst>
I mean.. as long as the application doens't do dump stuff, it works great :)
<karolherbst>
*dumb
eukara has joined #dri-devel
jewins has joined #dri-devel
<airlied>
feel free to speculate on the printf mr with dumb ideas
<karolherbst>
I'd just throw AFL at it and let it figure out the dumb ideas :D
<karolherbst>
although it would find more than just stupid printf formats
<jekstrand>
Ugh... no Marge for me. The Windows build machine died.
<jekstrand>
daniels: ^^
<jekstrand>
But -EWEEKEND
<jekstrand>
karolherbst: I kicked my tex/sampler branch to Jenkins. I'm sure I messed something up. :)
<jekstrand>
I've not tested any of it with CL yet. Just typed until it built, verified with gears, and kicked to Intel CI.
<karolherbst>
okay
<karolherbst>
I might give it a try after I finished printf
<jekstrand>
Ok. That should be about it, right? I've fixed fdiv and isnormal
<karolherbst>
afaik yes
<jekstrand>
Woo#
<jekstrand>
!
<karolherbst>
I am sure piglit will find more stuff
<jekstrand>
At some point, I should actually attempt to review the rusticl code
<karolherbst>
but that's probably tons of API validation bugs
<karolherbst>
have fun :P
<karolherbst>
although if you want to look at it, the nir pass stuff could need help
<karolherbst>
I just put something which isn't terribly slow and doesn't crash
<karolherbst>
but you might have better ideas on how to order/do things there
<jekstrand>
Yeah. I suspect we're going to want to do a bunch of tweaking before we call it ready
<jekstrand>
I've just not really looked at any of it since banging my head on Arc
<karolherbst>
although I figure that function calling is like the biggest thing left
<jekstrand>
For sure
<karolherbst>
besdies that: waiting for bug reports or so
<daniels>
jekstrand: Windows is badly backlogged; the GSt people who maintain it think it’s a machine-specific issue rather than structural. we’re trying to provision more either way but stuck in a bit of a Kafkaesque maze trying to find who can fix my account to be able to get more license keys …
<karolherbst>
icecream95: yeah.. although I was more thinking about weirdo bugs with weirdo printf format strings
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #dri-devel
nchery has joined #dri-devel
<icecream95>
karolherbst: It would be helpful to have any printf code in a place where other things can use it, for example I've found printf useful for debugging driver-internal compute shaders, or even using NIR passes to add printf to vertex shaders
<karolherbst>
yeah
<karolherbst>
that's what I am doing
<karolherbst>
just without the runtime hooked up
ppascher has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Wally has joined #dri-devel
ybogdano has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit []
rkanwal has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
Wally has quit [Remote host closed the connection]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
HankB__ has quit [Remote host closed the connection]
sdutt has quit [Read error: Connection reset by peer]
HankB__ has joined #dri-devel
HankB__ has quit [Remote host closed the connection]
HankB has joined #dri-devel
alanc has quit [Remote host closed the connection]