warpme_ has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #lima
dddddd has quit [Ping timeout: 240 seconds]
BenG83 has quit [Ping timeout: 240 seconds]
BenG83 has joined #lima
megi has quit [Ping timeout: 268 seconds]
Barada has joined #lima
Barada has quit [Client Quit]
Barada has joined #lima
BenG83 has quit [Ping timeout: 268 seconds]
BenG83 has joined #lima
Barada has quit [Quit: Barada]
Barada has joined #lima
Barada has quit [Client Quit]
maccraft123 has joined #lima
mastermart has joined #lima
<mastermart>
now I have the shader skeletons with correct dependencies on both vertex and fragment programs for 1.5ogl, since the spec does not allow address registers for fragment programs always, i made fragment program slightly differently.
<mastermart>
however additions are needed, cause i can not come up with the way to communicate with command buffers from vertex programs, cause it has not got any method to communicate with it.
<mastermart>
nothing exports to data cache it seems.
maccraft123 has quit [Ping timeout: 240 seconds]
BenG83 has quit [Read error: Connection reset by peer]
<mastermart>
actually there is something, however i have not looked into this.
wiewo has quit [Ping timeout: 276 seconds]
<mastermart>
the rationale behind this is, when you have millions of calls in the cp, the cpu would start to bottleneck, even when scheduling on CPU is good, cause accessing VRAM of the chip is slow.
<mastermart>
hence you want GPU to feed commands to the CP.
wiewo has joined #lima
<mastermart>
and more particularly Shader to do that.
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
camus has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
camus has joined #lima
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
<mastermart>
so it is going to be slight more work to be added, command buffers are defined for physicaldevice memory views that can be cached however needed in data cache.
<mastermart>
I do not know how accisble is t&l as data cache yet, but yeah normally all chips differentiate or separate the last vertex writes from the middle/preceding ones.
<mastermart>
in the vertex shader or program.'
<mastermart>
i have to go now.
mastermart has quit [Remote host closed the connection]
warpme_ has joined #lima
BenG83 has quit [Read error: Connection reset by peer]
BenG83 has joined #lima
BenG83 has quit [Read error: Connection reset by peer]
monstr has quit [Remote host closed the connection]
enunes has joined #lima
<anarsoul>
enunes: rellla: any ideas how to debug random failures when running q3a in loop?
<anarsoul>
recording apitrace is not feasible since it can take 30-60mins for issue to reproduce
<enunes>
anarsoul: I found two more leaks while debugging the glmark2 stuff
<enunes>
will send MR
<enunes>
but I think there is 1 more
<enunes>
at least with refract
<anarsoul>
great
<anarsoul>
I suspect we also free some BOs early somewhere
<anarsoul>
but I'm not sure how to debug it other than eyeballing the code
<enunes>
are you monitoring memory consumption while you reproduce those, to see if you might be running out for some random allocation?
<anarsoul>
nope
<anarsoul>
but I don't get any allocation failures
yann has joined #lima
mastermart has joined #lima
<mastermart>
mareko and nha once explained it. Rasterizer should post the new interpolated varyings everytime the succeeding stage does final exports, it then drives the bus with new ones, this all is logged on dri-devel
<mastermart>
and 400MP is specialized hardware it has separate vertex and fragment cores, and even registers are given separately from 1024 128bit ones from the regfile.
<mastermart>
which means actually fragment processor can be actively also feeding the CP. or so to speak made to do so.
<mastermart>
but yeah anyways i allready gave VHDL code of the rasterizer a full one and lengthy also.
<mastermart>
it was programmed in korea, by KAIST people...Korea Advanced Institute of Science and Technology.
<mastermart>
I think people should bare in mind that AFAIK. texture memory loads are always vector (as mandated by arb fragment program spec ), the dependent read on vectored load is very easy to be formulated.
armessia has joined #lima
<mastermart>
You do highly big roundrips at coding very big hunks that never behave intelligently for performance, added you know nothing about hw to run things properly and aside from copying stuff from internet all necessary for your code, you also lack any kind saner creativity which is to say no independent thinking capability in form of critical eye,
<mastermart>
people who only follow all commands blindly are dumb in my book.
<mastermart>
you seem to fall to every trolling and scam where the vendors planningly expect you to. very stupid guys so to speak, very arrogont on top, violative for a reason cause maybe you are not that bad, you are just purest dummies.
<mastermart>
some time ago google informed the computing enthusiasts or community of such, that they developed a quantum chip, and allready on my facebook i get feeds of how to do machine learning on cortex-M processors, so cause of pushed to the corner visually or virtually by google, IBM engineers finally told, that current computers are powerful too, more
<mastermart>
powerful then that of a linux freak could naturally anticipate.
<mastermart>
So one of the use of a tri-state signalling is in the busy_decoder_table.v so the incoming data is SIPO kind, tri-state ternary will reset the assigment to 0 if previous data gets old, and hence still be able to block the vectors register that is current
afaerber has quit [Quit: Leaving]
<mastermart>
which leads me to thinking do you also know how circular buffers work, at least linked-lists the other famous way alyssa seemed to have read, what is the goal of linked lists.
<anarsoul>
enunes: these are all regular memory leaks, not BO leaks
<enunes>
anarsoul: I know, though I wondered if it was because of them that running in a loop was failing
<mastermart>
cause wikipedia again has a good article about circular buffers and how they work, there is a channel of length of bytes sometimes also called ring
afaerber has joined #lima
<enunes>
and I was looking for bo leaks and found those anyway
<mastermart>
and when you post data to that ring, you have to tell the tail pointer to increment this is a producer consumer technique
<mastermart>
producer is a CPU and consumer is GPU
<enunes>
valgrind doesn't report anything other than those
<mastermart>
when the channel is full it wraps around the pointers to the the beginning of the ring, when pointers are equal
<mastermart>
wikipedia explains everything needed there also like in the case of linked lists
<anarsoul>
enunes: I don' think that valgrind knows how we allocate BOs
<anarsoul>
IIRC we need to do some annotations to teach it
<enunes>
I mean, I want to get other leaks out of the way so we can be sure that we really have bo leaks
<anarsoul>
see vc4_bufmgr.c
<mastermart>
you want to ban me and ignore me and shit like this, but you gotta learn how to program before, stop this autist crap and think a bit how to maintain proper stack, if you are not going to learn this art, you will receive critisism in greater amounts soon.
<mastermart>
so ringbuffer has start and end pointers and head and tail pointers, four pointers.
<mastermart>
all of them can be programmable but if they are not, well on specialized fragment processor you can have the texture as the size of the ring.
<mastermart>
and overlap it and feed the commands from there.
<mastermart>
if the vertex buffers have limits with instancing enabled that the ring can be larger by default and is somewhat fixed.
<enunes>
anarsoul: yeah ok porting those annotations gives a lot more of reports
<anarsoul>
:)
<enunes>
though it requires more time to go through all this, and I don't know how much cleanup we do at the end to classify these as real bugs
<enunes>
I guess I can just look at whatever is the buffer buffer reported with a few runs
<enunes>
bigger buffer
<anarsoul>
I think the biggest for glmark2 would be ctx buffer
<mastermart>
really that parrot code is not very good for scheduling jobs either.
<enunes>
anarsoul: I can review it, but later
<mastermart>
very bulky, highly pointless.
<anarsoul>
OK, thanks
<mastermart>
lot of kernel is nowdays bloated all do it very wrong, basically a flood of shit.
<anarsoul>
it looks good to me, just want to get second opinion on compiler change
maccraft123 has quit [Ping timeout: 245 seconds]
<mastermart>
I am going to be pissed off, my webrowser nor my eyes can not tolerate such crap. Kernel plumbing just like any other code needs to performsnt and performant code is short.
<mastermart>
so most of this crap spanning around millions of lines need to be removed from kernel.
mastermart has quit [Remote host closed the connection]