jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
boistordu has joined #dri-devel
boistordu_old has quit [Ping timeout: 480 seconds]
xp4ns3 has quit []
xp4ns3 has joined #dri-devel
zrusin has quit [Remote host closed the connection]
txenoo has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
drawat_ has joined #dri-devel
drawat has quit [Ping timeout: 480 seconds]
txenoo has joined #dri-devel
libv has joined #dri-devel
libv_ has quit [Ping timeout: 480 seconds]
shankaru1 has joined #dri-devel
aravind has joined #dri-devel
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
<jekstrand>
airlied: I could believe it. I could also believe if you'r scalarizing everything that TRex would be slower.
<jekstrand>
airlied: I see two options: 1) Stop scalarizing entirely in st_glsl_to_nir and let brw_nir do it for you or 2) make the st_glsl_to_nir scalarization stuff per-stage or at least separate FS/CS from the vertex pipeline.
<jekstrand>
airlied: Or maybe crocus_get_compiler_options is doing something wrong?
<airlied>
jekstrand: that code is only scalarising the fp64 instr
xp4ns3 has quit [Quit: Konversation terminated!]
<airlied>
it just happens to scalarise some b32anys and then the backend chokes
<airlied>
I just compared shaders between 965 and crocus for the looping forever
<jekstrand>
airlied: Uh, what? Is it scalarizing fp64 b32anys?
<airlied>
yup, since it just searchs for any instructions with src/dst fp64
<jekstrand>
And what's re-combining them?
<airlied>
nothing
<jekstrand>
So why is it infinite looping?
<airlied>
the vec4 backend ra isn't somewhere I know how to answer that question
<jekstrand>
Oh, it's blowing up in RA?
<airlied>
yup
<jekstrand>
airlied: Is airlied/crocus still the right branch?
* jekstrand
builds
<airlied>
jekstrand: should work or airlied/crocus-initial-submit
<airlied>
but they are mostly the same code
<jekstrand>
What test blows up?
<airlied>
just run KHR-GL45.enhanced_layouts.varying_locations and watch the cpu burn
<jekstrand>
Uh oh....
* jekstrand
thought he already fixed fp64 spilling. :-/
<airlied>
yeah I'm guessing this is in a similiar area
<jekstrand>
probably just need moar
<airlied>
bleh both 965 and crocus fail KHR-GL45.gpu_shader_fp64.builtin.mod_dvec*
<jekstrand>
It's been a while since we did GL 4.6 conformance on HSW
anholt has quit [Remote host closed the connection]
<airlied>
not sure anyone did 4.6 but it has 4.5 but fails a few tests with the latest gl cts
<danvet>
agd5f_, [PATCH] drm: fix doc warnings in drm_atomic.h <- I guess this is in some amdgpu patch?
<danvet>
also looks like sneaking in a new helper in an commit with drm/amd/display: subject :-)
<thellstrom>
daniels: Thanks.
Hakuchi has joined #dri-devel
Hakuchi has quit [Remote host closed the connection]
bezaban has joined #dri-devel
bezaban has quit [Remote host closed the connection]
Lightkey has quit [Ping timeout: 480 seconds]
itoral has quit []
Lightkey has joined #dri-devel
<kusma>
mareko_: I'm debugging some PBO failures, and discovered that st_pbo always copies through floats, even when copying integer data... Is that really a good idea? I would imagine integer-values that are signaling NaNs could get modified while copying...
pinchart1 has left #dri-devel [#dri-devel]
pinchartl has joined #dri-devel
AAA_awright has joined #dri-devel
AAA_awright has quit [Remote host closed the connection]
Dylanger has joined #dri-devel
<Dylanger>
Hey all, does anyone know how to get better debugging when dealing with virgl?
krendoshazin has joined #dri-devel
krendoshazin has quit [Remote host closed the connection]
earthnative23 has joined #dri-devel
earthnative23 has quit [Remote host closed the connection]
mjorgensen has quit [Remote host closed the connection]
<kusma>
Dylanger: tried using vtest?
<Dylanger>
Not yet, googles vtest
<karolherbst>
so uhm... I am seeing a weirdo 1920x1200 mode and I am not sure if that's nouveau doing weirdo stuff or if there is some code adding whatever default modes it thinks is right to add. Anybody any ideas?
<kusma>
Dylanger: It's a way where you run both the "guest" and the "host" on the same machine (e.g no virtual machine needed)
<kusma>
Dylanger: Also note that it looks like you've found a crash in the hypervisor, if this happens on a production system, you *might* have a CVE at hand...
<kusma>
I mean, a way of triggering a crash in the hypervisor.
drawat_ has quit []
drawat has joined #dri-devel
akrosi has joined #dri-devel
akrosi has quit []
vivijim has joined #dri-devel
<alyssa>
" Invalid format used but glCopyTexImage2D succeeded"
<alyssa>
This seems like a mesa/st bug..
<ccr>
Error: Success [ OK ]
sdutt has joined #dri-devel
<alyssa>
( that was KHR-GLES3.packed_pixels.rectangle.rgba8 )
<alyssa>
I'm only mostly sure I'm falling over a mesa/st bug
<pq>
Lucky you having conformance test suites to begin with. I envy you. :-p
* zmike
stops writing the tests that the drivers have to pass for a moment
<zmike>
huh?
<alyssa>
:<
* pq
is a Wayland dev with no such luxury.
<danvet>
airlied, [PATCH] drm/i915: Add relocation exceptions for two other platform <- ack on v2?
<danvet>
dt9, ^^ you need to ping for acks or it wont happen :-)
hch12907_ has joined #dri-devel
hch12907 is now known as Guest729
hch12907_ is now known as hch12907
Guest729 has quit [Ping timeout: 480 seconds]
hch12907 has quit [Remote host closed the connection]
pekkari has quit [Read error: Connection reset by peer]
hch12907 has joined #dri-devel
hch12907_ has joined #dri-devel
hch12907 is now known as Guest731
hch12907_ is now known as hch12907
Guest731 has quit []
pekkari has joined #dri-devel
<danvet>
tzimmermann, so vgem conversion to shmem helpers goes boom because we're not using wc anymore
<danvet>
I guess that means I need a drm_driver->gem_create_object hook?
<danvet>
I'm kinda lost what's the pretty way to do this now
pekkari has quit [Remote host closed the connection]
kode54 has joined #dri-devel
kode54 has quit [Remote host closed the connection]
vxn has joined #dri-devel
vxn has quit [Remote host closed the connection]
ajmcmiddlin has joined #dri-devel
<zmike>
robclark / Kayden: how interested would either of you be in becoming guinea pigs for testing tc buffer rebind api while marek's busy? the zink impl prob won't be mergeable for a long time, but I'd like to get the tc part in if someone else wants to do an impl
ajmcmiddlin has quit [Remote host closed the connection]
agd5f_ has quit []
agd5f has joined #dri-devel
<agd5f>
danvet, for "drm: fix doc warnings in drm_atomic.h" I think I applied it to the amdgpu tree rather than the drm-misc tree by accident. Didn't notice until it was too late
<robclark>
zmike: what is the MR? I can take a look, but freedreno already does rebind stuff internally (kinda needs to to function without TC).. got some other stuff on my plate so not sure how quickly I'll get to it, but I can at least take a look
<danvet>
agd5f, you cant apply it to drm-misc
<danvet>
because the commit that needs fixing is in amdgpu only I think
<danvet>
well probably soon in drm-next
idr has joined #dri-devel
<agd5f>
danvet, maybe I'm thinking of a different patch
<zmike>
robclark: top 2 patches in my test branch should give an idea; this doesn't remove the need to have internal rebinding functional, it just provides an optimized path for doing rebinds associated with buffer replacement
<danvet>
agd5f, well I don't have the referenced Fixes: tag
mbrost has joined #dri-devel
<danvet>
nor that macro in drm-misc
<danvet>
I'm also not seeing the reference amd/display commit on either amd-gfx nor dri-devel (should have been cc'ed there)
<danvet>
I guess it went directly into your tree and then got picked up by people looking at linux-next?
<agd5f>
oh, nevermind, different patch
<danvet>
or maybe the patch is just confused, I have no idea
<tzimmermann>
danvet, but isn't vgem entirely in software? why would it need map_wc?
ngcortes has joined #dri-devel
tango_ is now known as Guest742
tango_ has joined #dri-devel
Guest742 has quit [Ping timeout: 480 seconds]
mlankhorst_ has quit []
<danvet>
tzimmermann, because we use it to test sharing with real drivers
<danvet>
and vgem doesn't have a begin/end cpu access ioctl
<danvet>
so we can't flush
<danvet>
hence must be wc
<danvet>
tzimmermann, uh that's convoluted subclassing fun, but will adjust
<anholt>
yeah, vgem would be so much more useful if it was wc
<danvet>
anholt, it is
<danvet>
anholt, you're on a pretty old kernel if you have wb vgem
<anholt>
we were struggling with that in cros for a a while, glad to hear it's been fixed
<danvet>
anholt, might this be mmap on the dma-buf fd?
<danvet>
there you have to use the cache control ioctl
<anholt>
unsure, would have to go dig up those old tests. I think we retired them because it was only ever finding that the caching was busted.
soreau has quit [Quit: Leaving]
soreau has joined #dri-devel
blue__penquin has quit [Remote host closed the connection]
erkoztra123s has joined #dri-devel
erkoztra123s has quit []
internut has joined #dri-devel
internut has quit [Remote host closed the connection]
<robclark>
anholt, danvet: iirc the issue was mmap and lack of flushing.. not sure if that has changed since v5.4? I've been kinda ignoring that because the vgem test won't be able to surface any actual hard issues and instead wastes a lot of peoples time surfacing fake issues (ie. cache)
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
gouchi has joined #dri-devel
mulbc has joined #dri-devel
mulbc has quit [Remote host closed the connection]
baudehlo__ has joined #dri-devel
baudehlo__ has quit [Remote host closed the connection]
deltasquared has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
<deltasquared>
bnieuwenhuizen, HdkR, neobrain: little update on that graphical heart attack... so it seems it was one of those cases where a kernel update had happened but I hadn't rebooted yet. in-between 5.12.5 and .8 (.7 in particular I think) there had been some notable bugfixes in amdgpu, around gpu-side virtual memory stuff in particular (which might explain why the graphical corruption was managing to
<deltasquared>
trash other users/applications on the system). it has however been completely fixed AFAICT. so I guess, no bug report, only a "read this if you're on stable kernel < 5.12.7" warning to others somewhere heh...
<deltasquared>
well, at least assuming I'm reading the changelogs right anyway.
Daanct12 has joined #dri-devel
pekkari has quit []
Danct12 has quit [Ping timeout: 480 seconds]
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
mareko_ is now known as mareko
<mareko>
kusma: where does it use floats?
<mareko>
zmike: does it handle rebinds with multiple contexts?
libv_ has joined #dri-devel
<zmike>
mareko: no, it just uses the binding info that tc has to provide drivers with exact rebind info so they don't have to loop randomly to find it
<zmike>
so now instead of calling si_rebind_buffer from si_replace_buffer_storage, you just directly update the rebind
libv has quit [Ping timeout: 480 seconds]
pastly-antispam has joined #dri-devel
<mareko>
zmike: that should be fine for tc, but we can't use it because other contexts still need to rebind
<zmike>
there's no existing code for handling multi-context rebinds though?
<mareko>
radeonsi has one
<zmike>
where is this?
<mareko>
zmike: the last block in si_rebind_buffer
<zmike>
huh
<mareko>
other contexts rebind all buffers, not just one buffer
<zmike>
so I see
<mareko>
The main problem with tc is that other contexts can't rebind buffers so easily because tc would have to pass the old ID and new ID to all other contexts. Drivers can do it because they can just bind the same pipe_resource again.
<zmike>
right...
<zmike>
I think it should be fine to use this rebind thingy and then drivers can also determine if they want to flag other contexts for rebinds on top of that
<mareko>
sure
<mareko>
tc is already inconsistent with multiple contexts because invalidating a buffer in one context doesn't update the bound ID in another context, so buffer lists are inaccurate
<zmike>
yes, I saw this comment
<zmike>
I think perhaps that might be what required me to revert my driver_calls_flush_notify usage
<mareko>
I doubt it
<zmike>
I didn't spend much time investigating, but it seemed like a multi-context type thing
<mareko>
what's the affected app?
<zmike>
tomb raider
<zmike>
the only app I run these days
<mareko>
that app is CPU-bound on the app side here, not the driver side, so it can't be made faster
<zmike>
I was talking about driver_calls_flush_notify being broken with it
<mareko>
I know
<mareko>
the mitigation would be to disable tc busyness tracking if there are multiple contexts
<zmike>
I tried that, but it was just the flush notify that was causing the problem
<zmike>
...the problem being that it started to hang at the title screen
<mareko>
tomb raider works fine with radeonsi
<zmike>
I'd expect that to be the case
<zmike>
the reference driver has to work or else I have nothing to steal code from
<bl4ckb0ne>
what's going on with the ci i915-g33? i keep getting 403 when I try to replay
<bl4ckb0ne>
i'm tryingto upgrade the vk.xml file and i got failures on gl stuff
<kusma>
mareko: the fragment shader uses float samplers and images
<kusma>
See !11164...
hikiko has quit [Remote host closed the connection]
neonking has joined #dri-devel
hikiko has joined #dri-devel
<mareko>
kusma: is it just a difference in the type that the shader declares? AMD hw doesn't use the type declared in the shader, which is why we haven't noticed this
alyssa has left #dri-devel [#dri-devel]
<kusma>
mareko: it also makes the sampler return the right value types as well
<mareko>
the return type is also not used
mdnavare has joined #dri-devel
<kusma>
Makes sense then
<danvet>
robher, sorry for the pl111 thing, unfortunately non-rebasing drm-misc and all that :-(
<robher>
danvet: if only there was a way to undo commits...
<danvet>
robher, well revert
<danvet>
but I guess Kees will send in a real fix
<danvet>
also I need an ack for a revert
wMw has joined #dri-devel
<robher>
ack
wMw has quit [Remote host closed the connection]
<danvet>
robher, did you actually compile test that the config you think exists still works?
<danvet>
from what I can see looking at the code Kees report is correct, that thing wont compile
<robher>
danvet: You mean whether IS_ENABLED() avoids undefined references?
<danvet>
I guess depends upon gcc and optimizer
<robher>
I thought that was the assumption. If it doesn't, I've broken a lot of things...
<mdnavare>
airlied: emersion:imirkin: How can I measure the fps with DRI PRIME glxgears when its using dgpu as the render target now ?
<imirkin>
GALLIUM_HUD=fps ?
<emersion>
it should print fps in the terminal?
<emersion>
something like "302 frames in 5.0 seconds = 60.313 FPS"
<emersion>
each 5s
<mdnavare>
emersion: when I run glxgears it should just print on the screen?
<bnieuwenhuizen>
the terminal where you run it
<emersion>
start glxgears from a shell
<mdnavare>
so DRI_PRIME = 1 glxgears
Steps[m] has joined #dri-devel
<emersion>
without spaces! :P
<emersion>
DRI_PRIME=1 glxgears
Steps[m] has quit [Remote host closed the connection]
shankaru1 has quit [Remote host closed the connection]
deltasquared has quit [Quit: leaving]
<mdnavare>
emersion: thanks Simon, got it but its like 5500 frames in 5 secs
<mdnavare>
emersion: On a really tiny screen
tzimmermann has quit [Quit: Leaving]
lemonzest has quit [Quit: Quitting]
asdf has joined #dri-devel
hunger[m] has joined #dri-devel
asdf has quit []
hunger[m] has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-03 20:40:53)]
fro has joined #dri-devel
fro has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
<ajax>
zmike: talk to me about #4859. i think i know what you're asking for but i want to be sure.
<zmike>
cc Plagman ^
<ajax>
zmike: you're not saying literally block at the end of SwapBuffers until you have a firm grip on the new back buffer, right?
<zmike>
I'm not entirely clear on it, I just thought you'd be someone in a position to comment and ask important questions like these
<zmike>
possibly also JoshuaAshton
<ajax>
so hisorically SwapBuffers tends to return as soon as it can, up to and including before the swap even happens, and deferring fb validation to the next gl command, because that way the cpu's work for the next scene can proceed immediately
<ajax>
but i mean, we have threads, now. we could start fb validation as early as before SwapBuffers returns and await the replies for it asynchronously, and just wait for the thread to signal if you get to Clear before the events/replies come back
<ajax>
and you maybe want to start validation at a particular ust, so maybe you want some control over when that validatin starts.
Daanct12 has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: I will try to get the contiguous patches reviewed! It's on my list. Really!
ledeni has joined #dri-devel
ledeni has quit [Remote host closed the connection]
<anholt>
thanks!
alyssa has joined #dri-devel
<alyssa>
craftyguy: You rung?
<alyssa>
?
<craftyguy>
ah, I sent you a DM earlier
<JoshuaAshton>
ajax: Essentially it's, if SwapBuffers should be blocking, it should be blocking after the buffers have been swapped
<alyssa>
craftyguy: (I block PM's due to people abusing them.)
<JoshuaAshton>
In Vulkan, we present immediately when the app asks us to, then kick off an acquire for the next presentation immediately after
ngcortes has quit [Remote host closed the connection]
<JoshuaAshton>
*In Vulkan terms
<ajax>
JoshuaAshton: s/after/until after/ i assume
<JoshuaAshton>
Hmmm, no
<JoshuaAshton>
Sorry my Internet is dying
<JoshuaAshton>
Didnt get a chance to finish what I was writing
<JoshuaAshton>
So right now in Mesa, Vulkan WSI is blocking, so we Present then acquire the next image (which blocks until that is acquired)
<JoshuaAshton>
If it wasn't blocking, we'd Present, kick off the acquire, and wait on semaphores before next present
<JoshuaAshton>
I assume in GL, you could just do similar in which you Present, then wait until the next image is acquired in SwapBuffers
<JoshuaAshton>
Additionally, if we could make acquiring non-blocking, on our end we wait on the semaphores for the image acquire for our next blit + present
<JoshuaAshton>
Sorry if this is kinda non-coherent, I suck at explaining things ^^
<JoshuaAshton>
I guess the latter wouldn't work if you don't have a virtualized swapchain (we are kinda required to right now.)
<JoshuaAshton>
so you'd need to block either way if you render directly to the images you get from acquire
<ajax>
we can certainly make SwapBuffers block until whatever you like
<ajax>
so you're saying the "if it wasn't blocking" case for vulkan is what you would prefer, and not what is currently happening. and all discussion of gl is functionally make it work like you'd like vulkan to work.
<JoshuaAshton>
Nah that was just an aside
<JoshuaAshton>
it being blocking on the host is fine I guess...
<JoshuaAshton>
I don't think that would matter in the non-virtualized case
<ajax>
forgive me, virtualized?
<JoshuaAshton>
Where you have a set of user buffers and blt before present
* alyssa
reads cwabbott 's SSA ir3 code
<ajax>
well
<jekstrand>
alyssa: Good luck!
<ajax>
there's always the option of calling glClear right after glXSwapBuffers to force validation to happen
<alyssa>
jekstrand: Correction:
marcheu_ has quit []
* alyssa
reads Boissinot et al
<alyssa>
:-p
<ajax>
but i also like the idea of async validation
<bnieuwenhuizen>
ajax: taking another stab at it since it feels people are talking along each other, feel free to interrupt if that is not the case. But the goal is reducing latency between input and present. under the assumption that a main loop is swapbuffers -> read input -> draw -> swapbuffers, waiting in the first draw would cause the input->present latency to increase while blocking at the end of the swapbuffers wouldn't
<jenatali>
Indeed. Frame throttlers on Windows all put a wait after presenting
<bnieuwenhuizen>
of course if you rotate between to few buffers it can results in the GPU being partially idle so there is a tradeoff
<ajax>
okay, that helps. the interval we're minimizing is between last user input and presenting the frame.
pzanoni has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
iive has quit []
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pcercuei_ has quit []
neonking has quit [Remote host closed the connection]
<jekstrand>
anholt: There you go. Two more comments to clean up and I'll RB the "fun" patch. :)
<jekstrand>
anholt: Sorry that took two months. :-(
<anholt>
could we just gc the serialization code? Do we anticipate using it ever?
<jekstrand>
anholt: We could. IBC uses it. If that ever lands.....
<jekstrand>
That said, with the new stuff, maybe IBC doesn't need offline RA setup?
<anholt>
that's what I'm hoping
<jekstrand>
IBC also has a concept of strided registers. I'm not sure those fit in the contiguous model.
* jekstrand
is hoping he left himself good enough comments to remember how this all works
<anholt>
if you have strided as in an allocation actually skips over space and you want to represent that, then you don't get to do this.
<anholt>
we could possibly do that "but I don't wanna" part for the interaction between contig- and non
<anholt>
but also I hope that you some day take on ssa RA.
<anholt>
we're just switching freedreno to it now.
<jekstrand>
I'd like to one day
<jekstrand>
But I'd like to do a lot of things "one day"
<jekstrand>
For now, if you want to dead code the serialization stuff, go for it. We can rewrite it or revert and update when we rebase IBC.
<jekstrand>
But, yeah, I think the strided stuff doesn't work
JimRM has joined #dri-devel
JimRM has quit [Remote host closed the connection]
<jekstrand>
In IBC, we represent our register file as 4096 1-byte registers.
<jekstrand>
Most stuff is contiguous but we can allocate g7<2>w and g7.1<2>w separately
<jekstrand>
And those two don't conflict. One is XX__XX__XX__XX__ and the other is __XX__XX__XX__XX
<jekstrand>
It's not utterly terrible to manually do the q-value setup but, dang, it's so nice with the contiguous stuff!
<jekstrand>
When I actually read and groked the Intel patches, I was shocked at how much better they make RA setup.
<alyssa>
anholt: Do you think SSA-based RA is worth it?
<anholt>
honestly getting rid of a set of mappings was the best part to me
<alyssa>
(Compared to the time investment to bring up)
<anholt>
alyssa: yes yes yes do not use my graph coloring allocator.
<anholt>
it's a bunch of typing, but you get to copy-and-paste a ton of it
<anholt>
(sigh, C)
<alyssa>
lol your graph colouring allocator i use a greedy O(n^3) constraint solver in 200 lines of code that does better on vector backends than util/ra but if you have to spill heaven help you
<alyssa>
for a scalar backend, util/ra sounds pretty decent by comparison :'p
<jekstrand>
Honestly, if we could switch IBC to SSA and figure out SSA-based RA, I think that'd make it enough better to finish up and land.
<jekstrand>
But first someone has to find time to do all that.
<airlied>
I thought intel hw didn't suit itself to ssa-based RA
<jekstrand>
It really badly doesn't
<jekstrand>
But graph coloring is aweful
<alyssa>
airlied: I thought that about Bifrost, but then I realized I was just compiling for Bifrost wrong.
<jekstrand>
There are cases where IBC's (mostly correct, AFAICT) register pressure estimator in the scheduler predicts that it's using only about 30-40% of the register file and we still fail RA.
<anholt>
I thought so too until I saw how the coalescing works out for splits/collects in ir3
<jekstrand>
I think I need to just bite the bullet and switch IBC to SSA and see how it works out.
<alyssa>
likewise for bifrost I guess
<alyssa>
and I wanted to do SSA for AGX anyway but also right now my "RA" is "ssa ? nir_ssa->index : nir_reg->index + 96" ;
<alyssa>
;P
<alyssa>
Somehow doing no RA whatsoever is enough to pass >90% of dEQP-GLES2
<jekstrand>
alyssa: With a big enough file, you can get a long ways with YOLO RA
dos1 has quit [Quit: Kabum!]
dos11 has joined #dri-devel
<alyssa>
srs
illwieckz has quit []
<alyssa>
I /am/ definitely a convert to setting (kill) bits on sources during liveness analysis and then colouring in linear time
<alyssa>
which afaiu ir3 does
illwieckz has joined #dri-devel
<alyssa>
but you don't actually need full SSA-based RA for that, you can do it on the output of nir_from_ssa as long as you avoid nir_registers
* airlied
just found a copy of compilers principles, techniques & tools 2nd ed, I should probably keep quite until I read some of that :-P
<alyssa>
(and then do nir_registers in a separate pass)
dos11 has quit [Remote host closed the connection]
dos1 has joined #dri-devel
<alyssa>
The patches for doing that are much, much simpler than handling out-of-SSA yourself
<Sachiel>
I suspect reading that will make you want to keep quiet even more
dos1 has quit []
<alyssa>
OTOH if you don't know how to go out-of-SSA are you really a compiler dev yet?
* alyssa
is not really a compiler dev yet
dos1 has joined #dri-devel
<airlied>
I've long since resigned myself to not being a compiler developer, after brief forays into gcc and llvm and now nir
<jekstrand>
alyssa: IMO, out-of-SSA is black belt stuff.