March 29, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 29, 2019 [00:00:02] <zalt__> i don't know, i'm using a single RGBA8888 texture for all instances of the sprite i'm testing, additionally 2 huge font atlases, and 2 fake textures for solid colors[00:00:29] <zalt__> it's a 500x500 sprite[00:00:35] <sparr> system has typedef void (APIENTRYP PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, const GLint *params); while game has typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, GLint* params); which look like minor changes possibly due to different versions of the libraries?[00:00:50] <derhass> sparr: the game shouldn't include both glew.h and glext.h to begin with[00:01:49] <chrisf> zalt__: you're drawing something 500x500 at 15x15?[00:01:55] <derhass> GL API got a few fixes for const correctness a couple of years ago[00:02:18] <zalt__> chrisf, yes lol, i'm testing things :D[00:02:36] <chrisf> zalt__: build some mipmaps.[00:02:37] <derhass> zalt__: mipmapping to the rescue[00:02:41] <derhass> hrhr[00:03:01] <zalt__> with that i'd be able to spawn even more :P[00:03:54] * zalt__ glad his two or three months working on the engine yielded reasonably good results[00:03:58] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has quit IRC (Quit: Leaving)[00:05:03] <derhass> zalt__: 200k 15x15 pixels at 28fps are just 1.26 GPixels/second. not impressive at all[00:05:31] <zalt__> derhass, it is impressive when you consider it is a 500x500 texture[00:05:32] <sparr> derhass: thanks, omitting glext.h leads to a successful build. omitting glew.h results in a lot of undefined constants (GLEW_EXT_*) that would need to be replaced by their GL_EXT counterparts[00:05:42] * zalt__ resizes his texture to cheat[00:07:51] <chrisf> zalt__: mipmaps help *both* performance and quality[00:09:42] <chrisf> zalt__: the sampler hw in the 1070 is capable of ~200Gtex/s[00:10:19] <zalt__> noo! resizing the texture didn't help :P[00:10:43] <zalt__> i should feel content with my 200k 30fps thing :P[00:11:12] <zalt__> note that each of them has an independent dx / dy / x / y, thing that gets added at each frame[00:11:41] <derhass> so it's particles?[00:12:13] <zalt__> umm, it's a benchmark, but in theory yes, you can consider them particles[00:12:30] <derhass> a benchmark for what?[00:12:33] <zalt__> i'm just testing various parts of the engine[00:13:38] <zalt__> the demo itself is quite meaningless, their dy's and dx's are set to a a random value[00:13:56] * zalt__ should try making something useful[00:14:36] <derhass> no. benchmarkin useful scenarios usually ruins the numbers[00:15:08] <zalt__> true, i will not publish the numbers[00:15:14] <zalt__> :P[00:15:27] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 245 seconds)[00:16:01] * zalt__ realizes that derhass optimized the vertex and fragments shaders that are used in this benchmark[00:16:05] <chrisf> i would be interested in seeing what nsight thinks of your version with the properly matched texture size[00:16:25] <zalt__> yeah, i will be back in a few minutes, i will take a screenshot[00:19:50] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[00:32:34] *** snyp <snyp!~Snyp@1.39.132.205> has quit IRC (Ping timeout: 255 seconds)[00:34:16] <zalt__> i'm back[00:35:54] *** goiko <goiko!~goiko@unaffiliated/goiko> has joined ##OpenGL[00:37:23] <zalt__> chrisf, https://i.imgur.com/ir1IZAi.png[00:37:34] <zalt__> i think i'm getting cpu bound at this point :D[00:39:45] <zalt__> i could reduce the number of draw calls by changing the hardcoded size of a buffer, i think that could slightly improve it, i'm worried i might run into the limits of some gpus[00:40:36] <zalt__> oh wait, most of the time is spent in glbufferdata()[00:41:07] * zalt__ changes the hardcoded size of the buffer[00:48:38] <zalt__> doubling its size by 4 reduced the time by 2ms, not a big difference, i think it's the bandwidth limit in this case?[00:52:09] <Stragus> Allocate once by glBufferData, then at least use SubData() to update chunks without reallocating[00:52:33] <Stragus> Better, map the buffer and write there[00:52:54] <Stragus> Even better, map the buffer persistently, unsynchronized, and manage syncing yourself[00:53:09] <Stragus> Even even better, write to the mapped buffer with SSE/AVX write-combining streaming stores[00:54:27] <zalt__> lol, also the cpu is dying it seems[00:54:39] <zalt__> all actions took 17ms? that means the rest of it is the cpu's fault[00:58:23] * zalt__ 17ms after changing the buffer size[00:58:34] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[00:59:02] *** zalt__ is now known as zalt[01:00:50] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[01:06:38] *** charlie5 <charlie5!~rod@pa49-180-41-4.pa.nsw.optusnet.com.au> has quit IRC (Read error: Connection reset by peer)[01:07:29] *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined ##OpenGL[01:27:51] <chrisf> zalt: you're waiting for idle 27 times per frame.[01:28:30] <chrisf> how about not :)[01:31:12] <chrisf> what are the characteristics of this buffer you're uploading?[01:33:35] <zalt> what do you mean?[01:33:49] <chrisf> how big are these uploads? how big is the entire buffer?[01:35:03] <zalt> ummm, it is 2^16 * (struct size: 24) * {30 uploads} per frame[01:36:31] <chrisf> let's see your actual upload code[01:37:54] * zalt has GL_STATIC_DRAW instead of STREAMING[01:38:16] <zalt> chrisf, do you think that might have something to do with it? :D[01:38:43] <chrisf> let's see actual code :)[01:38:54] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[01:40:16] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[01:41:54] <chrisf> im more concerned about waiting for the gpu to go idle than the buffer placement[01:44:24] <zalt> chrisf, the code is scattered in a few places, i'm afraid a single function will be not be enough, here i gathered what i think is relevant[01:44:45] *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined ##OpenGL[01:44:48] <zalt> chrisf, http://dpaste.com/1GYCHAT[01:45:01] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[01:45:56] <zalt> vbuff is just a huge contiguous mallocd buffer, with a set limit, when it overfills i call ren_dump_to_buffer to clear it and fill it with more vertices[01:46:05] <zalt> the default limit is at (1 << 15)[01:47:00] *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined ##OpenGL[01:47:37] <zalt> Batch_Info is just a descriptor of a region of vertices in vbuff that have the same texture_id, each Batch_Info needs a texture switch then a draw call[01:50:50] *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC (Ping timeout: 250 seconds)[01:51:29] <chrisf> and this is all using one buffer object by the looks of it[01:51:36] <zalt> yep[01:52:09] <chrisf> well, what you're doing, intentionally or otherwise, is leaning very heavily on the buffer renaming / orphaning tricks drivers try to do[01:52:14] <chrisf> and it's not quite working out[01:52:37] <derhass> use the ring buffer, luke![01:52:58] <zalt> hmm, so i will be giving the gpu an easier time by having multiple buffers?[01:53:20] <derhass> or ranges inside a single buffer[01:53:26] <zalt> the buffer renaming scheme sounds like what is done with x86 registers :P[01:53:58] <chrisf> if you just replace your single buffer object with a small pool of them, you might find interesting results[01:54:20] <chrisf> these buffers themselves are a whole pile of nothing in terms of memory... ~1.5M.[01:55:54] <zalt> i will try this[01:56:57] <chrisf> you can do even better, but this is fairly uninvasive.[01:57:17] <chrisf> and yes, as you mentioned earlier -- STATIC_DRAW is wrong.[01:57:53] <derhass> yeah, but the nvidia driver will second-guess that anyway^^[01:58:02] <chrisf> it assumes you have no idea what you're doing :)[01:58:12] * zalt glad nvidia doesn't trust him[01:58:20] <chrisf> (which is true for most GL apps)[01:58:43] <derhass> and a major PITA in the rare cases when one _really_ knows what one is doing[01:58:54] <chrisf> it does obey BufferStorage[01:59:24] *** xx2 <xx2!~xx2@212.253.8.72> has quit IRC (Quit: Leaving)[02:00:58] *** KAHR-Alpha_ <KAHR-Alpha_!~Alpha@2a01cb0d024a66005474f06642e55b50.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 258 seconds)[02:01:22] <derhass> yeah. my statement was meant more in the broader sense, not specific to the buffer usage flags[02:07:01] <Serus> Is there a debugger for the raspberry pi? every one I've tried doesn't work, because of it wanting to use mesa EGL[02:07:49] <Serus> the pi uses a different EGL library[02:08:01] <derhass> the Pi can use mesa just fine[02:08:07] <derhass> you just have to enable it[02:08:14] <Serus> yes, but that's emulation[02:08:18] <derhass> no[02:08:31] <Serus> you sure? I've been told so[02:08:36] <derhass> there is a native GLES driver for the broadcom vc4 in meas (and linux)[02:08:53] <derhass> there is some desktop GL 2.x emulation/simulation/hacks[02:09:13] <chrisf> vc4 is better than broadcom's old GLES blob now[02:09:13] <Serus> wait[02:09:19] <Serus> what[02:09:42] <Serus> so I can actually use GLES via mesa and have it work properly?[02:09:49] <derhass> sure[02:09:52] <Serus> I did read something about that, but it being in beta[02:10:04] <derhass> you can even get some desktop GL apps working *(with a couple of limitations)[02:10:15] <chrisf> iirc it's not even hard to set up -- raspbian installer has a switch?[02:10:25] <derhass> raspi-config has an option for it[02:10:32] <chrisf> that would be it[02:10:52] <chrisf> i never use a pi unless something is interestingly busted[02:11:00] <Serus> Hmmm, I'll ask what school thinks about that[02:11:06] <derhass> hehe, I use a couple of those[02:11:15] <derhass> not really for graphics, though[02:11:20] <derhass> all headless[02:11:32] * Serus is talking from a gen 1 pi[02:11:41] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[02:11:42] <chrisf> ive had a few which ive bought for debugging something or other, and then ended up giving away to someone who needed a machine to tinker with[02:12:03] <chrisf> Serus: gpu is the same in all of them[02:12:16] <derhass> I did port dxx-rebirth to the Rpi with the broadcom proprietary vc4 libs back when there was no alternative[02:12:17] <chrisf> miserable little vc4[02:12:17] <Serus> I thought the pi 1 had a lesser gpu[02:12:24] <derhass> Serus: no[02:12:33] <derhass> they all have the VC4[02:12:39] <Serus> interesting[02:12:43] <chrisf> there's some shenanigans about memory partitioning on the pi1.[02:13:23] <derhass> Serus: moder raspbian images even use the mesa driver by default, iirc[02:13:38] <Serus> but yeah, I'll ask what school thinks about that mesa driver thingy[02:13:55] <Serus> afaik they want us to use a vanilla setup so they can run it without issues[02:14:00] <derhass> a, school[02:14:11] <derhass> so we can be happy that it is not limited to GLES1.1[02:14:26] <Serus> well, I say school, but I mean uni[02:14:31] <derhass> same thing[02:14:43] <Serus> I just call every institution of education a school[02:14:53] <Serus> well some people think like high school lol[02:14:55] <derhass> I've no issue with that[02:15:24] <Serus> but yeah, using ES2[02:15:33] <Serus> let me check raspi-config[02:15:43] <derhass> I'm finished with university this month. so looking forward, although I might be looking backwards GL-wise[02:16:38] <Serus> It seems it's using G1 GL (Full KMS)[02:16:49] <Serus> or that might just be the default selection for it[02:16:55] <Serus> how do I query it?[02:17:52] <derhass> are you using X desktop?[02:17:59] <derhass> glxinfo should already tell you[02:18:01] <Serus> nope, headlessish[02:18:06] <derhass> eglinfo maybe[02:18:21] <Serus> what package?[02:18:51] <derhass> no idea[02:18:56] <Serus> I have somebody's eglinfo thingy, but idk if that's the actual eglinfo[02:18:56] <derhass> dunno if it is in raspbian[02:19:29] <Serus> hmmm, mesa-demos on arch[02:19:36] <derhass> asking apt-file on one of my Pis, takes a while (pi 1 is really slow, especially when underclocked)[02:20:01] <derhass> nope, not in raspbian, it seems[02:23:26] <Serus> hmmm[02:24:43] <derhass> just compile it yourself[02:25:14] <Serus> https://github.com/dv1/eglinfo this one?[02:25:30] <zalt> is 0 a valid vbo name?[02:25:40] <chrisf> no[02:25:52] <chrisf> 0 is 'no buffer'[02:25:56] <zalt> it is the same with textures/vaos i assume?[02:26:11] <chrisf> no[02:26:15] <chrisf> texture object 0 is a thing[02:26:33] <chrisf> you can (and probably should) pretend it isnt[02:26:34] <zalt> but it will never be returned by gentexture right? i remember reading this[02:26:42] <chrisf> correct[02:27:16] <zalt> but my assumption about 0 being a valid buffer name is wrong[02:27:35] <derhass> right[02:27:37] <chrisf> ideally dont make any assumptions about what valid names are :)[02:27:45] <zalt> :D[02:27:47] <chrisf> use things Gen* gives you, and nothing else[02:30:08] <zalt> i got confused between functions that return negatives (get..location i assume) and ones that return 0[02:30:41] <zalt> i only noticed this because it's unsigned, i was like how can unsigned be negative[02:32:09] * zalt wonders whether his assumption about gluniformlocation returning a negative is also wrong[02:32:27] <chrisf> no[02:32:43] <zalt> i always heard that error handling code paths themselves contain the most bugs, now i believe this :P[02:33:13] <chrisf> but using glGetUniformLocation at all might be wrong :)[02:33:14] <derhass> well. there is nothing wrong about it returning -1, and call glUinform() on location 01 will explicitely NOT generate a GL error[02:33:27] <derhass> *on location -1[02:33:50] <chrisf> default block uniforms can go die[02:33:58] <derhass> but samplers![02:34:09] <chrisf> derhass: layout(binding=n)[02:34:09] <derhass> sure, set the binding in the GLSL source[02:34:32] <chrisf> having that mapping via uniform *values* was mad anyway[02:35:08] <chrisf> in fact, i think every one of GL's little remapping tables ended up being crap[02:35:19] <derhass> I put it to my list of "what were they thinking", biut that list is quite long already[02:35:19] * chrisf frowns at drawbuffers state[02:35:28] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 258 seconds)[02:35:43] <derhass> GL, master of indirections[02:35:48] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Remote host closed the connection)[02:36:46] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[02:36:52] <Serus> libEGL warning: DRI3: xcb_connect failed[02:36:58] <Serus> libEGL warning: DRI2: xcb_connect failed[02:37:04] <Serus> eglinfo: eglInitialize failed[02:37:05] <derhass> looks like it wants some X server running[02:37:07] <Serus> :([02:37:20] <chrisf> you might be holding it wrong[02:37:53] <Serus> ok, there we go[02:38:03] <Serus> had to ssh in with X forwarding[02:38:11] <derhass> mmmm[02:38:25] <derhass> now you might use your local X server and not the Pi's[02:38:52] <Serus> it says EGL 1.4 (DRI2)[02:39:01] <Serus> and Mesa Project as the driver vendor[02:39:25] <derhass> and Renderer?[02:40:07] <derhass> you might get really weird results by using your local x server[02:40:26] <Serus> uhm[02:40:32] <derhass> although I'm not sure how this all works together in the context of EGL[02:40:51] <Serus> what do you mean with Renderer, I see no thing with the word Renderer in it[02:41:01] <Serus> EGL client APIs: OpenGL OpenGL_ES[02:41:24] <derhass> well[02:41:38] <derhass> eglinfo should report somethin' on the OpenGL ES API[02:42:15] <Serus> under configurations?[02:42:24] <derhass> no idea[02:42:25] <Serus> In that case[02:42:31] <Serus> renderable[02:42:37] <Serus> gl es es2 vg[02:42:37] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[02:42:41] <derhass> there are probably a gazillion different eglinfo.c around[02:42:55] <Serus> I grabbed the one from the mesa demos source code[02:43:05] <Serus> ftp://ftp.freedesktop.org/pub/mesa/demos/8.3.0/[02:43:36] <Serus> oh wait, there's an 8.4.0 that I skipped over[02:43:39] <Serus> lemme grab that[02:43:48] <derhass> both are prehistoric[02:44:09] <Serus> oh[02:44:25] <Serus> 8.4.0 says 23/02/2018 though[02:44:35] <derhass> oh, so not synced with mesa version?[02:44:36] <derhass> OK then[02:44:44] <derhass> whatever[02:45:08] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Quit: Leaving)[02:45:18] <zalt> chrisf, what you suggested about multiple vbos seems to be the solution, it's fast, however i'm running into undefined behavior it seems :D[02:45:23] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[02:45:39] <zalt> i think i'm overwriting the previous buffer before the one currently drawing is done or something[02:46:08] <derhass> zalt: you were doing that _before_[02:46:25] <zalt> umm, so that's not the problem?[02:46:51] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has joined ##OpenGL[02:46:51] <derhass> well, with glBuffer(Sub)Data, synchronization is the driver's problem[02:47:30] <derhass> but you might still have undefined behavior in your code[02:47:34] <derhass> who knows?[02:47:34] <zalt> now i have 4 vbos and i'm doing a simple vbox[4]; bind(vbos[idx]); idx = (idx + 1 ) % 4; thing[02:47:58] * zalt checks gl error[02:48:07] <Serus> ok, now the output is more inline with what I see on my desktop[02:48:07] <chrisf> zalt: did you forget to also call VertexAttribPointer again after switching bo?[02:48:10] <derhass> and you do respecify the vertex attrib pointers?[02:48:24] <zalt> no i'm not calling that[02:48:27] <Serus> looks like it wants X11[02:48:34] <zalt> i thought it's the vao problem, no?[02:48:51] <zalt> i mean i thought it's saved in the vao[02:48:52] <derhass> Serus: I;m not sure how mesa's vc4 egl implementation works without x11[02:48:54] <chrisf> zalt: this is the usual new user trap.[02:48:57] <derhass> Serus: never tried that[02:48:58] <zalt> haha[02:49:13] <chrisf> zalt: the value of GL_ARRAY_BUFFER has *no* direct effect on draws.[02:49:17] <derhass> zalt: the fact that it is stored in the VAO is exactly the problem[02:49:33] <chrisf> zalt: it's captured into the vao at the time you call VertexAttribPointer[02:49:43] <zalt> ohh[02:50:03] <zalt> so it's not even a proper indirection[02:50:25] <derhass> it is[02:50:35] <chrisf> it's latched state[02:50:38] <derhass> it is just latched at a different point than many new users think[02:50:47] <zalt> :D[02:51:00] <chrisf> i agree it's crap, and we fixed it in GL4.3 with the new vertex attrib binding model[02:51:09] <derhass> but OTOH, there would be no way to have attributes come from different buffers if it were otherwise[02:51:15] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[02:51:55] <chrisf> derhass: with an indirection table :)[02:52:07] *** mandeep <mandeep!mandeep@gateway/vpn/privateinternetaccess/mandeepb> has quit IRC (Remote host closed the connection)[02:52:26] <chrisf> the old model grew out of client vertex arrays[02:52:33] <chrisf> it makes sense in that context[02:53:10] <derhass> there was a time when even using void* for byte offsets made (a bit of) sense[02:53:11] <zalt> chrisf, ha! 200k sprites at 37.5 fps[02:53:30] <zalt> this is an amazing improvement :P[02:53:32] <chrisf> let's see the profile again[02:53:42] <zalt> it was at 24-28 fps before[02:53:43] <chrisf> you're still only getting a few % of the machine[02:53:48] <zalt> lol[02:54:00] <chrisf> a big pascal is *incredibly* fast.[02:54:55] <derhass> yeah, I wished I had the power of the 1070 available to me just 7 years ago[02:55:02] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[02:56:54] <chrisf> derhass: well, when they really were pointers into client memory, void* made perfect sense.[02:57:05] <derhass> yes[02:57:29] <derhass> but it never made sense for byte offsets (if you're not counting pointers as just that, which of course is not totally wrong either)[02:58:20] <chrisf> derhass: the right thing might have been to define new functions rather than jam buffer object semantics into VertexAttribPointer etc[02:58:33] <chrisf> or, at the time, VertexPointer, ColorPointer, HamSandwichPointer,...[02:58:53] <derhass> IndexPointer, my secret favourite ;)[02:59:08] <chrisf> monster[02:59:22] <chrisf> that is just to confuse new users :)[02:59:22] <Serus> I have to enable it, derhass[02:59:29] <Serus> it's not enabled by default[02:59:54] <derhass> Serus: maybe it is enabled for default on Pi2 or higher? dunno[03:00:04] <zalt> chrisf, https://i.imgur.com/WoK2vFg.png[03:00:10] <Serus> the one I'm using is a pi3 from school[03:00:18] <derhass> oh, ok[03:00:19] <zalt> it seems at this point it's pretty much the cpu's fault[03:01:53] <derhass> .oO( next, chrisf is telling you about persistently mapped buffers or something like that )[03:02:08] <chrisf> you're still stalling[03:02:21] <chrisf> derhass: im tempted, but i think it's maybe too intrusive[03:03:12] <chrisf> zalt: the thing im looking at is the `Wait For Idle Count` on the right[03:03:27] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has quit IRC (Quit: Leaving)[03:03:36] <zalt> chrisf, it was reduced significantly after using 4 buffers[03:03:53] <zalt> i tried with 16 buffers and there wasn't much of a difference, the fps actually became slightly worse[03:03:55] <chrisf> did you fix your buffer flags to STREAM_DRAW or DYNAMIC_DRAW?[03:04:01] <zalt> STREAM_DRAW[03:04:36] <zalt> if i'm still using a couple of % of the gpu, what's the point of buying better gpus, it's a scam[03:04:59] <chrisf> well, if you feed them more efficiently you can light up the whole thing :)[03:05:05] <derhass> zalt: maybe do somehting useful on the GPU?[03:05:19] <zalt> i guess most games don't buffer huge amounts of data, and render huge 3d geometry saved on the gpu :P[03:05:20] <derhass> drawing textured quads is boring. every compositor does that[03:06:15] <chrisf> zalt: we have more efficient ways of streaming data than BufferData as well :)[03:06:36] <derhass> .oO( I knew it! )[03:06:49] <chrisf> depends how far down this rabbit hole you want to go[03:06:51] * zalt his enginelet is ready for 3d, it's designed with ecs and cache friendliness in mind, he just needs to read 5 books about how 3d graphics work[03:07:16] <derhass> better read one good book about linear algebra[03:14:18] <chrisf> zalt: you might also consider calling BufferData *once* for each buffer with your fixed size + data=0, and then using BufferSubData for your actual upload[03:14:57] <chrisf> respecifying the buffers all the time, and to the *exact* size you're using, is a bit weird[03:15:16] <zalt> what's sad about optimizing this further is that it'll end up using 0.0001% of the cpu in any 2d game i might make with it[03:15:20] <zalt> gpu*[03:15:28] <zalt> it'll be able to run on a toaster[03:16:29] <Serus> derhass: interestingly I get no output when I enable the new GL driver[03:16:32] <zalt> i will try it on android after these improvements, i have already built the thing before for it[03:16:40] <Serus> does it require an X server?[03:16:56] <derhass> Serus: I honestly don't know[03:17:09] <derhass> Serus: when I tried the mesa vc4 drives, it was on an X server[03:17:19] <zalt> thinking about it, it does make sense to care about performance even for 2d, because of phones[03:17:39] <zalt> but with pubg running on mobiles these days, i don't know :P[03:17:43] <derhass> phones meanes GLES[03:18:20] <derhass> and if you really want them all, you're in ES2 land, which is just a euphism for "hell"[03:18:56] <zalt> lol[03:19:10] <derhass> *euphemism[03:19:19] <derhass> I shouldn't type any more today...[03:27:06] <Serus> oh it works with fake kms[03:32:03] *** xx2 <xx2!~xx2@212.253.8.72> has joined ##OpenGL[03:34:13] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##OpenGL[03:34:37] <zalt> chrisf, what made interested in this sprite benchmark nonsense is a 'premium' unity demo about their 'revolutionary' job optimization thing, i was angry i couldn't beat it when i was overdrawing and without the changes you guys suggested[03:35:46] <zalt> it was 100k sprites at 30 fps or something, i'm not sure whether they even have script invocations or not :D[03:37:08] * zalt tries to find the demo[03:37:55] <chrisf> 100k actors doing real stuff isnt even that impossible.[03:38:30] <zalt> chrisf, now even with 80k entities with scripts, that is 80k lua invocations per frame i'm getting 60fps[03:38:50] <zalt> it's not even luajit[03:39:28] <zalt> each script has its state and lua table[03:39:51] <zalt> i wonder what kind of numbers of scripts/entities do you usually have in AAA games[03:41:14] <zalt> i think good games with huge worlds have to be smart about these things, like they'd have zones that are loaded/unloaded based on where the player is located[03:41:22] <chrisf> actively doing stuff? less than this.[03:41:32] <chrisf> you have *loads* of clutter that doesnt really do much[03:42:36] <derhass> it is funny that - apart from maybe a few videos on youtube - I basically have no idea of what modern AAA games look or feel like[03:43:01] <zalt> some are incredible pieces of engineering :D[03:43:40] <zalt> i don't play now though, i totally quit video games a while ago[03:44:11] <derhass> I had quit around 2001 or so[03:44:41] <derhass> interestingly, it can back a bit two years ago[03:44:46] <chrisf> zalt: since your cpu/gpu work is so lopsided you might also consider moving more to the gpu[03:45:28] <zalt> chrisf, i can improve the cpu part even more, for example the lua numbers wouldn't have been possible had i not used 4 threads for it[03:45:42] <chrisf> zalt: reconstruct the pairs of triangles from a single block of per-sprite data, etc.[03:45:59] <zalt> however i'm not doing the same for the transform system, the thing that adds dx/dy, i can multithread that part too[03:46:11] <chrisf> zalt: may allow you to spend significantly less time building the data to upload.[03:46:36] <Serus> derhass: where can I find that the vc4 mesa driver is faster?[03:47:00] <derhass> Serus: I didn't even claim it to be faster in general[03:47:29] <derhass> but the open source drivers did mature a lot since when they were first inroduced[03:47:33] <derhass> (in 2016 I think?)[03:47:41] <Serus> oh, right, that was chrisf[03:47:50] <Serus> well, he said better, specifically[03:48:05] <Serus> chrisf: in what way is the vc4 driver better?[03:48:15] <Serus> other than being open source[03:48:22] <chrisf> less buggy[03:48:37] <Serus> what about performance?[03:48:41] <Serus> how do they compare?[03:48:48] <chrisf> should be on par[03:49:14] <derhass> Serus: actually, you started this by saying that you can't debug on the Pi because mesa egl is required, and I told you that mesa works on the Pi[03:49:37] <Serus> I did[03:49:59] <derhass> not sure if this will actually solve the issue about the debugging[03:50:10] <Serus> it does[03:50:16] <Serus> I grabbed a sample and compiled it[03:50:22] <Serus> and was able to run apitrace on it[03:50:27] <Serus> and it runs in KMS mode[03:51:16] <Serus> https://i.imgur.com/Cokbqfg.png[03:53:12] *** impulse <impulse!~impulse@S01062c7e81ff33f0.mh.shawcable.net> has quit IRC (Read error: Connection reset by peer)[03:53:28] <Serus> https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef this code[03:57:48] *** bpmedley <bpmedley!~bpm@2600:1700:eb20:6050:d50e:6232:987d:880b> has quit IRC (Ping timeout: 250 seconds)[03:58:33] *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC (Read error: Connection reset by peer)[04:07:45] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[04:23:38] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[04:32:56] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[04:34:27] *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC (Quit: fatal halt)[04:42:51] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has joined ##OpenGL[04:50:56] *** Shockk_ <Shockk_!~shockk@polar/dev/shockk> has joined ##OpenGL[04:53:34] *** Shockk <Shockk!~shockk@polar/dev/shockk> has quit IRC (Ping timeout: 250 seconds)[04:55:22] *** LunarJetman2 <LunarJetman2!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 255 seconds)[04:57:13] *** LunarJetman2 <LunarJetman2!LunarJetma@5ec16e1a.skybroadband.com> has joined ##OpenGL[05:07:04] <Serus> derhass: I got it working with GLFW and X forwarding[05:07:11] <Serus> but I feel it's slow[05:10:34] <Serus> lmao it runs at 3FPS[05:11:34] <Serus> I definitely feel it's running in some emulation mode with X forwarding[05:14:31] *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined ##OpenGL[05:24:29] <chrisf> well, with x forwarding you're going to be doing indirect glx over the x connection[05:24:56] <Serus> yeah[05:25:02] <chrisf> the local gpu isnt involved[05:25:03] *** gb_away <gb_away!~hhhhh@190.18.120.141> has quit IRC (Ping timeout: 245 seconds)[05:25:26] <Serus> I switched back to brcm for now, since I have no platform layer for libdrm[05:28:32] *** xx2 <xx2!~xx2@212.253.8.72> has quit IRC (Remote host closed the connection)[05:30:46] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has quit IRC (Quit: Leaving)[05:33:11] * chrisf frowns at gl_VertexID being signed[05:34:05] *** gb_away <gb_away!~hhhhh@190.18.120.141> has joined ##OpenGL[05:40:00] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has joined ##OpenGL[05:43:18] *** pie___ <pie___!~pie_@unaffiliated/pie-/x-0787662> has joined ##OpenGL[05:45:42] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 250 seconds)[05:46:45] *** pie__ <pie__!~pie_@unaffiliated/pie-/x-0787662> has quit IRC (Ping timeout: 246 seconds)[05:49:33] <Stragus> chrisf: Dealing with 2 billion triangles today? ;)[05:53:08] *** charlie5 <charlie5!~rod@pa49-195-128-231.pa.nsw.optusnet.com.au> has joined ##OpenGL[05:58:18] *** cfoch <cfoch!uid153227@gateway/web/irccloud.com/x-iqdaqmldgeicmogc> has quit IRC (Quit: Connection closed for inactivity)[06:08:15] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[06:12:23] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[06:30:12] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[06:43:38] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[07:23:04] *** LunarJetman2 <LunarJetman2!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 250 seconds)[07:30:37] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[07:45:35] *** snyp <snyp!~Snyp@202.83.17.8> has joined ##OpenGL[08:04:52] *** krystcich <krystcich!~krystcich@088156132005.dynamic-ww-04.vectranet.pl> has joined ##OpenGL[08:22:29] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[08:29:48] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[08:30:04] *** Apeiron` <Apeiron`!~Apeiron@enigmavoid.com> has quit IRC (Quit: ZNC - http://znc.in - it's pretty ftw)[08:34:49] *** Apeiron` <Apeiron`!~Apeiron@enigmavoid.com> has joined ##OpenGL[08:39:05] *** bpmedley <bpmedley!~bpm@2600:1700:eb20:6050:f076:bdd9:61c7:18b7> has joined ##OpenGL[08:40:27] *** krystcich <krystcich!~krystcich@088156132005.dynamic-ww-04.vectranet.pl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))[08:43:34] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[08:54:22] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has joined ##OpenGL[09:07:48] *** Lord-Kamina <Lord-Kamina!~Lord-Kami@pc-250-87-104-200.cm.vtr.net> has quit IRC (Read error: Connection reset by peer)[09:10:27] *** Lord-Kamina <Lord-Kamina!~Lord-Kami@pc-250-87-104-200.cm.vtr.net> has joined ##OpenGL[09:24:01] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 255 seconds)[09:26:43] *** random_yanek <random_yanek!~random_ya@host-89-230-166-106.dynamic.mm.pl> has quit IRC (Ping timeout: 245 seconds)[09:26:45] *** Foaly <Foaly!~Foaly@ppp-88-217-62-223.dynamic.mnet-online.de> has joined ##OpenGL[09:30:36] *** bpmedley <bpmedley!~bpm@2600:1700:eb20:6050:f076:bdd9:61c7:18b7> has quit IRC (Ping timeout: 250 seconds)[09:38:39] *** charlie5 <charlie5!~rod@pa49-195-128-231.pa.nsw.optusnet.com.au> has quit IRC (Remote host closed the connection)[09:41:50] *** charlie5 <charlie5!~rod@pa49-195-128-231.pa.nsw.optusnet.com.au> has joined ##OpenGL[09:47:33] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 245 seconds)[09:51:59] *** charlie5 <charlie5!~rod@pa49-195-128-231.pa.nsw.optusnet.com.au> has quit IRC (Quit: Leaving.)[09:53:36] *** charlie5 <charlie5!~rod@pa49-195-128-231.pa.nsw.optusnet.com.au> has joined ##OpenGL[10:05:15] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##OpenGL[10:21:51] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has joined ##OpenGL[10:25:18] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Remote host closed the connection)[10:29:25] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[10:49:23] *** random_yanek <random_yanek!~random_ya@host-89-230-171-29.dynamic.mm.pl> has joined ##OpenGL[10:49:24] *** random_yanek <random_yanek!~random_ya@host-89-230-171-29.dynamic.mm.pl> has quit IRC (Max SendQ exceeded)[10:50:52] *** random_yanek <random_yanek!~random_ya@host-89-230-171-29.dynamic.mm.pl> has joined ##OpenGL[10:53:14] *** Foaly <Foaly!~Foaly@ppp-88-217-62-223.dynamic.mnet-online.de> has quit IRC (Quit: Now 'mid shadows deep falls blessed sleep.)[10:54:45] *** kraft <kraft!kraft@gateway/shell/blinkenshell.org/x-wgkqsqbloouywymu> has quit IRC (Ping timeout: 246 seconds)[11:08:56] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has quit IRC (Read error: Connection reset by peer)[11:10:10] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has joined ##OpenGL[11:48:24] *** Serus <Serus!~Serus@unaffiliated/serus> has quit IRC (Ping timeout: 250 seconds)[11:52:54] *** Serus <Serus!~Serus@unaffiliated/serus> has joined ##OpenGL[11:59:54] *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC (Ping timeout: 268 seconds)[12:02:36] *** slime <slime!~slime73@24.215.81.93> has joined ##OpenGL[12:13:43] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[12:27:22] *** snyp <snyp!~Snyp@202.83.17.8> has quit IRC (Ping timeout: 244 seconds)[12:29:29] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has quit IRC (Quit: Leaving)[12:33:54] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[12:34:24] *** Suchorski <Suchorski!~regex@unaffiliated/suchorski> has joined ##OpenGL[12:35:43] *** kraft <kraft!kraft@gateway/shell/blinkenshell.org/x-bfcrdirsfnofrdxb> has joined ##OpenGL[12:48:43] *** snyp <snyp!~Snyp@202.83.17.8> has joined ##OpenGL[12:59:37] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 245 seconds)[13:09:14] *** rocketmagnet <rocketmagnet!~username@unaffiliated/rocketmagnet> has quit IRC (Quit: WeeChat 1.6)[13:14:21] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[13:14:27] *** goiko <goiko!~goiko@unaffiliated/goiko> has quit IRC (Quit: ﴾͡๏̯͡๏﴿ O'RLY? Bye!)[13:14:43] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC ()[13:17:35] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[13:19:09] *** layeredcurkin <layeredcurkin!~reisima@2001:1530:1010:f7e4:1d50:c30d:530:fb46> has joined ##OpenGL[13:22:46] <layeredcurkin> I've read some of the AXI4 and PCI-E spec, there is even linux driver GPU developers documentation, both of them and also MMU have read-only and write-only flags for memory protection, in opengl clamped in-bounds but framebuffer incompleteness is done similarly i belive[13:23:43] <layeredcurkin> that ideally and very probably translates into accessing cache i.e leaving memory stale compared to uptodate cache on the chips[13:23:57] <layeredcurkin> cause write operation to memory can not succeed[13:24:44] <layeredcurkin> in many ways mlockall sort of semantics can be implemented albeit slightly different ways[13:26:33] <layeredcurkin> also with possible extension to make accessing all caches without hw support, i-cache access is a bit complex theory with fetch queue accesses, but should be doable[13:28:03] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[13:29:48] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has quit IRC (Read error: Connection reset by peer)[13:30:47] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[13:31:51] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has joined ##OpenGL[13:32:32] <layeredcurkin> generally I spotted from both of the specs, that there is exclusive transaction support for PCI-E and AXI4 buses, which does not mean that the bus can not be hijacked, but it guards a range of 4kb mmio space maximum with atomic operations support[13:36:02] <layeredcurkin> bus arbitration on chip works with certain methods, mostly there is a warp identifier 6-bits on latest cards, which starts from zero, and a decoder for those which starts from 1[13:36:56] <layeredcurkin> a decoder means a 40bit value in verilog, and it is filled with powers of two in decimal[13:38:13] <layeredcurkin> what i am saying is the whole chip is quite clearly human readable and gives lot of different but real ideas how to run the graphics chips properly like for performance etc.[13:39:30] *** LunarJetman2 <LunarJetman2!LunarJetma@5ec16e1a.skybroadband.com> has joined ##OpenGL[13:43:36] <layeredcurkin> the weakness how to access and fill i-buffers with user chosen content relies on inherent weakness of von neumann arch as i understand[13:44:01] <layeredcurkin> which means there is a hijackable bus for external memory interface[13:46:02] <layeredcurkin> it is not very much practiced or demonstrated in computer science, but it generally should work, there is a path for workqueues also from registers->L1>to i-buffer[13:46:50] <mangelis> ..what are you doing?[13:48:24] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 272 seconds)[13:49:52] *** snyp <snyp!~Snyp@202.83.17.8> has quit IRC (Ping timeout: 246 seconds)[13:51:44] <layeredcurkin> the point is, when you do things based closed to hw, by exploiting the circuit, the algorithms are quite easy, short and efficient, I did some gardening and will schedule an implemention of some methods in the drivers for coding them soon.[13:52:34] <layeredcurkin> some people have creativity crisis, and try to make sophisticated algorithms in the papers, which do not work well, that is why i tell it is easier to read the hw code even.[13:58:19] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[14:00:36] *** DarkUranium <DarkUranium!~DarkUrani@stdrand.com> has quit IRC (Read error: Connection reset by peer)[14:00:55] *** DarkUranium <DarkUranium!~DarkUrani@stdrand.com> has joined ##OpenGL[14:01:42] *** Yamakaja <Yamakaja!~yamakaja@vps.pub.yamakaja.me> has quit IRC (Remote host closed the connection)[14:01:45] *** Akari <Akari!~Akari@srsfckn.biz> has quit IRC (Quit: ZNC - https://znc.in)[14:02:06] *** Akari <Akari!~Akari@srsfckn.biz> has joined ##OpenGL[14:04:08] *** Yamakaja <Yamakaja!~yamakaja@vps.pub.yamakaja.me> has joined ##OpenGL[14:06:14] *** layeredcurkin <layeredcurkin!~reisima@2001:1530:1010:f7e4:1d50:c30d:530:fb46> has quit IRC (Read error: Connection reset by peer)[14:18:40] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[14:27:04] *** snyp <snyp!~Snyp@202.83.17.8> has joined ##OpenGL[14:35:55] *** layeredcurkin <layeredcurkin!~reisima@2001:1530:1010:f7e4:1d50:c30d:530:fb46> has joined ##OpenGL[14:41:22] *** hellozee <hellozee!~hellozee@116.73.36.92> has joined ##OpenGL[14:42:05] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Remote host closed the connection)[14:46:26] <layeredcurkin> I've done many of those theories which seem like nutter ones to some, but in reality this is how hw works, and hence they should mostly work too. All those were carefully studied from miaow code some of it from attilagpu and general computing theory.[14:47:05] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[14:50:47] <layeredcurkin> still i say i lack VLIW code, but since there is realworldtechs article which has it all, than i know how VLIW works too, those have even more resources and can not be considered aged in any way[14:54:37] <layeredcurkin> most of the earlier cards were by ATI tech now AMD, were laid out so: there were 20COREs nowdays CU each had 16way SIMD[14:54:52] <layeredcurkin> and SIMD may execute there 4to5instruction[14:55:18] <layeredcurkin> and with 32waves per 16way SIMD[14:55:30] <Yaniel> you should try writing a blog instead of spamming on IRC[14:57:19] <Yaniel> also it's rude to fill a channel's ban list by evading the ban masks[14:57:51] <Stragus> I wonder if it's a bot, there's a high non-sense to information ratio[14:58:44] <Yaniel> a rather sophisticated bot if so[14:59:09] <Stragus> Indeed, the grammar is good[14:59:44] <vmt> there was an estonian (? i think) guy around who was extremely nonsensical, some time ago[14:59:58] <Yaniel> yup, guess who this is[15:00:17] <vmt> said individual was boasting around with some kind of pioneering work he had done, the details of said work were really vague...[15:00:25] <vmt> oh yeah?[15:01:08] <Yaniel> just look at the freenode account they are using[15:01:17] <layeredcurkin> vmt: non sensical are you with Stragus....[15:01:19] <Yaniel> it matches 30% of the ban list of this channel[15:01:25] <vmt> i hardly think he's a bot in that sense, i had a short pm session with him[15:01:33] <vmt> in that case, rather[15:01:42] <Stragus> Maybe it's a human trying to fail the Turing test[15:02:13] *** ChanServ sets mode: +o Yaniel[15:02:22] *** Yaniel sets mode: +b $a:mardination[15:02:28] *** layeredcurkin was kicked by Yaniel (layeredcurkin)[15:02:34] *** Yaniel sets mode: -o Yaniel[15:02:55] <Yaniel> new freenode account in 5...[15:03:22] <derhass> I estimate it will take an hour or two[15:04:11] <Yaniel> guess I have time to grab lunch then[15:04:34] <Yaniel> (also I wouldn[15:04:44] <Yaniel> 't exactly call death threats "boasting")[15:05:54] <vmt> oh, i wasn't aware of such a thing. i only recall him boasting about doing some computer graphics related stuff a long time ago (10+ years), for ATI if memory serves[15:06:41] <vmt> <roundtheworld> i remember that "sensical" fucktard infact indeed, i think you were the one with the sexual propositions[15:06:59] <vmt> well, he's back. and i have never mentioned anything of the likes to him, oh well.[15:16:11] *** learningc <learningc!~learningc@2001:d08:d6:24d5:71b8:ca10:8c6d:5fae> has joined ##OpenGL[15:30:46] <Stragus> He certainly made an impression to remember him 10 years later[15:31:25] *** Suchorski <Suchorski!~regex@unaffiliated/suchorski> has quit IRC ()[15:31:35] <vmt> he exhibits the exact symptons of paranoid schizophrenia.[15:31:40] <vmt> symptoms, even[15:33:43] <vmt> i've been talking to him in pm for a while now. I hate the term, but I figure he's an incel. he's basically regarding this channel as a group of "cockblockers" who are trying to publicly ashame him, from getting any, even though he himself is "females' favorite". How did he get to this from cg, beats me[15:35:15] <vmt> anyway, soz for the ot. i'm done[15:36:22] <Stragus> "Publicly" shame him? Eh, now that's somewhat amusing[15:47:31] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has joined ##OpenGL[15:50:10] <s0laster> Can filling a VBO using transform feedback cause some artifacts when this VBO is used every frame by other draw calls?[15:50:54] <s0laster> I do have such artifacts by I'm not sure if its because of this VBO updates or something else...[15:51:34] <s0laster> Invalidating the VBO buffer using glBufferData() before using transform feedback on it doesn't improve the situation either[15:57:32] <Stragus> You can quickly check that by inserting a glFinish() before the transform feedback and the draws[16:00:10] *** snyp <snyp!~Snyp@202.83.17.8> has quit IRC (Ping timeout: 250 seconds)[16:04:44] <s0laster> Ah yes, good idea. It doesn't improve the situation so I guess the problem lies elsewhere[16:06:00] <Stragus> Yup, there you go. Most things are implicitely synchornized in OpenGL, unless specified otherwise[16:12:23] <s0laster> Well, removing the transform feedback pre-computing stuff and doing the computation everytime each frame does remove the artifacts, so it is somehow related to the transform feedback code...[16:15:26] <Stragus> You could grab the buffer and check the differences[16:15:37] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Quit: leaving)[16:22:17] *** thomasross_ <thomasross_!~thomasros@134.117.249.97> has joined ##OpenGL[16:22:18] *** thomasross <thomasross!~thomasros@134.117.249.97> has quit IRC (Killed (asimov.freenode.net (Nickname regained by services)))[16:22:18] *** thomasross_ is now known as thomasross[16:24:12] *** APK <APK!AKP@irc.akpwebdesign.com> has joined ##OpenGL[16:24:46] *** AKPWD <AKPWD!AKP@irc.akpwebdesign.com> has quit IRC (Ping timeout: 255 seconds)[16:25:13] *** kivutar <kivutar!~kivutar@95.130.13.198> has quit IRC (Ping timeout: 255 seconds)[16:25:13] *** ByronJohnson <ByronJohnson!~bairyn@unaffiliated/bob0> has quit IRC (Ping timeout: 255 seconds)[16:25:28] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has joined ##OpenGL[16:25:35] *** ByronJohnson <ByronJohnson!~bairyn@unaffiliated/bob0> has joined ##OpenGL[16:26:05] *** diwr <diwr!~diwr@unaffiliated/diwr> has joined ##OpenGL[16:27:48] *** zalt_ <zalt_!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[16:27:48] *** krystcich <krystcich!~krystcich@088156132232.dynamic-ww-04.vectranet.pl> has joined ##OpenGL[16:28:46] *** krystcich <krystcich!~krystcich@088156132232.dynamic-ww-04.vectranet.pl> has quit IRC (Client Quit)[16:29:57] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[16:30:43] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[16:31:14] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 268 seconds)[16:39:57] *** APK is now known as AKPWD[16:47:38] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 272 seconds)[16:59:36] *** hexagoxel <hexagoxel!~hexagoxel@hexagoxel.de> has quit IRC (Ping timeout: 268 seconds)[17:00:16] <s0laster> Okay, I nailed it, nooby mistake: TF use a different shader program and I forgot to set the right program when doing other drawcalls. The artifacts came from missing geometry and other stuff because of the wrong shader program in use[17:01:09] <s0laster> And updating the VBO and using it in the same frame looks okay now, as expected![17:03:26] <s0laster> Renderdocs really rocks[17:04:19] *** learningc <learningc!~learningc@2001:d08:d6:24d5:71b8:ca10:8c6d:5fae> has quit IRC (Read error: Connection reset by peer)[17:05:45] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[17:09:35] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##OpenGL[17:11:52] *** hexagoxel <hexagoxel!~hexagoxel@hexagoxel.de> has joined ##OpenGL[17:19:13] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has quit IRC (Ping timeout: 245 seconds)[17:20:21] *** moser <moser!~moser@113.68.195.44> has joined ##OpenGL[17:23:39] *** moser_ <moser_!~moser@116.22.6.104> has quit IRC (Ping timeout: 268 seconds)[17:24:01] *** mukunda <mukunda!~mukunda@cpe-104-175-176-150.socal.res.rr.com> has joined ##OpenGL[17:28:41] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has joined ##OpenGL[17:37:57] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[17:42:38] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has quit IRC (Quit: *waves frantically*)[17:44:14] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##OpenGL[17:49:35] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[17:54:11] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[17:59:26] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[18:11:07] *** snyp <snyp!~Snyp@1.39.174.106> has joined ##OpenGL[18:15:55] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[18:17:25] *** zalt_ is now known as zalt[18:25:52] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[18:36:11] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Remote host closed the connection)[18:36:30] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##OpenGL[18:37:18] *** phloris <phloris!~psj@ip5456839b.speed.planet.nl> has joined ##OpenGL[18:44:21] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 256 seconds)[18:47:13] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC ()[18:55:48] *** xx2 <xx2!~xx2@212.253.8.72> has joined ##OpenGL[19:11:26] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined ##OpenGL[19:25:11] *** davr0s <davr0s!~textual@host81-147-72-11.range81-147.btcentralplus.com> has joined ##OpenGL[19:26:56] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##OpenGL[19:26:56] *** KAHR-Alpha <KAHR-Alpha!~Alpha@2a01cb0d024a6600dc725e1df7510b81.ipv6.abo.wanadoo.fr> has joined ##OpenGL[19:36:55] *** krystcich <krystcich!~krystcich@088156132232.dynamic-ww-04.vectranet.pl> has joined ##OpenGL[19:54:25] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has quit IRC (Quit: Leaving)[19:56:29] *** Foaly <Foaly!~Foaly@ppp-88-217-93-113.dynamic.mnet-online.de> has joined ##OpenGL[20:18:53] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[20:21:46] *** slvn_ <slvn_!~slvn_@c2s31-1-78-245-90-111.fbx.proxad.net> has joined ##OpenGL[20:36:47] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[20:50:02] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[20:53:15] *** slvn_ <slvn_!~slvn_@c2s31-1-78-245-90-111.fbx.proxad.net> has quit IRC (Quit: Leaving)[20:55:07] *** LunarJetman2 <LunarJetman2!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 246 seconds)[20:55:44] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has joined ##OpenGL[21:07:32] *** snyp <snyp!~Snyp@1.39.174.106> has quit IRC (Ping timeout: 245 seconds)[21:08:29] *** snyp <snyp!~Snyp@1.39.174.106> has joined ##OpenGL[21:10:50] *** daidai-san <daidai-san!~daidai-sa@240f:38:41e7:1:e8d5:867b:594a:14e1> has joined ##OpenGL[21:14:17] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[21:14:56] *** RobertPlummer <RobertPlummer!aee702e6@gateway/web/freenode/ip.174.231.2.230> has joined ##OpenGL[21:16:49] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[21:19:19] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##OpenGL[21:21:43] *** daidai-san <daidai-san!~daidai-sa@240f:38:41e7:1:e8d5:867b:594a:14e1> has left ##OpenGL ("Leaving")[21:29:25] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has quit IRC (Ping timeout: 255 seconds)[21:31:00] *** RobertPlummer <RobertPlummer!aee702e6@gateway/web/freenode/ip.174.231.2.230> has quit IRC (Quit: Page closed)[21:37:46] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has joined ##OpenGL[21:42:08] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has quit IRC (Ping timeout: 245 seconds)[21:53:32] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has joined ##OpenGL[21:56:45] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Remote host closed the connection)[21:56:45] *** iCherry <iCherry!iCherry@gateway/shell/suchznc/x-qdzbhzycpstosyhm> has quit IRC (Quit: Bai Bai Bambi)[21:57:31] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[21:58:30] *** iCherry <iCherry!iCherry@gateway/shell/suchznc/x-jequfihxswxeeqet> has joined ##OpenGL[21:59:16] *** wildlander <wildlander!~wildlande@unaffiliated/wildlander> has joined ##OpenGL[22:00:18] *** KAHR-Alpha is now known as Guest49703[22:00:20] *** KAHR-Alpha_ <KAHR-Alpha_!~Alpha@2a01cb0d024a6600dc725e1df7510b81.ipv6.abo.wanadoo.fr> has joined ##OpenGL[22:00:42] *** Foaly <Foaly!~Foaly@ppp-88-217-93-113.dynamic.mnet-online.de> has quit IRC (Quit: Now 'mid shadows deep falls blessed sleep.)[22:03:29] *** Guest49703 <Guest49703!~Alpha@2a01cb0d024a6600dc725e1df7510b81.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 259 seconds)[22:11:51] *** Alpha_ <Alpha_!~Alpha@2a01cb0d024a6600dc725e1df7510b81.ipv6.abo.wanadoo.fr> has joined ##OpenGL[22:11:57] *** ratchetfreak_ <ratchetfreak_!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##OpenGL[22:14:59] *** KAHR-Alpha_ <KAHR-Alpha_!~Alpha@2a01cb0d024a6600dc725e1df7510b81.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 258 seconds)[22:15:22] *** ratchet_freak <ratchet_freak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 258 seconds)[22:22:09] *** cocholate <cocholate!~cppfag@179.178.210.74> has joined ##OpenGL[22:23:52] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined ##OpenGL[22:40:08] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Ping timeout: 244 seconds)[22:40:59] *** eetsi123 <eetsi123!~eetu@91.152.205.56> has joined ##OpenGL[23:02:24] *** snyp <snyp!~Snyp@1.39.174.106> has quit IRC (Ping timeout: 246 seconds)[23:06:01] *** hellozee <hellozee!~hellozee@116.73.36.92> has quit IRC (Ping timeout: 246 seconds)[23:17:32] *** cocholate <cocholate!~cppfag@179.178.210.74> has quit IRC (Quit: cocholate)[23:23:44] *** fr3tz0r <fr3tz0r!~snigelfar@185.183.146.196> has joined ##OpenGL[23:28:59] <fr3tz0r> hi[23:33:39] <derhass> hi[23:34:50] <fr3tz0r> I want a separate function in the vertex shader to take float *f1, float *f2 as input arguments but I get compilation error in the vertex shader when doing this. The function is called from main in vertex shader.Suggestions?[23:38:21] <Yaniel> post code[23:38:31] *** s0laster <s0laster!~needs@119.160.9.93.rev.sfr.net> has joined ##OpenGL[23:46:26] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[23:57:30] <derhass> fr3tz0r: there are no pointers in GLSL