July 28, 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 | >
July 28, 2019 [00:00:09] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Quit: Leaving)[00:00:36] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[00:02:08] *** Singmyr <Singmyr!~Singmyr@c83-253-123-62.bredband.comhem.se> has joined ##OpenGL[00:06:31] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Quit: Leaving)[00:14:04] *** LunarJetman <LunarJetman!LunarJetma@176.248.197.112> has left ##OpenGL[00:28:29] *** reductum <reductum!~weechat@cpe-104-32-77-28.socal.res.rr.com> has quit IRC (Quit: WeeChat 2.5)[00:48:08] *** toor_ <toor_!~toor@ppp-seco21parth2-46-193-164-233.wb.wifirst.net> has quit IRC (Read error: Connection reset by peer)[00:48:29] *** toor_ <toor_!~toor@ppp-seco21parth2-46-193-164-233.wb.wifirst.net> has joined ##OpenGL[00:51:17] *** toor_ <toor_!~toor@ppp-seco21parth2-46-193-164-233.wb.wifirst.net> has quit IRC (Read error: Connection reset by peer)[01:04:58] *** toor_ <toor_!~toor@ppp-seco21parth2-46-193-164-233.wb.wifirst.net> has joined ##OpenGL[01:05:58] *** Foaly <Foaly!~Foaly@ppp-88-217-60-86.dynamic.mnet-online.de> has quit IRC (Quit: When in doubt, hit it with the wrench.)[01:15:28] *** ra4king <ra4king!~ra4king@unaffiliated/ra4king> has quit IRC (Quit: Take a byte out of this!)[01:15:58] *** ra4king <ra4king!~ra4king@unaffiliated/ra4king> has joined ##OpenGL[01:26:54] *** ra4king <ra4king!~ra4king@unaffiliated/ra4king> has quit IRC (Quit: Take a byte out of this!)[01:28:57] *** ra4king <ra4king!~ra4king@unaffiliated/ra4king> has joined ##OpenGL[01:42:03] *** Danishman <Danishman!~kvirc@62-243-156-218-dynamic.dk.customer.tdc.net> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)[02:34:22] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[02:52:09] *** Singmyr <Singmyr!~Singmyr@c83-253-123-62.bredband.comhem.se> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)[02:53:33] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has quit IRC (Quit: Leaving)[03:12:43] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[03:17:01] *** macroprep_ <macroprep_!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[03:20:02] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Ping timeout: 245 seconds)[03:20:53] *** DMJC <DMJC!~DMJC@121.208.48.187> has joined ##OpenGL[03:21:34] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 246 seconds)[03:24:20] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 268 seconds)[03:34:26] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[03:34:58] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 276 seconds)[03:37:48] <macroprep_> hi[03:43:30] *** immibis <immibis!~immibis@222.153.90.196> has joined ##OpenGL[03:44:31] <macroprep_> so, as i said, https://github.com/mgood7123/AndroidCompositor/blob/d0238349385f8146146f698ef3bbb528e7c3ef95/app/src/main/jni/jniapi.cpp#L202 does nothing, why might that be?[03:50:57] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[03:51:02] *** macroprep__ <macroprep__!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[03:54:01] *** macroprep_ <macroprep_!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Ping timeout: 244 seconds)[03:58:53] *** macroprep__ is now known as macroprep[04:07:53] *** hk239^2 <hk239^2!~d@94.22.235.202> has joined ##OpenGL[04:10:03] *** hk239 <hk239!~d@94.22.235.202> has quit IRC (Ping timeout: 245 seconds)[04:10:41] *** David3k <David3k!~David3k@120.29.75.241> has joined ##OpenGL[04:11:43] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 245 seconds)[04:15:28] *** David3k <David3k!~David3k@120.29.75.241> has quit IRC (Client Quit)[04:15:36] *** DMJC <DMJC!~DMJC@121.208.48.187> has quit IRC (Read error: Connection reset by peer)[04:15:43] *** David3k <David3k!~David3k@120.29.75.241> has joined ##OpenGL[04:23:53] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[04:43:19] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has joined ##OpenGL[04:52:35] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Quit: Leaving)[05:05:00] *** macroprep <macroprep!~smallvill@172.193.104.55> has joined ##OpenGL[05:30:23] *** manj-budgie_ <manj-budgie_!~manjaro-b@x4db749b9.dyn.telefonica.de> has joined ##OpenGL[05:34:27] *** VladTheImplier <VladTheImplier!~manjaro-b@x590e3fe2.dyn.telefonica.de> has quit IRC (Ping timeout: 268 seconds)[05:55:47] *** Vasco_O is now known as Vasco[06:04:25] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[06:06:20] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has quit IRC (Read error: Connection reset by peer)[06:08:01] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has joined ##OpenGL[06:21:02] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has joined ##OpenGL[06:22:34] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has left ##OpenGL[06:22:43] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Read error: Connection reset by peer)[06:45:06] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Ping timeout: 258 seconds)[06:49:20] <wrobinson> macroprep: does the second window for WM[1] get created?[06:49:57] <wrobinson> nvm[06:53:19] <wrobinson> (this probably won't fix, but) for window w2, shouldn't it be initialised with {1,500,0,500,500} ?[06:55:37] <wrobinson> macroprep: does your log show everything as expected, but you just get blank screen?[06:56:30] <macroprep> ill check in a few[06:58:31] <wrobinson> no rush[06:59:21] <wrobinson> also, maybe log error and return false if create_context(WM[0]) fails.[07:00:59] <wrobinson> nvm - currently dealt with inside create_context()[07:01:33] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[07:03:15] <wrobinson> I'm not experienced at all with pthread, but looks like a race-condition exists when creating contexts[07:11:32] <wrobinson> macroprep: https://stackoverflow.com/questions/11726650/egl-can-context-be-shared-between-threads[07:12:28] <wrobinson> it appears though that multiple contexts and using eglMakeCurrent is quite expensive[07:13:01] <wrobinson> I'm also not sure that if you use this method, that you require the use of scissor and viewport for each WM[07:17:05] <macroprep> wrobinson, you have android right?[07:17:30] <wrobinson> a note for shared_context: https://github.com/google/grafika/issues/36[07:17:53] <wrobinson> macroprep: I did, but do not currently - also have not set up emulator[07:18:12] <macroprep> ok[07:19:54] <wrobinson> more java related but contains some useful info: https://exceptionshub.com/textureview-vs-glsurfaceview-or-how-to-use-glsurfaceview-with-egl14.html[07:23:52] *** tabbk <tabbk!~mantra@2601:601:c980:8fd:3166:e3f7:55c7:6752> has quit IRC (Read error: Connection reset by peer)[07:36:26] *** manj-budgie_ <manj-budgie_!~manjaro-b@x4db749b9.dyn.telefonica.de> has quit IRC (Quit: Leaving)[07:36:39] *** manj-budgie_ <manj-budgie_!~manjaro-b@x4db749b9.dyn.telefonica.de> has joined ##OpenGL[07:36:46] *** manj-budgie_ is now known as VladTheImplier[07:36:53] *** VladTheImplier <VladTheImplier!~manjaro-b@x4db749b9.dyn.telefonica.de> has quit IRC (Client Quit)[07:37:07] *** VladTheImplier <VladTheImplier!~manjaro-b@x4db749b9.dyn.telefonica.de> has joined ##OpenGL[07:47:57] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Ping timeout: 245 seconds)[07:51:06] *** Singmyr <Singmyr!~Singmyr@c83-253-123-62.bredband.comhem.se> has joined ##OpenGL[07:55:29] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[07:58:16] *** hk239^2 <hk239^2!~d@94.22.235.202> has quit IRC (Quit: Leaving)[07:58:40] *** hk239 <hk239!~d@94.22.235.202> has joined ##OpenGL[08:06:30] *** dansho <dansho!~dansho4@71-84-161-204.dhcp.astr.or.charter.com> has joined ##OpenGL[08:29:17] *** dansho <dansho!~dansho4@71-84-161-204.dhcp.astr.or.charter.com> has quit IRC (Remote host closed the connection)[08:29:43] *** dansho <dansho!~dansho4@71-84-161-204.dhcp.astr.or.charter.com> has joined ##OpenGL[08:51:18] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has quit IRC (Remote host closed the connection)[09:05:32] *** Foaly <Foaly!~Foaly@ppp-88-217-65-4.dynamic.mnet-online.de> has joined ##OpenGL[09:06:29] *** reductum <reductum!~weechat@cpe-104-32-77-28.socal.res.rr.com> has joined ##OpenGL[09:23:20] *** Foaly <Foaly!~Foaly@ppp-88-217-65-4.dynamic.mnet-online.de> has quit IRC (Quit: When in doubt, hit it with the wrench.)[09:30:52] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 245 seconds)[09:37:02] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[09:39:03] *** LunarJetman <LunarJetman!LunarJetma@176.248.197.112> has joined ##OpenGL[09:50:36] *** wrobinso1 <wrobinso1!~0x@196.20.158.243> has joined ##OpenGL[09:52:52] *** wrobinson <wrobinson!~0x@102.119.215.22> has quit IRC (Ping timeout: 246 seconds)[10:16:37] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Read error: Connection reset by peer)[10:20:39] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[10:44:32] *** reductum <reductum!~weechat@cpe-104-32-77-28.socal.res.rr.com> has quit IRC (Quit: WeeChat 2.5)[11:01:34] *** David3k <David3k!~David3k@120.29.75.241> has quit IRC (Quit: SOUUUUUUULS)[11:11:50] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[11:35:02] *** ville <ville!~ville@212-149-214-47.bb.dnainternet.fi> has quit IRC (Quit:)[11:36:53] *** ville <ville!~ville@212-149-214-47.bb.dnainternet.fi> has joined ##OpenGL[11:46:07] *** Kingsquee <Kingsquee!~kingsquee@node-1w7jr9qmxqrpow98mke9t5qou.ipv6.telus.net> has quit IRC (Quit: https://i.imgur.com/qicT3GK.gif)[11:47:04] *** markweston <markweston!~markwesto@78-62-196-119.static.zebra.lt> has joined ##OpenGL[11:49:12] <markweston> Hi! I want to learn geomtry algorithms. For example, how to cut a triangle into a polygon such that it does not intersect a line segment: https://imgur.com/rsqHKer . The red line is the line segment. The blue triangle is the triangle. The green polygon is the new polygon cut from the triangle which does not intersect the line segment. Could you recommend a book that teaches stuff like this? Thanks![12:04:33] *** macroprep <macroprep!~smallvill@172.193.104.55> has quit IRC (Remote host closed the connection)[12:07:35] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[12:08:02] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Read error: Connection reset by peer)[12:09:10] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[12:13:16] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Client Quit)[12:26:30] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[12:31:33] <nilspin> I have a buffer of objects defined as : __align(8)__ struct Vox{ float sdf; uchar weight;} from CUDA[12:32:08] <nilspin> I am trying to bind them as SSBO and read them inside my fragmebt shader[12:32:50] <nilspin> but nothing gets rendered, I'm trying to cross of alignment-issues as one of possible culprits[12:33:12] <nilspin> glsl doesn't seem to support char[12:33:37] <Yaniel> https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL)#Memory_layout[12:34:38] <Yaniel> and yes, no chars[12:35:21] <Yaniel> uint is the closest thing you get but that is 32 bits[12:36:54] <nilspin> Yaniel: the CUDA struct is aligned to 8 bytes, so I'm wasting 3 bytes anyways. reading the char as glsl int should work, right?[12:37:13] <Yaniel> why not change it to uint32 to begin with[12:37:46] <nilspin> I'll try that.[12:38:05] <Yaniel> bytes will be wasted either way but at least that should be compatible[12:46:30] <nilspin> No change. Problem lies elsewhere :([13:01:29] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Remote host closed the connection)[13:14:16] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has joined ##OpenGL[13:14:18] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##OpenGL[13:31:14] <macroprep> https://open.gl/framebuffers can this be applied to any kind of OpenGL program[13:31:23] <macroprep> as i am not sure how to apply it to mine[13:32:15] * macroprep builds[13:33:07] <derhass> macroprep: it is a GL feature, so you can use it in GL programs[13:33:20] <Yaniel> you don't "apply" it to a program after the fact[13:33:26] <Yaniel> you build the program to use it[13:33:35] <Yaniel> from the start[13:33:43] <derhass> macroprep: you just need to make sure that the implementation you're running on does have these features[13:35:24] <macroprep> as if i try to compile this https://del.dog/naxitaxiqa.txt i get...[13:36:17] <macroprep> the following undefines:[13:36:27] <derhass> use a proprer GL loader[13:37:02] <macroprep> glGenFramebuffers glGenRenderbuffers GL_RENDERBUFFER GL_DEPTH24_STENCIL8 GL_FRAMEBUFFER GL_DEPTH_STENCIL_ATTACHMENT glDeleteFramebuffers[13:37:39] <macroprep> would this mean the implementation does not support frame buffers[13:38:09] <Yaniel> more likely it means that you still don't have a clue of what you are doing[13:39:24] <macroprep> btw i know that the code in particular will likely crash[13:39:31] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[13:39:43] <Yaniel> why?[13:40:16] <macroprep> for example, if i can compile and execute "GLuint frameBuffer; glGenFramebuffers(1, &frameBuffer); glDeleteFramebuffers(1, &frameBuffer);" then that would mean that i can at lease use a frame buffer right?[13:40:29] <Yaniel> wat[13:40:46] <macroprep> (unless those are stubbed in the particular implementation)[13:40:56] <macroprep> eg do nothing[13:41:52] <Yaniel> that... is not how this works[13:42:19] <macroprep> as i am currently using https://open.gl/framebuffers, OpenGL ES version 1 and OpenGL EGL[13:43:01] <macroprep> (i do have access to OpenGL ES 3 )[13:46:30] <macroprep> nvm[13:46:47] <macroprep> what do i need to do in order to obtain the glGenFramebuffers function[13:47:20] <macroprep> Yaniel,[13:51:31] <Yaniel> use a loader like derhass said[13:54:14] <macroprep> https://www.khronos.org/opengl/wiki/OpenGL_Loading_Library this?[13:58:09] <derhass> first of all: GLES 1.x? seriously?[13:58:23] <derhass> forget that this thing even existed[13:58:23] <macroprep> derhass, yes[13:58:38] * derhass runs away screaming[13:58:42] <macroprep> o.o[13:59:23] <macroprep> specifically GLESv1_CM[13:59:38] * derhass can still be heard screaming[14:00:29] * macroprep should i link against GLESv3 instead[14:00:29] <wrobinso1> macroprep: I think if you are just getting started with OpenGL, you should probably steer very clear of deprecated code/specs[14:00:37] *** wrobinso1 is now known as wrobinson[14:01:14] <Yaniel> and probably shouldn't try writing window managers for android[14:03:28] <derhass> macroprep: no[14:03:50] <derhass> GLES1 and GLES >= 2.x are _totally incompatible_ to each other[14:04:55] <macroprep> oh[14:06:25] <macroprep> welp 90% of the gl code is invalid now x.x[14:06:33] <derhass> there are only bvery few good things I can say about GLES 2.0, but the fact that it completely removed that old crap (instead of just deprecating it) is definitively one of them.[14:06:34] <wrobinson> back to drawing board[14:06:41] <derhass> macroprep: invalid now?[14:06:47] <derhass> invalid since decades[14:07:12] <macroprep> IDE fails to resolve references[14:07:27] <macroprep> Can't resolve variable 'glMatrixMode'[14:07:33] <derhass> good[14:08:40] <derhass> welcome in 2004[14:08:45] <macroprep> :P[14:09:18] <macroprep> so should i try to convert the existing GL1 code into GL3 code? or should i just try to start from scratch[14:09:45] <Yaniel> try to decide whether you mean GL or GLES for starters[14:09:50] <derhass> maybe you should start by learning the basics first[14:09:56] <Yaniel> the two aren't compatible either[14:10:24] <macroprep> GLES[14:11:23] <macroprep> as i DO have existing GLES v3 code but... im not sure how easy that would be to copy and paste[14:11:36] <wrobinson> I'm working through the tutorial mentioned in the topic here - it really is a good place to start (even if I'm re-covering some old ground)[14:12:02] <Yaniel> if copying and pasting is your first worry then you are doing it wrong[14:12:31] <derhass> wrobinson: well, they are not too bad, if you like the tutorial-style way of learning things[14:12:48] <wrobinson> i have some issues, but it's not bad content[14:13:11] <Yaniel> I recommend raising those issues on their github[14:13:12] <macroprep> tho i suppose i can get away with only displaying a coloured viewport and eliminate the fancy rotating multicolour cube[14:13:22] <derhass> wrobinson: I'd also throw in https://alfonse.bitbucket.io/oldtut/ as another tutrial-like ressource[14:13:39] <wrobinson> derhass: thanks[14:13:48] <derhass> (and don't be confused by the "oldtut", it is teaching the modern way, just the modern way is a decade old by now already)[14:13:55] <wrobinson> Yaniel: I probably should. I assume you mean in order to be helpful :)[14:14:24] <Yaniel> yes, and obviously to get rid of your issues with the tutorials[14:14:24] <wrobinson> derhass: no worries. I've had my share of deciphering what "modern" OpenGL looks like[14:14:40] <wrobinson> Yaniel: :)[14:14:47] <macroprep> which leaves me with only GL_PERSPECTIVE_CORRECTION_HINT and glShadeModel undefined, in which these would not be required in order to display the viewport right?[14:15:11] <wrobinson> right[14:15:18] <derhass> "display the viewport" is t totally nonsensical phrase in GL terms[14:16:44] <derhass> the viewport is just an axis-aligne rectangular region which might intersect the framebuffer, and what is typically displayed is the back buffer of the default framebuffer, and that is always displayed no matter what actions you take to fill it with data[14:17:28] *** DMJC <DMJC!~DMJC@121.208.48.187> has joined ##OpenGL[14:18:01] <macroprep> for example this would be all i need in order to display something right? glEnable(GL_SCISSOR_TEST); glScissor(X,Y,W,H); glClearColor(0.0f, 1.0f, 1.0f, 1.0f); glViewport(X,Y,W,H);[14:18:16] <derhass> wrong[14:18:27] <derhass> all that does is set a bit of state[14:18:34] <derhass> it does not change any framebuffer contents[14:19:02] <derhass> also, the whole glViewport call there is probably totally moot for what you trying to do[14:19:14] <macroprep> oh[14:19:14] <derhass> and that is funny, as that perfectly fits to my previous statement[14:19:43] <derhass> you probably want to do just a scissored glClear[14:20:06] <derhass> so you need to enable scissort test, set the scissort rect, set a clear color, _and do the actual clear operation_[14:20:20] <derhass> the viewport will have _no effect on that whatsoever_[14:21:20] <derhass> the viewport state is applied during the vertex transformation[14:21:46] <derhass> and it is just a scale and a translation, so a simple multiply-add per dimension[14:22:06] <wrobinson> derhass: other than tutorials, I tend to learn by picking apart other code (not great when learning OpenGL) and by just trying to do my own project (which with OpenGL definitiely meant researching tutorials)[14:22:25] <wrobinson> if you have some other suggestions, I'm all ears - I'm open to trying other approaches[14:22:34] <derhass> wrobinson: do whatever works best for you[14:23:14] <derhass> wrobinson: looking at other programs is always interesting, but you should be careful not to pick up bullshit concepts and get to cargo-cult-programming[14:23:45] <wrobinson> fair point. I was only getting at that if you're aware of a method I'm not, it would be hard to know if what I do so far is "best for me"[14:23:54] <wrobinson> (hope that doesn't sound snarky, I mean it honestly)[14:24:09] <derhass> wrobinson: while it probably is not a good idea hto start there from the beginning, I actually recommend looking into the actual GL specs[14:24:11] <wrobinson> yeah, that's been a fear of mine over the years, particularly with cpp[14:24:59] <wrobinson> derhass: I'm going to have to at some point. I actually downloaded a couple. Haven't had the strength to get into them yet :/[14:26:15] <macroprep> derhass, ok[14:27:25] <macroprep> so all this is NOT rendered to a frame buffer correct?[14:28:01] <derhass> macroprep: wrong[14:28:37] <macroprep> since it does not change any of the framebuffer contents[14:29:04] <derhass> macroprep: so you mean just your state changes above?[14:29:17] <derhass> the ppint there is that nothing is rendered at all by that[14:29:28] <derhass> so it doesn't really matter to where it is not rendered[14:31:22] <derhass> macroprep: some thing I can recommend is when looking for information about a particular GL feature, it might be a good idea to look at the _extension_ spec even if you care about a core feature[14:31:26] <derhass> sorry[14:31:39] <derhass> s/macroprep/wrobinson[14:32:45] <macroprep> so glclear modifies the specified buffer right? in which "The pixel ownership test, the scissor test, dithering, and the buffer writemasks affect the operation of glClear. The scissor box bounds the cleared region. Alpha function, blend function, logical operation, stenciling, texture mapping, and depth-buffering are ignored by glClear. "[14:33:14] <derhass> wrobinson: extension specs often have more background information, sometimes really interesting "issues sections" which sometimes explains _why_ things are done in particular way (which the spec never states), and also, the particular info on a single feature is often spread out into different sections and chapters, but in the extension spec, one can see all of that in one place[14:33:33] <derhass> macroprep: yes[14:33:59] <macroprep> in which the frame buffer itself is just the combination of the colour buffer, accumulation buffer, and stencil buffer correct?[14:34:14] <derhass> there are some other states that affect the clear, especially the DRAW_BUFFER and DRAW_FRAMEBUFFER ones[14:34:25] <macroprep> (and possibly the depth buffer aswell)[14:34:51] <derhass> macroprep: kind of[14:37:36] <macroprep> how so[14:38:48] *** markweston <markweston!~markwesto@78-62-196-119.static.zebra.lt> has quit IRC (Remote host closed the connection)[14:38:49] <derhass> well, there can be multiple color buffers in a framebuffer[14:39:00] <derhass> also, accumulation buffer isn't a thing anymore[14:39:56] <macroprep> ok, so what would be in a default frame buffer[14:40:15] <derhass> what you have chosen when creating it[14:40:51] <macroprep> ok[14:40:57] <derhass> a defualt framebuffer can have one to 4 color buffers, and optionally depth and/or stencil[14:41:23] *** slvn_ <slvn_!~slvn_@2a01:e34:ef55:a6f0:e8e4:7e10:92a3:a181> has joined ##OpenGL[14:42:11] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has joined ##OpenGL[14:44:06] <macroprep> ok, in order to render offscreen a new frame buffer must be created right?[14:44:38] <Yaniel> correct[14:44:44] <derhass> not necessarily[14:44:54] <derhass> the default framebuffer can also be an offscreen surface[14:45:11] <macroprep> oh[14:45:25] <derhass> depending on how you create it, again[14:45:39] <derhass> but that is totally plattfrom-specific[14:45:46] <Yaniel> derhass: I'll leave you to ELI5 that[14:46:16] <macroprep> can both be used to render to a surface?[14:46:40] <macroprep> eg render offscreen then draw once rendering is complete[14:46:44] <Yaniel> both what[14:46:52] <derhass> Yaniel: I see what you mean...[14:47:09] <Yaniel> derhass: guess what has been going on for the past 2-3 days[14:47:49] <macroprep> or would an offscreen surface and a framebuffer serve different purposes[14:48:13] <derhass> probably[14:48:30] <derhass> you wouldn't bother creating an offscreen surface when you want to display something in the end[14:48:42] <macroprep> ok[14:49:41] <macroprep> once correctly created it should be binded via glBindFramebuffer(GL_FRAMEBUFFER, frameBuffer); right?[14:50:26] <macroprep> after verifying with glCheckFramebufferStatus[14:52:12] <derhass> more or less[14:52:42] <derhass> I definitively prefer using explicitely GL_READ_FRAMEBUFFER and GL_DRAW_FRAMEBUFFER binding targets[14:54:42] <macroprep> for example[14:54:44] <macroprep> GLuint frameBuffer; glGenFramebuffers(1, &frameBuffer); /* bind buffers */ if (glCheckFramebufferStatus(1) == GL_FRAMEBUFFER_COMPLETE) glBindFramebuffer(GL_DRAW_FRAMEBUFFER, frameBuffer); else glDeleteFramebuffers(1, &frameBuffer);[14:55:04] *** immibis <immibis!~immibis@222.153.90.196> has quit IRC (Ping timeout: 272 seconds)[14:56:21] <macroprep> in which operations such as glClear would modify frameBuffer instead of the default frameBuffer right? or would i need to do more that https://open.gl/framebuffers does not seem to specify[14:56:58] <Yaniel> yes, you need to attach something that has memory to the framebuffer[14:57:09] <macroprep> ok[14:57:50] <macroprep> how would i do so[14:58:09] <derhass> macroprep: glClear affects the currently bound GL_DRAW_FRAMEBUFFER, like all other operations which do modify the framebuffer contents[14:59:06] <macroprep> derhass, so it would modify frameBuffer instead of GLES's default frame buffer?[14:59:46] <derhass> it is not "GLES' default framebuffer". the default framebuffer is part of the _drawable_ your context is currently bound to, so a window or whatever else[15:00:01] <derhass> the default framebuffer is _not_ part of the GL context[15:01:23] <macroprep> ok[15:02:49] <macroprep> would that be a surface or a display?[15:03:32] <wrobinson> derhass: thanks a lot for that pointer - never thought to look at extension specs, being that I figured I could do my best to stick to core features[15:06:05] *** dansho <dansho!~dansho4@71-84-161-204.dhcp.astr.or.charter.com> has quit IRC (Quit: Leaving)[15:08:25] <macroprep> wait it would be the surface right? as per "<derhass> the default framebuffer can also be an offscreen surface"[15:10:53] <derhass> macroprep: it would be whatever you have set it up to be[15:13:13] <macroprep> ok, so how i complete the frame buffer?[15:13:49] <derhass> complete?[15:13:52] <macroprep> as i currently have nothing binded to the buffer[15:14:15] <derhass> so what are you talking about now?[15:14:18] <macroprep> in which glCheckFramebufferStatus(1) does not return GL_FRAMEBUFFER_COMPLETE[15:14:19] <derhass> FBOs?[15:14:31] <macroprep> i think so[15:14:48] <derhass> why 1?[15:15:07] <macroprep> i dont know, im just following https://open.gl/framebuffers[15:15:50] <derhass> and which part don't you understand?[15:16:06] <derhass> isn't that exactly answering the question you're asking?[15:16:15] <macroprep> as i currently have no use for binding a texture since i do not use any and i have no use for a renderer as i do not use any either (i think)[15:17:10] <mefesto> so the default framebuffer is all you need?[15:17:40] <derhass> macroprep: I don't even understand the question then[15:17:45] <Yaniel> aaaaaaaaaaaAAAAAAAAAAAAA[15:17:47] *** Yaniel <Yaniel!yaniel@unaffiliated/yaniel> has left ##OpenGL ("WeeChat 2.6-dev")[15:18:25] <macroprep> im trying to get glClear to work offscreen so i can then attempt to render it[15:18:41] <derhass> what?[15:20:27] <macroprep> im trying to make a Compositor[15:20:29] <zid> you know he's a troll right?[15:20:39] <zid> and he's been warned heavily[15:20:50] *** zid <zid!zid@muf.violates.me> has left ##OpenGL[15:22:05] <macroprep> are framebuffers the wrong thing i need? as both Xorg and wayland sujjest that i use frame buffers (FBOS) to render seperate "windows"[15:22:06] <derhass> macroprep: then, we're back at "14:09:49 < derhass> maybe you should start by learning the basics first"[15:22:08] <macroprep> suggest*[15:22:57] <macroprep> as i tried using surface's instead but that did not seem to work[15:23:34] <macroprep> eg swapping the display and surface of app1 and app2 in a while loop[15:24:07] <derhass> whatever that even means[15:27:26] <macroprep> binding a render buffer didnt seem to cause the frame buffer to be complete[15:28:10] <macroprep> glBindFramebuffer needs to be called AFTER glCheckFramebufferStatus right?[15:28:21] <derhass> https://www.khronos.org/opengl/wiki/Framebuffer_Object#Framebuffer_Completeness[15:28:37] <macroprep> eg to avoid binding an incomplete framebuffer[15:28:53] <derhass> macroprep: totally wrong[15:30:03] <derhass> since you used the non-DSA glGenFramebuffers, the FBO doesn't even _exist_ before it is first bound[15:30:24] <derhass> and you can't possibly have attached something to it wothout it even existing[15:30:56] <macroprep> oh[15:30:56] <derhass> and glCheckFramebufferStatus of course works on the currenltly bound FBO[15:31:37] <macroprep> so the currently bound (default) FBO itself is incomplete?[15:31:51] <macroprep> is that even possible?[15:32:21] <macroprep> or would that be part of initializing OpenGL itself[15:33:29] <macroprep> if so how is my program still able to display pixels if it has an incomplete frame buffer?[15:34:02] <derhass> if you really called glCheckFramebufferStatus(1) you should just have gotten a GL error[15:34:10] <derhass> I asked "why 1" before[15:34:20] <derhass> you just make that stuff up[15:34:32] <derhass> why do you send random values to functions?[15:34:42] <derhass> and expect it to do something useful?[15:34:50] <macroprep> wait by "glCheckFramebufferStatus of course works on the currenltly bound FBO" did you mean for example if i call glCheckFramebufferStatus(0)[15:35:02] <macroprep> it would check the default FBO?[15:35:12] <derhass> calling it with 0 is the same GL_INVALID_ENUM as 1[15:35:21] <derhass> and the function should just return 0 in that case[15:36:23] <macroprep> so what do you mean by " works on the currenltly bound FBO"[15:36:41] <macroprep> is the numbered argument irrelivant?[15:37:41] * macroprep reads it man page[15:40:07] *** Fr0stBit <Fr0stBit!~theartist@2a02:2149:8643:fa00:2ed0:5aff:febd:8e14> has joined ##OpenGL[15:44:49] <macroprep> so i currently get 0[15:45:13] <macroprep> as the return of glCheckFramebufferStatus(1)[15:47:38] <macroprep> which does not match GL_INVALID_ENUM nor any of the errors specified on https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glCheckFramebufferStatus.xml[15:47:54] <mefesto> https://www.khronos.org/opengl/wiki/Framebuffer_Object#Framebuffer_Completeness[15:48:23] <macroprep> tho "Additionally, if an error occurs, zero is returned. "[15:48:42] <mefesto> heh n/m i see derhass already linked that page.[15:48:51] <macroprep> how would i check what this error is[15:49:19] <mefesto> glGetError[15:49:47] <mefesto> but you'd probably want to setup the error callback stuff for more detailed info[15:50:11] <mefesto> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_debug.txt[15:53:31] <macroprep> ok[15:57:08] *** DMJC <DMJC!~DMJC@121.208.48.187> has quit IRC (Ping timeout: 272 seconds)[15:59:32] <macroprep> GL_INVALID_OPERATION[16:18:37] <macroprep> https://github.com/mgood7123/AndroidCompositor/blob/master/app/src/main/jni/compositor.cpp this is my current file[16:21:21] *** slime <slime!~slime73@24.215.81.93> has joined ##OpenGL[16:22:17] <macroprep> im trying to make it render off screen[16:22:51] *** Vasco is now known as Vasco_O[16:24:52] <mefesto> don't you want to associate the render buffer with the framebuffer? glFramebufferRenderbuffer[16:25:22] <macroprep> i dont know[16:25:40] <macroprep> i just want it to render off screen[16:25:58] *** macroprep <macroprep!~smallvill@cpe-172-193-104-55.qld.foxtel.net.au> has quit IRC (Quit: Leaving)[16:41:36] *** Fr0stBit <Fr0stBit!~theartist@2a02:2149:8643:fa00:2ed0:5aff:febd:8e14> has quit IRC (Quit: WeeChat 2.5)[16:46:19] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has quit IRC (Read error: Connection reset by peer)[16:48:11] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has joined ##OpenGL[16:48:30] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[17:03:07] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[17:22:18] *** Kane <Kane!~Kane@home.yarg.fr> has joined ##OpenGL[17:33:04] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[18:11:01] *** salamanderrake <salamanderrake!~quassel@2605:a000:122a:2139:50b5:d668:b233:7be2> has quit IRC (Remote host closed the connection)[18:13:19] *** salamanderrake <salamanderrake!~quassel@2605:a000:122a:2139:f000:8e58:f0e0:29cb> has joined ##OpenGL[19:17:04] *** hk239 <hk239!~d@94.22.235.202> has quit IRC (Ping timeout: 246 seconds)[19:18:45] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##OpenGL[19:23:47] *** toor_ <toor_!~toor@ppp-seco21parth2-46-193-164-233.wb.wifirst.net> has quit IRC (Read error: Connection reset by peer)[19:25:41] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has joined ##OpenGL[19:44:07] *** ville <ville!~ville@212-149-214-47.bb.dnainternet.fi> has quit IRC (Quit:)[19:54:13] *** chirpsalot <chirpsalot!~Chirps@unaffiliated/chirpsalot> has quit IRC (Ping timeout: 245 seconds)[19:56:41] *** KAHR-Alpha <KAHR-Alpha!~Alpha@2a01cb0d024a6600f8d397b433da22ba.ipv6.abo.wanadoo.fr> has joined ##OpenGL[19:57:10] *** thoys <thoys!~thoys@84-107-217-107.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 272 seconds)[20:01:13] *** chirpsalot <chirpsalot!~Chirps@unaffiliated/chirpsalot> has joined ##OpenGL[20:06:00] *** Noah1101 <Noah1101!~noah@c-73-216-58-112.hsd1.va.comcast.net> has joined ##OpenGL[20:06:54] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 244 seconds)[20:07:22] *** simpl_e <simpl_e!~user@unaffiliated/simpl-e/x-3049283> has joined ##OpenGL[20:09:09] *** ville <ville!~ville@212-149-214-47.bb.dnainternet.fi> has joined ##OpenGL[20:27:03] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[20:35:02] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has left ##OpenGL ("Leaving")[20:50:16] <Noah1101> Beginner OpenGL programmer here. If I'm getting no compilation errors with my shaders, no linking error with my program and glGetError() is only returning GL_NO_ERROR does that conclude I have something wrong with my one of my shaders or could there be something else going awry?[20:51:53] <derhass> Noah1101: it only concludes that there are no GL erros[20:52:06] <derhass> Noah1101: it does not really narrow down where it goes wrong[20:52:20] <derhass> there are lots of situations where the GL simply can't detect your error[20:52:26] <Noah1101> Hmm. Oh well. More debugging for me then[20:52:41] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has joined ##OpenGL[20:52:51] <derhass> and there also lots of GL programs which are technically correct as far as the GL spec is concerned, but simply do not draw the image one is intenting[20:53:16] <Noah1101> That is... confusing.[20:55:05] <derhass> Noah1101: there are billions of perfectly valid ways to draw a black screen. you could draw outside of the viewing volume, you could screwed up your lighting correction, you could send triangles with all points being the same, you could have color writes disabled,the depth buffer might be initialized to the wrong value, and so on[20:55:26] <derhass> there is no way foir the GL to detect this stuff as errors[20:55:33] <Noah1101> I'm only drawing a simple triangle[20:56:02] <nilspin> can you show the code?[20:56:02] <derhass> that narrows things down already[20:57:19] <Noah1101> nilspin: Sure. Do want everything? It's only 239 LOC[20:57:43] <derhass> yeah, use some paste site and it will be fine[20:58:09] <wrobinson> 0bin.net pretty good[20:59:23] <derhass> I really don't care about all those different sites, and all those extra features they might have, in the end it usually means I have to adjust the uMatrix configuration to see the damn code[21:00:18] <Noah1101> nilspin: https://gist.github.com/Noah11012/1a374216b710d08cfbf57fa59cf07f18[21:01:51] <derhass> Noah1101: create_vbo is broken[21:02:17] <derhass> Noah1101: you're supplying a pointer, so sizeof(data) is just the size of your pointers, not the size of the array[21:02:54] <Noah1101> derhass: Oh... my bad. It used to be in main() but then cut it out into its own function.[21:02:58] <Noah1101> Thanks for catching that one[21:03:07] <wrobinson> derhass: was only trying to speed up a process of picking one - equally I too have to poke with uMatrix (actually for pretty much _every_ site these days)[21:03:44] <derhass> well, I already had the stup right for gist[21:03:51] <derhass> as I use that myself[21:03:55] <derhass> *setup[21:04:56] <nilspin> Noah1101: btw, using a profiler like apitrace/renderdoc really helps. It tells you exact state of things at each gl* call.[21:05:36] <Noah1101> nilspin: Cool. I'll take a look soon.[21:06:51] <derhass> Noah1101: I also suggest you add glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE) so you do not exclude some implementations (like apple's). you basically gain nothing by not setting it anyway. but that is not an error[21:07:20] <Noah1101> derhass: Thanks for your help. After fixing create_vbo() and some other minor tweaks, my triangle is now on the screen.[21:07:33] <derhass> \o/[21:07:52] <derhass> the first triangle is always the hardest[21:08:05] <Noah1101> I hear after all the boilerplate it gets a bit easier[21:08:27] <derhass> let's say it gets _different_ ;)[21:08:34] <Noah1101> Ah[21:09:33] <nilspin> Btw, why can't we step through glsl code and see values (like cuda) ?[21:10:05] <derhass> when you start chasing down some vendor's shader compiler bugs, things become really funny very fast[21:10:29] <nilspin> because of differences in implementation, perhaps?[21:10:45] <derhass> there is no standard for that, at least[21:10:57] <derhass> not sure what nvidia's tools for example can do nowadays[21:11:58] <derhass> I think nvidia nsight can actually single-step through GL shaders[21:12:39] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[21:13:10] <derhass> I also wonder if one could abuse mesa's various software rasterizers to get some debug-friendly shader code, at least running on the CPU[21:13:46] <nilspin> lol on linux/nvidia GL's debug mode says "GL_INVALID_CODE generated and <program> is not successfully linked" right after linking successfully[21:17:19] <DrBenway> sorry if i'm over taking this channel with not purely opengl related stuff but... apparently i need an hdmi cable that supports 18gbs to do 4k @ 60hz. apparently there's no way too identify the cable. you just have to try it. right now on windows, it's saying 4k @ 30 so i'm guessing i don't have the right cable considering that i'm plugged in the hdmi 1 which claims to be able to do 4k @ 60hz on monitor assus MG28UQSKU[21:17:31] <DrBenway> can i just plug un plug new cables? or do i need to reboot every time?[21:18:05] <DrBenway> ah nevermind... it's working fine[21:18:09] <DrBenway> sorry about that[21:19:52] <DrBenway> awesome! my vsynced frame rate is now... 70![21:20:50] <derhass> nilspin: I'm not convinced that there isn't something fishy on your side[21:22:28] <DrBenway> the problem with mesa is how far back is its support (haven't checked recently) and whether you can run your stuff with what is provided[21:23:01] <DrBenway> if you're working with very modern hardware, you won't be able to use the new features[21:23:33] <derhass> DrBenway: not sure what exactly you're talking about[21:24:13] <derhass> while mesa's llvmpipe is technically still at GL3.3, it already supports lots og GL4.x features[21:24:24] <derhass> with a little tweaking with the env vars, some stuff can work[21:24:30] <derhass> https://mesamatrix.net/[21:25:07] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has joined ##OpenGL[21:25:32] <DrBenway> i havent looked at the project in a while[21:25:52] <DrBenway> i work with opengl 4.6. do you think my stuff will port well to mesa?[21:26:10] <DrBenway> the answer use to be "probably not"[21:26:26] <derhass> DrBenway: depends on which backends you care about[21:26:40] <DrBenway> not everyone have the same needs[21:26:43] <derhass> DrBenway: the intel and AMD drivers are basically at 4.5 + most bits of 4.6[21:26:50] <DrBenway> ok[21:26:56] <derhass> so if you don't use SPIRV, it will work[21:27:03] <DrBenway> isn't the mesa the intel driver?[21:27:07] <derhass> that's the only 4.6 part still missing[21:27:11] <derhass> DrBenway: no[21:27:16] <derhass> mesa is an open source project[21:27:18] <nilspin> derhass: https://bpaste.net/show/CnBU typical (GL's and my own) debug output when compiling shaders[21:27:19] <DrBenway> i thought intel went full mesa[21:27:20] *** hk239 <hk239!~d@94.22.235.202> has joined ##OpenGL[21:27:22] <derhass> started as a software rasterizer[21:27:34] <derhass> became the framework for linux opengl drivers in general[21:27:46] <derhass> and is officially supported by intel and AMD nowadays[21:27:53] <DrBenway> so intel releases a separate closed source driver?[21:28:01] <derhass> not for linux[21:28:04] <DrBenway> for its intel gpus[21:28:04] <derhass> AMD still does[21:28:05] <DrBenway> ok[21:28:15] <DrBenway> so thats sort of what i meant. mesa is the intel driver[21:28:19] <derhass> but both intel and AMD directly contribute to mesa[21:28:22] <DrBenway> since intel makes a lot of contribution to mesa[21:28:27] <DrBenway> (or they use to anyway)[21:28:31] <DrBenway> sure[21:28:39] <DrBenway> but now amd has its own open source driver from what i heard?[21:28:52] <derhass> actually, mesa's main devs work for vmware[21:28:56] <DrBenway> wouldn't it be better to use that?[21:29:04] <DrBenway> fareout[21:29:08] <gehn> amd's linux drivers have been open source like since forever[21:29:08] <derhass> DrBenway: AMD's open source driver is the one in mesa[21:29:11] <DrBenway> so you get a mesa driver when using a VM?[21:29:16] <gehn> since before amd was amd, when they were still just ATI[21:29:21] <wrobinson> I use linux. not sure if i'm talking rubbish, but I have an intel chip (which uses mesa on linux) and apparently will return 4.5 core[21:29:28] <DrBenway> derhass, gotcha[21:29:42] <derhass> gehn: nope, AMD hat fglrx proprietary driver for a long time[21:29:49] <DrBenway> i dunno, there was a news a year or two ago that amd was opening its gfx driver[21:29:55] <DrBenway> i dont really have amd hardware[21:29:57] <derhass> and even after that, they still have the amdgrpu-pro stack[21:30:15] <DrBenway> wrobinson, thats wonderful[21:32:24] <derhass> gehn: the open source drivers before the last 3or so years were not endorsed by AMD and ATI at all. ATI and AMD just had more of their actual chip documentation available, so less reverse engineering was required for the open source developers[21:32:42] <derhass> but those were not paid by AMD at all[21:34:04] <gehn> ah ok[21:34:23] <derhass> ATI and later AMD had this horrible fglrx (for "fire GL and redeon for x") proprietary driver stack for over a decade[21:34:44] <gehn> yeah I at least know the amd/ati drivers for linux have all historically been pretty bad[21:35:14] <derhass> (they have been pretty bad for windows, too, especially when it comes top opengl)[21:35:21] <gehn> yup[21:35:29] <gehn> across the board really[21:37:12] <derhass> must have been in the early 2000s, I was presenting my software at some fraunhofer institute. at some point, they were asking for which GOUs are supported, and I half-jokingly responded "all but AIT", and they "ah, yes. we've done that mistake before already"[21:37:37] <gehn> hah[21:37:43] <derhass> (and it really didn't work well on ATIs driver)[21:37:51] <DrBenway> i'm puzzled at why all the consoles went with them[21:38:02] <DrBenway> even stadia went amd[21:38:08] <derhass> fur the consoles, the drivers are a lot thinner[21:38:09] <gehn> money, marketing, business deals (probably)[21:38:15] <DrBenway> sure[21:38:23] <DrBenway> but yeah lobbying probably[21:38:34] <derhass> and the developer support is a completely different story, as it is a fixed platform[21:38:41] <DrBenway> you dont need to be good technically :P[21:39:16] <derhass> AMDs hardware isn't that bad[21:39:29] <gehn> also probably because part of the point of consoles is to be "affordable", relative to a good PC anyway, and ATI/AMD have always been basically second-tier, i.e. affordable but you also get what you pay for[21:39:42] <derhass> and also probably a lot cheaper than what the competition can (or wants to) offer[21:39:51] <gehn> I used to be an AMD/ATI fanboy back when I was a poor college student[21:40:38] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[21:40:44] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Remote host closed the connection)[21:41:08] <derhass> it is funny because from 2009 to 2018 I worked on a product which came wich was AMD only (and windows only, for odd reasons), but I did all the main development on nvidia/linux[21:41:15] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined ##OpenGL[21:41:33] <DrBenway> some people seem to talk good of them[21:41:43] <DrBenway> but they also talk good about samsung and i dont really like samsung either[21:42:11] * DrBenway has a lot of angst...[21:44:27] <derhass> at one point, we even had some exhibition which was supported by AMDs marketing. and we actually run this thing on two quadros on linux (with the nvidia splash screen disabled)[21:44:42] <derhass> because AMD was unable to fix some show-stopping driver bug in time[22:11:15] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[22:14:10] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Read error: Connection reset by peer)[22:16:18] *** Nokurn_ <Nokurn_!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has joined ##OpenGL[22:16:22] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[22:16:33] *** thoys <thoys!~thoys@84-107-217-107.cable.dynamic.v4.ziggo.nl> has joined ##OpenGL[22:16:35] *** Oddity <Oddity!~Oddity@unaffiliated/oddity> has quit IRC (Ping timeout: 244 seconds)[22:17:57] *** Nokurn <Nokurn!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has quit IRC (Ping timeout: 245 seconds)[22:23:30] *** Groogy <Groogy!~Groogy@90-227-38-205-no61.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)[22:29:31] *** slvn_ <slvn_!~slvn_@2a01:e34:ef55:a6f0:e8e4:7e10:92a3:a181> has quit IRC (Remote host closed the connection)[22:33:43] *** Kane <Kane!~Kane@home.yarg.fr> has quit IRC (Quit: Leaving)[22:35:14] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 248 seconds)[22:35:53] *** Nokurn_ <Nokurn_!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has quit IRC (Ping timeout: 245 seconds)[22:36:42] *** Nokurn <Nokurn!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has joined ##OpenGL[22:37:40] *** tab-key <tab-key!~mantra@2601:601:c980:8fd:dc93:2e80:fa4d:c15e> has joined ##OpenGL[22:49:39] *** Nokurn_ <Nokurn_!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has joined ##OpenGL[22:49:48] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Read error: Connection reset by peer)[22:50:02] *** Nokurn <Nokurn!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has quit IRC (Ping timeout: 245 seconds)[22:51:28] *** immibis <immibis!~immibis@222-153-90-196-fibre.sparkbb.co.nz> has joined ##OpenGL[22:59:24] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[23:07:34] *** Noah1101 <Noah1101!~noah@c-73-216-58-112.hsd1.va.comcast.net> has quit IRC (Quit: Lost terminal)[23:07:48] *** immibis <immibis!~immibis@222-153-90-196-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 272 seconds)[23:17:48] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has quit IRC (Quit: Leaving)[23:22:10] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has quit IRC (Quit: Leaving)[23:33:08] *** Nokurn_ <Nokurn_!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has quit IRC (Ping timeout: 272 seconds)[23:43:40] *** Nokurn <Nokurn!~Nokurn@cpe-108-185-62-246.socal.res.rr.com> has joined ##OpenGL