<MoeIcenowy>
sorry sent a obvious wrong url -- the latter url is the dump1
<MoeIcenowy>
but more strangely
<MoeIcenowy>
this is not a regression
<MoeIcenowy>
the dump1 is equal to the one generated by master
<enunes>
MoeIcenowy: thanks, I'll do some more testing and update my MR based on the comments there, you don't need to submit another MR on the same topic :)
<MoeIcenowy>
I forgot whether the kernel build contains the fix...
<MoeIcenowy>
I only know my newest build fixes it
nerdboy has joined #lima
<MoeIcenowy>
yuq825: checked the dump, it's the same with my intel
<yuq825>
with or without your MR?
<MoeIcenowy>
I get the same result on lima both with or wirhout...
<MoeIcenowy>
I mean your dump is same with my intel
<yuq825>
OK, I miss understand
<yuq825>
so let's see if your strange result is due to the kernel bo wait fix
<MoeIcenowy>
yuq825: no
<MoeIcenowy>
it's not related to bo wait
kaspter has joined #lima
<yuq825>
I did use this test when implementing partial clear, at that time the result is same as amdgpu with the partial clear and not without the partial clear
<yuq825>
how about sleep several sec before read out the pixel?
<yuq825>
this result looks like read from in-complete rendering buffer
<MoeIcenowy>
yuq825: tried to uncomment glFlush and add system("sleep 1") before and after it
<mardikene193>
it asks for a result of assignment in the simd module
<mardikene193>
if the writeback was never comitted
<mardikene193>
committed
<mardikene193>
cause of execution getting a stall in verilog loop, cause of
<mardikene193>
the opcode being not recognized, it will wrap around right away
<mardikene193>
what happens under the hood is: when simd module do not progress to writeback, a flopped value is offered, which is going to be the same as before
<mardikene193>
so in other words, that drives zero to
<mardikene193>
issue modules instr_info_table
jrmuizel has quit [Remote host closed the connection]
<mardikene193>
and this one is going to be registered since
jrmuizel has joined #lima
<mardikene193>
It involves only linking in the issue module with dummy call though
<mardikene193>
errrr.........
<mardikene193>
SIMD module sorry from issue
jrmuizel has quit [Ping timeout: 245 seconds]
<mardikene193>
what happens honestly is a tricky methof....
<mardikene193>
it plays the last element back into simd two times, and the last one is not being registered instead it wraps around
<mardikene193>
So yes with 95% likeliness the bets from be is placed into simd arbiter wrapping around
<anarsoul>
MoeIcenowy: allocation failure is not good. It's probably not handled properly in lima
<MoeIcenowy>
but at least no virtual glitches
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
megi has joined #lima
<anarsoul>
deqp surfaceless doesn't work for me :\
<MoeIcenowy>
anarsoul: I cannot understand why the code even works
nerdboy has quit [Ping timeout: 246 seconds]
nerdboy has joined #lima
<mardikene193>
And it isn't like it is wrapping around fast on it's own, it wraps around with the help of the fetch arbiter
<mardikene193>
it is very complex but the simd arbiter and valid bits signals are different
jrmuizel has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
<mardikene193>
I mean buckle your seatbelts while i push down the paddle, but everything will be fine cause everything was meant to be
<mardikene193>
this taiwanease guy who made the code, is a hell of a star, but canadians and yanks were even before there
<mardikene193>
i am not sure when the generator was made, what suprised me the most, was how russians did their VLIW chips for instance or for an example
<mardikene193>
but zwabbit is hell of a big programmer, this guy has a head similar to me
<mardikene193>
I offhand do not even remember was he hailing from taiwan or hong-kong though
<mardikene193>
in both of the cases his nationality along with the picture proved ethnicity should be chinease
<mardikene193>
so to be frank, to demonstrate how simd arbiter wraps around, you need to make instances of 3-4 submodules
<mardikene193>
fetch. decode. issue simd alu or starting from decode, 3-5 depending how you call into the simulator
<mardikene193>
I of course would prove it rather quick with 20minutes work if someone wanted though
<mardikene193>
I have had my own issues in life, but i have capability to think, and generally i am considered ace in the pack even though this is judd trumps nickname
<mardikene193>
MoeIcenowy: you wanna present your issue too with scissors in the code or blend, or what is the matter?
<mardikene193>
what i tend to think those are fixed function stages minimally configurable
<mardikene193>
scissors probably belong to a term called depth testing
<mardikene193>
while blending is as it is allready stage name is the same
<mardikene193>
i may be wrong, since there is also a viewport transformation which is a stage before depth testing
<mardikene193>
so scissors belong either to clipping or depth desting
<mardikene193>
while blending is something that happens before the final framebuffer write as middleware stage
Tofe has quit [Ping timeout: 265 seconds]
Tofe has joined #lima
jrmuizel has quit [Remote host closed the connection]
Tofe has quit [Quit: Tofe'IRC Machine]
Tofe has joined #lima
Tofe has quit [Client Quit]
Tofe has joined #lima
<anarsoul>
enunes: are you going to update your MR to drop partial clears?
jrmuizel has joined #lima
mardikene193 has quit [Ping timeout: 245 seconds]
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
anarsoul|c has quit [Quit: Connection closed for inactivity]
jrmuizel has quit [Remote host closed the connection]