ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
_whitelogger has joined #dri-devel
go4godvin has quit [Server closed connection]
go4godvin has joined #dri-devel
go4godvin is now known as Guest563
wens has quit [Server closed connection]
wens has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
cheako has joined #dri-devel
a has joined #dri-devel
a has quit []
ameerj has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
iive has quit []
<ameerj>
Hello all, I'm a developer on the yuzu emulator project. I need assistance debugging a device loss on the RADV driver with RDNA2 hardware that causes a driver panic
pcercuei has quit [Quit: dodo]
<HdkR>
ameerj: Do the validation layers say anything?
Tooniis[m] has quit [Server closed connection]
Tooniis[m] has joined #dri-devel
<HdkR>
I don't recall if gfxreconstruct helps with debugging device lost
chema has quit [Server closed connection]
<ameerj>
validation layers don't say anything near when the hang/crash occurs
chema has joined #dri-devel
MatrixTravelerbot[m] has quit [Server closed connection]
<ameerj>
I was able to dump the hang using $RADV_DEBUG=hang but not I'm sure how to make use of the dumped info
MatrixTravelerbot[m] has joined #dri-devel
<pendingchaos>
otherwise, I think RADV_DEBUG=hang is mostly useful for those who are very familiar with radv or the hardware
<pendingchaos>
pipeline.log should have the spir-v of the hanging shader, if it's a shader that's causing the issue
<pendingchaos>
never used this, but it looks like it might be useful and would give a higher-level information on the hang: https://github.com/googlestadia/gfr
apinheiro[m] has quit [Server closed connection]
apinheiro[m] has joined #dri-devel
dcbaker has quit [Server closed connection]
dcbaker has joined #dri-devel
<pendingchaos>
I think radv does something similar to gfr and dumps it into trace.bo, but figuring out the corresponding vulkan commands would probably be difficult
<ameerj>
Interesting, I'll set up GFR and hope it provides me with better indication as where the problem lies. Thanks pendingchaos!
<JoshuaAshton>
ameerj: This couldn't be the one I am debugging right now is it?
<JoshuaAshton>
:D
<JoshuaAshton>
Mine is a full hang that only occurs when VK_EXT_vertex_input_dynamic_state is enabled
<JoshuaAshton>
Right now I am trying to narrow it down to the right instruction with umr stuff and having a jolly old time :frog:
ella-0[m] has quit [Server closed connection]
ella-0[m] has joined #dri-devel
<JoshuaAshton>
My first UMR stuff was pointing PC_LO to something wacky so I am trying again with some other stuff
<JoshuaAshton>
if I make it not use it or disable it in RADV, it works fine
<pendingchaos>
vertex prologs use s_setpc_b64 to jump to the main shader, so maybe the address given there is wrong for some reason
<JoshuaAshton>
Based on my first UMR stuff, looks like the PC was somewhere invalid when it hung, but it could just be UMR giving me back BS so that's what I am testing now
<JoshuaAshton>
notably it doesn't have on Radeon VII (Vega20)
<pendingchaos>
if the instance rate divisor is not 1, then it will take a more complex path to obtain the address
<pendingchaos>
I'm not sure how well that path is tested
xerpi[m] has quit [Server closed connection]
xerpi[m] has joined #dri-devel
<ameerj>
JoshuaAshton: Indeed it is the same one you're debugging, and looks like your much further along than i am xD
<imirkin>
hm, i guess spec@amd_performance_monitor@measure,UnexpectedPass needs to be added to flakes for intel?
<JoshuaAshton>
Currently doing a kernel build with CONFIG_STRICT_DEVMEM=n because UMR was bitching at me
<JoshuaAshton>
> <pendingchaos> vertex prologs use s_setpc_b64 to jump to the main shader, so maybe the address given there is wrong for some reason
<JoshuaAshton>
That sounds like it could very likely be a culprit if this is the cause
<JoshuaAshton>
given that it works fine on the simple like splash screen and stuff
<JoshuaAshton>
but as soon as more complex scenes come up, it hangs
<bnieuwenhuizen>
I'm curious though because in the example it hung at the address of PC_LO which sounds like it hangs in the prolog shader
Net147 has quit [Server closed connection]
Net147 has joined #dri-devel
<bnieuwenhuizen>
rather than a weird jump from the prolog shader
<JoshuaAshton>
bnieuwenhuizen: PC_LO didn't seem to be in the prolog shader though did it? Can double check with this new kernel + umr wave + radv dumps anyway I hope
<bnieuwenhuizen>
oh right nvm
<bnieuwenhuizen>
it was in SPI_SHADER_USER_DATA_GS_0
<JoshuaAshton>
ye
<bnieuwenhuizen>
was thinking of the GS start address, which does need to point to the prolog
<bnieuwenhuizen>
kinda weird though. GS_0 is IIRC also where we store the address to all the scratch/tess/etc rings
<bnieuwenhuizen>
so if a shader starts using that that will get messy
<JoshuaAshton>
GS being geometry shader or?
<bnieuwenhuizen>
yeah
<bnieuwenhuizen>
though with NGG a VS gets implemented as GS
<JoshuaAshton>
Not sure on the interaciton with NGG + prologs and stuff there
<JoshuaAshton>
ah
<bnieuwenhuizen>
so likely yuzu has a VS, and on the HW GS is the first stage
<pendingchaos>
I think the ring address is in SPI_SHADER_USER_DATA_ADDR_LO_GS, not GS_0
<JoshuaAshton>
I wonder if its worth me just forcing non-trivial divisors off (rendering be damned) to smoke that out immediately
<JoshuaAshton>
that would narrow that down quickly
<bnieuwenhuizen>
oh right, always forget we have that special one on GFX9+
<ameerj>
JoshuaAshton: do you think it would make sense for the time being for yuzu to blacklist RADV RDNA2 drivers from using VK_EXT_vertex_input_dynamic_state while a proper fix is being investigated?
<JoshuaAshton>
we should probably make a big wiki page about umr and debugging hangs and stuff at some point
<JoshuaAshton>
ameerj: Sure, probably makes sense to
<JoshuaAshton>
ameerj: Not surprising! :D
<JoshuaAshton>
hmmm I disabled nontrivial_divisors and it still hangs
<JoshuaAshton>
okay back to UMR!
The_Company has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
pendingchaos: looks like s_setpc_b64 in the hung pipeline (according to RADV_HANG) is just from s[8:9], there's no waitcnts so seems like trivial divisor?
<karolherbst>
jekstrand: okay.. I think I succeeded :) without even having to change the code except my super macro
pnowack has quit [Ping timeout: 480 seconds]
<karolherbst>
testing if I can really split out the bindgen CL stuff into its own crate tomorrow
<karolherbst>
but it should look fine
<karolherbst>
I just inserted three magic casts
<karolherbst>
and have a struct with only the dispatch table
<karolherbst>
but I also have ideas on how to minimize that macro
<jekstrand>
karolherbst: Yeah, I've got a few ideas of things I'd like to see too.
<jekstrand>
karolherbst: For one, I'd like to see us stop doing our own reference count and use an Arc for the wrapper
<karolherbst>
what do you mean?
<jekstrand>
And have core::Foo.cl be a Weak
<karolherbst>
we don't do our own ref counting
<jekstrand>
karolherbst: Yeah we do unless you've changed that
<karolherbst>
I never did my own ref counting except implmenting those CL functions changing some atomic
<jekstrand>
Yeah, that's what I'm referring to
<jekstrand>
Arc will do all that
<karolherbst>
well
<karolherbst>
no
<karolherbst>
it can't
<jekstrand>
why not?
<karolherbst>
how do you think it should work out?
<jekstrand>
Picking Device for a moment for an example...
<jekstrand>
We have a struct ObjectWrapper<Device> which has a dispatch table and an Arc<Device> or Arc<Mutex<Device>> (depending on if we want it to be mutable or not)
<jekstrand>
Then to get the cl_device_id, we create an Arc<ObjectWrapper<Device>> and call into_raw() on it to get a pointer.
<karolherbst>
mhhh.. planning to use increment_strong_count and decrement_strong_count?
<jekstrand>
Yup
<karolherbst>
mhhh
<karolherbst>
not a big fan of allowing clients to trash rust internals though :/
<jekstrand>
And decrement_strong_count() should delete it when it hits zero without having to do any "turn it back into a Box/Arc" nonsense
<jekstrand>
We're giving the client a pointer to a Box<>. How's that different?
<karolherbst>
we are giving it an opaque pointer
<karolherbst>
the only use of that is to pass it inside CL API functions
<jekstrand>
And we're blindly smashing an atomic relative to that pointer
<jekstrand>
The memory corruption is going to be the same
<karolherbst>
no
<karolherbst>
when the wrapper is gone we don't care
<karolherbst>
atm
<jekstrand>
Yeah, but if they release one too many times, we have no protection against that
<karolherbst>
oh well.. mhh I guess they could keep decrementing..
<jekstrand>
Yeah
<karolherbst>
mhh
<jekstrand>
I don't think your box trick is any differen than the implementaiton of Arc
<karolherbst>
there is another thing, which is that clients can ask for the ref count
<jekstrand>
And one of the advantages to using Arc is that we can have our device.cl back-pointer be a Weak and it'll automatically null when the client deletes the object.
<karolherbst>
but.... I hope no clients is doing "decrement by the ref count" crap
Karyon has quit [Server closed connection]
Karyon has joined #dri-devel
<jekstrand>
Short of mapping all their objects through a hash table, we can't protect against too many decrements
<karolherbst>
yeah.. I mean, we can just ignore crappy apps and move on
<karolherbst>
I can play around and see if that would work
<karolherbst>
should be a trivial change
<jekstrand>
If we want to protect against crappy apps, we need a HashMap per handle type.
pnowack_ has quit []
<karolherbst>
I think some impls actually store the type besides the dispatch table...
<karolherbst>
not sure if clover does
<karolherbst>
but I think there is some magic
<jekstrand>
I also thought about doing that
<karolherbst>
me as well
<jekstrand>
Rust enums would work well for that
<karolherbst>
yeah
<jekstrand>
I was also looking at Any. Not sure how that works just yet, though.
<jekstrand>
If we did that, I think we could have a single standard wrapper class without the generic parameter.
kurufu has quit [Server closed connection]
kurufu has joined #dri-devel
<jekstrand>
I think that'd add us a bit of nice protection
<karolherbst>
maybe
<jekstrand>
If the dispatch table is ours, it doesn't guarantee that it's our object, but it's as close as we'll get. THen the enum protects us from bad pointer casts in the client.
<karolherbst>
yeah
<jekstrand>
I'm going to prototype some things on Monday. Part of my problem today is that refactoring is hard because you've gotten far enough that any change has a lot of changes before it builds.
<jekstrand>
So I may strip it down to just Device or something and then experiment.
ishitatsuyuki has quit [Server closed connection]
ishitatsuyuki has joined #dri-devel
<karolherbst>
well.. I am close to done with my changes anyway
<jekstrand>
karolherbst: How immutable are the objects? Is basically everything mutable or is there some stuff that we expect to create once and never change? Like images, maybe?
<karolherbst>
just some
<imirkin>
i missed the start of this ... what are you guys hacking up?
<jekstrand>
karolherbst: Yeah, go ahead and finish up what you're doing. Don't worry about conflicting with me.
<karolherbst>
cl_programs are mutable for real
<jekstrand>
imirkin: A new OpenCL state tracker written in Rust.
<karolherbst>
the other things? mhh
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: keep in mind that mutable doesn't mean we need &mut refs
<jekstrand>
karolherbst: Yeah, Images, memory, buffers, etc. are probably immutable.
<karolherbst>
kernels as well
<jekstrand>
karolherbst: Yeah. Just wondering what all we need to wrap in Mutex
<karolherbst>
kernels are explicitly not thread safe
<karolherbst>
so we can trash
<jekstrand>
Right
<karolherbst>
or just fail randomly
<karolherbst>
cl_program might be the first one really needing a lock
<karolherbst>
maybe even the only one
<jekstrand>
Right so, for that, we could use get_mut() and just throw an error if it's used concurrently or something.
<karolherbst>
yep
<karolherbst>
ohh cl_queue is mutable
<jekstrand>
I'd like as little mutex and mut as possible
<karolherbst>
but I wanted to use atomic containers
<karolherbst>
because you get heavy threading on those anyway
<jekstrand>
atomic containers?
<karolherbst>
containers which use atomic ops instead of requiring &mut refs
<karolherbst>
there are some crates
<jekstrand>
Yeah
<jekstrand>
Often taking a mutex is faster than a few atomics if the mutex is implemented right.
<karolherbst>
queues are weird, but probably the only type of objects who are mutable for a reason
<karolherbst>
cl_programs are mutable because of bad API design
<jekstrand>
sure
<karolherbst>
jekstrand: maybe there is something like simple_mtx_t in rust :D
* karolherbst
already see us writing it ourselves
<jekstrand>
karolherbst: I would expect Mutex is basically that on Linux
<jekstrand>
But I don't know
<karolherbst>
it's not afaik
<jekstrand>
There shouldn't be any recursion with Mutex so it could be
<karolherbst>
mhh
<karolherbst>
I know that RwLocks have some smartness inside
<karolherbst>
not sure for mutex
<jekstrand>
Yeah, RwLocks are going to be more expensive
<jekstrand>
Mutex can be cheap. Not sure if it is.
<karolherbst>
mhh
<karolherbst>
maybe
jbarnes has quit [Server closed connection]
jbarnes has joined #dri-devel
<karolherbst>
imirkin: OpenCL implemented in Rust within mesa
<jekstrand>
But, yeah, generally, I'd like to use Arc and keep it immutable as much as possible.
<jekstrand>
And I think we can for must things. I just don't know the API super well yet. Not in that level of detail.
<karolherbst>
should be fine
<karolherbst>
I implemented most of the stuff
<karolherbst>
already
<karolherbst>
not sure for new types like pipes and the like
<jekstrand>
Looking at clover, queues and events have mutexes. I'm not sure if we actually need them for events.
<karolherbst>
why for events?
<jekstrand>
I don't remember why. It has these CPU-implemented events where it does CPU waits, IIRC.
<jekstrand>
I don't think we want that.
<karolherbst>
I've made the status an atomic
camus1 has joined #dri-devel
<jekstrand>
That's probably enough.
<karolherbst>
looks like it at least
<jekstrand>
Or, better yet, we can use actual kernel sync primitives like sync_file and not do the userspace CPU stuff.
<karolherbst>
I am doubting it's really worth it... but maybe
<jekstrand>
idk
<karolherbst>
I mean.. Mutex are usually implemented with futex already anyway
<jekstrand>
?
<jekstrand>
I'm not sure we're talking about the same thing
<karolherbst>
ohh you were refering to events?
<jekstrand>
Yeah
ameerj has quit [Quit: Leaving]
<karolherbst>
mhh
<jekstrand>
For events, we may want to use sync_file or something and kick to the kernel. I've not studied them well enough to be sure that'll work, though.
<jekstrand>
If we want to get full perf on big GPUs, we're going to need to push as hard as we can to use all the parallelism.
<karolherbst>
yeah... I really didn't investigate all that waiting on event stuff anyway, not sure what we need and what's required
<karolherbst>
yeah
camus has quit [Ping timeout: 480 seconds]
<jekstrand>
Yeah, neither have I. I expect there's going to be some work to do there if we want full perf.
<karolherbst>
at least I push all events to a worker thread already
<karolherbst>
but there could be more workers with a bit of dep managing
<karolherbst>
but...
<jekstrand>
Yeah
<karolherbst>
all this mixing of CPU and GPU events is a mess to begin with
<jekstrand>
Yeah and I'll need to study the spec before I've got especially solid opinions on it.
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
we could just check what MS did :D
<jekstrand>
But I could imagine us wanting to spawn multiple queues on radeonsi and similar.
<jekstrand>
hehe. We could :)
<jekstrand>
Not sure how spawning multiple compute queues works with Gallium. (-:
<karolherbst>
you creeate a new context
demarchi has quit [Server closed connection]
demarchi has joined #dri-devel
<jekstrand>
That works, I guess.
<jekstrand>
But, yeah, we may want to do some context juggling. But we need to get things up and working and well enough tuned that that's the bottlekneck first.
adam_ has joined #dri-devel
<karolherbst>
it's a bit sad that the CL CTS is in such a sad state... normally I'd just get that passing and hope that applications only hit some werido corners cases, but no...
<jekstrand>
Yeah
ley has joined #dri-devel
thaytan has quit [Server closed connection]
thaytan has joined #dri-devel
ley_ has joined #dri-devel
<karolherbst>
ahh my stuff finally compiles :D
Luc has joined #dri-devel
Luc has quit []
bbrezill1 has joined #dri-devel
ley has quit []
cef has quit [Server closed connection]
<jekstrand>
karolherbst: \o/
cef has joined #dri-devel
<karolherbst>
only did it for cl_program for now, but now moving over everything :D
<karolherbst>
81 errors, but I know why and requires maybe 4 loc changes
<karolherbst>
jekstrand: you know what's the most annoying part about rust macros?
<karolherbst>
you can't create new idents...
<jekstrand>
:(
<karolherbst>
you can do with proc_macros though, but ugh....
<karolherbst>
proc_macros need their own create and are more like compiler plugins
<karolherbst>
and I am sure dcbaker will hate us if we ask for that :D
<jekstrand>
hehe
bbrezillon has quit [Ping timeout: 480 seconds]
ramaling has quit [Server closed connection]
ramaling has joined #dri-devel
<karolherbst>
jekstrand: okay.. ported everything over and no regressions :) so it seems to work
<jekstrand>
\o/
<karolherbst>
so tomorrow I will probably remove the atomic and split the crate and see how well that works
<jekstrand>
karolherbst: Save you a bit of effort. :)
<karolherbst>
:D
orbea has quit [Server closed connection]
camus1 has quit [Ping timeout: 480 seconds]
<karolherbst>
ehhh wait
<karolherbst>
jekstrand: is it even going to work?
orbea has joined #dri-devel
<karolherbst>
because the CL headers define that
<jekstrand>
karolherbst: yup. Works fine.
<karolherbst>
and I used '--blacklist-type', '_cl_command_queue' etc...
<jekstrand>
Yeah, just drop the --blacklist-type
<karolherbst>
oh wow :O
<karolherbst>
but that's invalid C
<jekstrand>
No it's not
<karolherbst>
ohhh right
<karolherbst>
those don't exist...
<jekstrand>
Yup. They're just predeclarations
<karolherbst>
right.. bindgen was adding those fake structs
<karolherbst>
yeah..
<karolherbst>
okay, that will be fun tomorrow then
<karolherbst>
jekstrand: we just need to be prepared to close all "please support non ICD execution" issues as wontfix :D
gnuiyl has quit [Server closed connection]
* karolherbst
doesn't see the point of even bothering with non ICD support tbh
<karolherbst>
mhh would be annoying if it's required for certification though
<karolherbst>
or conformance passing or whatever
<karolherbst>
mhh well I guess we can fill the table regardless...
<karolherbst>
oh well
<jekstrand>
idk about non-ICD
<jekstrand>
If we need to support that, we'll deal with that later.
<karolherbst>
yep... anyway.. the bed calls, good night
<jekstrand>
g'night
sagar__ has quit [Remote host closed the connection]
sagar__ has joined #dri-devel
tarceri_ has quit [Server closed connection]
tarceri_ has joined #dri-devel
kts has quit [Server closed connection]
kts has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
adam_ has quit []
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
dafna2[m] has quit [Server closed connection]
dafna2[m] has joined #dri-devel
mhenning has quit []
mbrost has joined #dri-devel
linearcannon has joined #dri-devel
reductum has quit [Server closed connection]
reductum has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
sagar__ has quit [Remote host closed the connection]
sagar__ has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
ley_ has quit [Remote host closed the connection]
SolarAquarion has quit [Server closed connection]
tdwebryv^ has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
SolarAquarion has joined #dri-devel
cheako has joined #dri-devel
andrey-konovalov has quit [Server closed connection]
sumits has quit [Server closed connection]
andrey-konovalov has joined #dri-devel
aravind has joined #dri-devel
mattrope has quit [Quit: Leaving]
imirkin has quit [Server closed connection]
imirkin has joined #dri-devel
Duke`` has joined #dri-devel
anholt has quit [Server closed connection]
anholt has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
mbrost has quit []
Guest563 is now known as go4godvin
bl4ckb0ne has quit [Server closed connection]
bl4ckb0ne has joined #dri-devel
mszyprow has joined #dri-devel
The_Company has quit []
kts has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
ifreund has quit [Server closed connection]
ifreund has joined #dri-devel
alanc has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
maxzor__ has quit [Ping timeout: 480 seconds]
eukara has quit [Server closed connection]
eukara has joined #dri-devel
mlankhorst has joined #dri-devel
danvet has joined #dri-devel
flto has quit [Server closed connection]
flto has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
lemonzest has joined #dri-devel
maxzor__ has joined #dri-devel
pnowack has joined #dri-devel
<JoshuaAshton>
pendingchaos: Dug down the rabbit hole a bit more
<JoshuaAshton>
PC_LO is 00703100
<JoshuaAshton>
which is the address after the jump call
<JoshuaAshton>
s_setpc_b64 s[8:9] ; be802008
<JoshuaAshton>
is the jump call thingy
<JoshuaAshton>
and the SGPR its doing is SGPRS[8..11] = { 00703100
<JoshuaAshton>
so the PC value of the hang does seem to be right
<JoshuaAshton>
which makes me believe that we are jumping somewhere naughty
kts has quit [Quit: Konversation terminated!]
mattst88 has quit [Server closed connection]
mattst88 has joined #dri-devel
kts has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
kts has quit [Quit: Konversation terminated!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: btw.. I am still not really happy about using dec/increment_strong_count, those calls require us to use Arc::into_raw and obj.inner = Arc::from_raw(ptr) to be used and I am not exactly sure what weird implications that might have
<karolherbst>
totally forgot about that detail
<karolherbst>
although it feels like this is fine
<karolherbst>
but...
kts has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
gouchi has joined #dri-devel
tdwebryv^ has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
bbrezill1 has quit [Read error: Connection reset by peer]
mripard has quit [Read error: Connection reset by peer]
ndut2 has joined #dri-devel
* ndut2
hey yah all skraito here what's up , i am here
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
* ndut2
brb
* ndut2
after sabbath day guys i join you all at 1:48 more hour rest well ... . is your sabbath day soon , at friday night to saturday night ... .
* ndut2
get the fuck off libera none of your concern here ... .
mvlad has joined #dri-devel
* ndut2
even rasberry pi is stupid guys , i would rather buy samsung a70 for 180 usd dollar and play tinkering from that ... .
<karolherbst>
jekstrand: done :) and no regressions \o/ (moving bindgen into its own crate)
* ndut2
all just code in c++ , c and the rest is just header , the rest think yourself ... .
* ndut2
to be honest you though you all code the kernel ? i just laugh ... . your just coding delusion ... . think for yourself why We say that ... .
* ndut2
if not the deal here i don't even care asshole ... . just get the fuck off libera and all frog ... . if you want just ban and k-line me ... . i got better thing to do rather than teaching kids with big ego or proud ... .
* ndut2
that usb encryption is one more thing super nice to for your key to turn on computer ... .
* ndut2
the password make it at my 0day c++ password with 7 string incase you forgot it
* ndut2
the password make it at my 0day c++ password with 7 string incase you forgot it <--- or just use the word and hash it
* ndut2
the password make it at my 0day c++ password with 7 string incase you forgot it <--- or just use the word and hash it think why i say so
* ndut2
you can hash it with time ... . the rest is your imagination ... .which mean other thing like your whatever favourite number or even letter or whatever ... .
* ndut2
haha is my old memory why i am the best in crypto now ... . i fail secondary 5 times lol ... . therefore The Fear of The Lord is The Beginning of wisdom ... . therefore be humble ... .
* ndut2
don't use vpn and the rest prince , is interpol problem , you just create trouble for yourself and them to protect you ... . i reveal to you that wireless encryption ... .
pcercuei has joined #dri-devel
* ndut2
you should first connect to wireless without encryption ... . than go to their https , fill in the form with your phone or ic ... . than get the password than connect to encrypted wireless ... .
* ndut2
you still sure there is privacy ? don't be fool ... . if not why the whole country has proxy ... . of course they know what's going on behind the door ... . even you need ic for your internet ... . brb working ... .
gawin has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
* ndut2
spamming ? yeah yeah
* ndut2
i am playing allods.my.com now , don't work crazy like us prince ... .
* ndut2
brb just call me for all country here what you want for deal i just standby it ... .
mszyprow has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
flacks has quit [Quit: Quitter]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
flacks has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
ndut2 was kicked from #dri-devel by ChanServ [(some troll)]
mlankhorst has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
* karolherbst
continues wiring up compiler stuff
camus has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
<HdkR>
ninja
<HdkR>
er uh
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
gawin has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
macromorgan is now known as Guest616
macromorgan has joined #dri-devel
cphealy has quit [Read error: Connection reset by peer]
Guest616 has quit [Read error: Connection reset by peer]
cphealy has joined #dri-devel
maxzor has joined #dri-devel
martijnbraam has quit [Server closed connection]
martijnbraam has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Guest499 is now known as degasus
MrRoffline[m] has quit [Server closed connection]
MrRoffline[m] has joined #dri-devel
gouchi has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
Company has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
neonking has quit [Read error: No route to host]
neonking has joined #dri-devel
neonking_ has joined #dri-devel
gawin has joined #dri-devel
neonking has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
Daanct12 is now known as Danct12
neonking_ has quit [Ping timeout: 480 seconds]
neonking has joined #dri-devel
mszyprow has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
siqueira has quit []
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Akari has quit [Ping timeout: 480 seconds]
siqueira has joined #dri-devel
melissawen has joined #dri-devel
siqueira has quit []
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
melissawen has joined #dri-devel
siqueira has joined #dri-devel
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
siqueira has quit []
sdutt has joined #dri-devel
melissawen has joined #dri-devel
siqueira has joined #dri-devel
mhenning has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
nchery has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
cworth has quit [Ping timeout: 480 seconds]
cworth has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
cphealy has quit []
<marex>
looking at the vivante VIP8000 NPU, it seems like vivante GPU with shares with different instructions
<marex>
*shaders
<marex>
is there any plan to support such stuff in mesa, via openvx ?
cphealy has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Guest452 is now known as DrNick
<jekstrand>
marex: Not via openvx. I don't think you can really do GL on top of OpenVX. But someone may add etnaviv support for it some day, I guess.
<marex>
jekstrand: no, you cannot, but you also cannot do GL on top of OpenCL and that is supported by clover, right ?
mvlad has quit [Remote host closed the connection]
<marex>
so something like clover for VX would be needed
<marex>
the NPU seems to be just a GPU with swapped out shaders with different instructions
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand>
Likely, if support were to happen, it'd be a compute-only gallium driver capalbe of running clover. We probably wouldn't layer on openvx
<marex>
jekstrand: the way I understand openvx, it is really an extension of opencl, right ?
<marex>
( I am not pushing openvx mind you, I'm just trying to understand the situation )
<jekstrand>
I'm not sure. I've not spent that much time looking at it. I think it's more like a standardized accelerated openCV image processing thing. Not general compute.
<jekstrand>
You could implement it on top of OpenCL, I think.
danvet has quit [Ping timeout: 480 seconds]
<marex>
jekstrand: I think opencl would be the first step anyway
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
mszyprow has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]