Current Server Time: 10:45 (Central Europe)

#apertus IRC Channel Logs

2020/05/02

Timezone: UTC


00:03
Bertl_oO
off to bed now ... have a good one everyone!
00:03
Bertl_oO
changed nick to: Bertl_zZ
02:26
mumptai_
joined the channel
02:30
mumptai
left the channel
05:16
panintended
joined the channel
07:47
BAndiT1983|away
changed nick to: BAndiT1983
08:13
LordVan
joined the channel
08:46
Bertl_zZ
changed nick to: Bertl
08:46
Bertl
morning folks!
08:47
metal_dent[m]
Bertl: morning!
08:57
se6ast1an
good day
09:10
panintended
good day
09:18
se6ast1an
metal_dent[m]: how are things going?
09:18
se6ast1an
panintended: any progress?
09:19
se6ast1an
I pushed a first version of the popup parameter menu yesterday to the AXIOM Remote repo, feel free to try it in the GUI
09:20
BAndiT1983
se6ast1an: is the parameter highlighted when the menu pops up?
09:21
BAndiT1983
i mean the one to modify
09:22
se6ast1an
yes
09:26
metal_dent[m]
> I pushed a first version of the popup parameter menu yesterday to the AXIOM Remote repo, feel free to try it in the GUI
09:26
metal_dent[m]
Sure, will check that
09:30
se6ast1an
just created a new task: https://lab.apertus.org/T1192
09:31
BAndiT1983
as currently the loop delay is removed, the performance seems to degrade, probably pic32 trying to push the data to LCD as fast as possible
09:33
BAndiT1983
delay was there for a reason, namely known frame rate and reduced strain for the pic32, in the future we don't need any FPS counter, as frame update will only be doen when something happens as LCD has it's own buffer, which holds the data permanently, until the power is off
09:36
BAndiT1983
there are better methods to measure performance, as the MCU has precise timers, current value can be retrieved between certain calls, like start time and end time
09:37
se6ast1an
I think this needs some dicussion as it sounds counter intuitive: if a delay with every loop is removed why would performance degrade?
09:38
se6ast1an
also remember this is not a desktop CPU, so does the concept of CPU strain/load exist?
09:38
se6ast1an
it always runs at the same speed no matter what it does
09:38
BAndiT1983
of course the load exists, as it tries to push the data as fast as possible, so the delays there also delay other functionality
09:39
BAndiT1983
as it's only single-core it's even more necessary to ensure that processes do not brake the system
09:39
se6ast1an
but I agree that with event based redrawing the FPS doesnt really mean anything anymore, but how far away are we from this? does it make sense to wait for it?
09:40
se6ast1an
<BAndiT1983> there are better methods to measure performance, as the MCU has precise timers, current value can be retrieved between certain calls, like start time and end time <- sounds good, how can we start doing this?
09:41
BAndiT1983
basic method is to grab the value of system timer, have to find the docs i'Ve used before
09:43
BAndiT1983
FPS won't tell us what really slows the process down, but we require profiling, to be able to tell which parts degrade performance and why
09:46
se6ast1an
Sounds good, but like a bigger taks
09:46
se6ast1an
Let's adapt the task to reflect that
09:46
BAndiT1983
back then i've read this thread about core timer -> https://www.microchip.com/forums/m591009.aspx
09:47
BAndiT1983
and this one https://www.microchip.com/forums/m883894.aspx
09:47
BAndiT1983
maybe there are still snippets in the code, as i don't remember the outcome of the tests
09:48
Bertl
are we talking processes on the PIC32MZ?
09:48
Bertl
did you implement multitasking?
09:48
BAndiT1983
for the beginning we could measure only the main loop to estimate how much time menu drawing, button polling etc. need
09:49
BAndiT1983
of course, ported freertos all the way
09:49
BAndiT1983
hm, there are enough crazy people out there -> https://www.freertos.org/port_PIC32_MIPS_MK4.html
09:50
Bertl
and ported it to C++ of course?
09:50
BAndiT1983
nah, punch cards are enough, just have to replace them quick enough for the firmware to run
09:57
BAndiT1983
at the moment it looks like the timer at the main page is running slower than before, so hunting down the culprit is necessary, but the loop was simplified already
09:58
BAndiT1983
my first tests had much faster performance, that tells me that there is code running which shouldn't
10:06
se6ast1an
off for reviving the bike, will update lab task when back
10:06
se6ast1an
or feel free to do so in the meantime
10:07
se6ast1an
adding those above links and new goals
10:07
BAndiT1983
will flash the board again, test a bit and update the task when i know more
10:59
Bertl
off for now ... bbl
10:59
Bertl
changed nick to: Bertl_oO
11:15
panintended
BAndiT1983: I've replied to your comment https://lab.apertus.org/T1181#16993 - have a look and let me know
11:21
BAndiT1983
panintended: nowadays opengl 3.3 is the default version, so 2.1 is not my preference
11:23
BAndiT1983
will check your version in my VM, then i can see if it works for general setup, like i said before, my manjaro with nvidia drivers isn't having any trouble to run either profile, probably because the drivers were finally improved and no bumblebee is required on intel/nvidia optimus system
11:27
BAndiT1983
the visualiser could have been done in software, but most UI libs require some graphics API like opengl, so went for imgui for now
11:36
BAndiT1983
not saying, that we can't change the base at some point to software only, it just needs proper UI which has less ties to OGL or similar
11:39
panintended
cool, thanks for the insight. I asked whether a recent version is a requirement because it seems to me that SDL is choosing it (for whatever reason)
11:40
BAndiT1983
3.3 and recent :D -> https://www.khronos.org/opengl/wiki/History_of_OpenGL
11:40
BAndiT1983
it's just a base version, like 2.1 was for quite some time before
11:40
panintended
haha :'D
11:41
panintended
touche. I guess non-ancient would be a better term then
11:41
BAndiT1983
good thing about OGL3 that they got rid of old things and slimmed it down, am looking forward what vulkan will deliver in the future
11:41
BAndiT1983
i suppose it will go on with GL backward compatibility, like it is done with win32 ;)
11:42
panintended
by the way, do the suggested changes work on your setup after all? In the comment you said that no profile worked for you
11:43
panintended
meanwhile I'll
11:43
panintended
*continue looking into convincing SDL to use a more recent version
11:43
BAndiT1983
i had no luck in my VM, as it started 2.1, but it is done by SDL2 for creating the 3.3 context, wasn't accomplished
11:43
BAndiT1983
will check your fork
11:44
panintended
cool, thanks
11:46
panintended
*btw, for me it also starts with 2.1, but the visualizer works just fine
11:48
BAndiT1983
i suppose it's the way it is done to get new context, remembering something from the days when i've developed with opengl
11:49
BAndiT1983
hey, looks great and worked instantly, will check your changes
11:49
anuejn
left the channel
11:49
BAndiT1983
at the start it tells me that it's 3.3
11:50
anuejn
joined the channel
11:50
BAndiT1983
please create a PR
11:52
panintended
Sure, will do. But I'd like to ask: (1) Does it still start with 2.1 or is ti with 3.3 now? (2) how do you check which version it starts with? Are you referring to the stdout of the Visualizer?
11:53
BAndiT1983
yep, stdout, as it grabs the version after init
11:53
BAndiT1983
dev@dev-VirtualBox:~/Projects/AR_pan/AXIOM-Remote/AXIOM_Remote_Firmware_Visualizer/build$ ./AXIOM_Remote_Firmware_Visualizer
11:53
BAndiT1983
AXIOM Remote Visualizer
11:53
BAndiT1983
GL Version: 3.3
11:53
BAndiT1983
Texture ID: 1
11:53
BAndiT1983
Texture ID: 2
11:54
BAndiT1983
SetupGL method is misleading, as it only initializes gl3w
11:55
BAndiT1983
some reordering is still required it seems, have just done it in very basic way
11:55
panintended
ok, I was referring to the same thing. for me it has been 2.1 ever since I applied the fix :'D
11:55
panintended
ah, I see
11:56
panintended
btw is there any cnovention to add a hook to the bug entry in the PR title? (similar to Gitlab's #<issue ID>)
11:57
panintended
or do you guys just add a reference to the commit Phabricator>
11:58
BAndiT1983
haven't used hooks before, but we had a topic about cimmit messages yesterday, if you add lab task like T1177 to the commit, then it will reference it in the task
11:58
BAndiT1983
see Details -> https://lab.apertus.org/T1177
11:59
BAndiT1983
commit message can look like -> T1177: Added .....
11:59
BAndiT1983
everything else will be done by lab, seeing that se6ast1an has added the whole link, but it's not required
12:00
BAndiT1983
just the T<number> is sufficient
12:02
se6ast1an
back
12:05
panintended
Ah, great. That was what I was referring to
12:05
se6ast1an
updated https://lab.apertus.org/T1192
12:05
panintended
done: https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/12
12:06
BAndiT1983
merged
12:10
panintended
great, thanks. Also regarding the visualizer: I don't seem to be able to select menu items like I could before with button 5. Am I missing something?
12:10
panintended
as soon as I make the knob pressable this should be resolved though
12:10
panintended
left the channel
12:10
panintended
joined the channel
12:10
BAndiT1983
button 5 was working for me just moments ago in your fork
12:11
se6ast1an
button 5 should work
12:11
se6ast1an
let me pull your PR and check here as well
12:11
BAndiT1983
but in the VM i have to be slightly above the button, seems like mouse is having some offset, which does not happen in the host PC
12:11
BAndiT1983
checked it again, works properly
12:13
se6ast1an
sorry for being that guy but this is my visualizer again now: https://paste.pics/2f1ea690e9d33cf7409435b3f3fe4190
12:13
panintended
oh boy ;D
12:13
se6ast1an
GL Version: 2.1
12:13
BAndiT1983
strange, my VM is exactly ubuntu 16.04
12:14
BAndiT1983
VBoxSVGA 128MB
12:14
BAndiT1983
panintended: just a normal craziness of trying to support most systems
12:15
BAndiT1983
i agree that software-only version would be better for the task, but even raspi supports opengl properly
12:16
BAndiT1983
se6ast1an: please paste also your glxinfo in the lab task, for comparison
12:17
se6ast1an
ok
12:17
BAndiT1983
glxinfo | grep OpenGL
12:19
BAndiT1983
please do the same for the VM, mesa-utils package has to be installed, will create a pastebin for mine
12:20
BAndiT1983
https://pastebin.com/raw/XEF7A9K7
12:24
se6ast1an
virtualbox is not starting currently...
12:28
se6ast1an
solved
12:29
BAndiT1983
what was the problem?
12:31
se6ast1an
https://lab.apertus.org/T1181#16998
12:31
se6ast1an
some service was not found
12:31
se6ast1an
also black in VM
12:31
panintended
Ah so the issue with virtualbox was solved, not with the visualiser :'D
12:31
BAndiT1983
VM looks the same
12:32
BAndiT1983
i mean the parameters
12:32
se6ast1an
yes, it also has the same black visualizer screen :)
12:33
panintended
hmm. FYI I've set the profile mask to 0 in my PR (corresponds to the SDL choosing the OpenGL profile)
12:33
BAndiT1983
your hardware looks also like it's ok, but if the host PC has the problems, then it's something else, as the GL commands are passed to the host for quite some time in VB
12:33
BAndiT1983
you can also try to disable 3D support for the VM
12:34
BAndiT1983
which linux do you use on your host?
12:34
panintended
perhaps setting it to SDL_GL_CONTEXT_PROFILE_COMPATIBILITY can help
12:36
BAndiT1983
especiall this line tells me that it should work: OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.8
12:37
BAndiT1983
se6ast1an: can you check what glxgears -info will say, mine starts with 4.6
12:37
BAndiT1983
GL_RENDERER = Mesa Intel(R) HD Graphics 630 (KBL GT2)
12:37
BAndiT1983
GL_VERSION = 4.6 (Compatibility Profile) Mesa 20.0.5
12:37
BAndiT1983
GL_VENDOR = Intel
12:38
BAndiT1983
and this is for prime-run glxgears -info, which starts on the dedicated GPU:
12:38
BAndiT1983
GL_RENDERER = GeForce GTX 1050/PCIe/SSE2
12:38
BAndiT1983
GL_VERSION = 4.6.0 NVIDIA 440.82
12:38
BAndiT1983
GL_VENDOR = NVIDIA Corporation
12:38
se6ast1an
virtualbox host is windows
12:39
se6ast1an
with a rtx 2080, doubt that is insufficient :)
12:39
BAndiT1983
nice having same one in my desktop
12:40
se6ast1an
panintended: I tried SDL_GL_CONTEXT_PROFILE_COMPATIBILITY, unfortunately no difference
12:40
BAndiT1983
you've posted 2 glxinfos, where is the first coming from?
12:41
se6ast1an
my dedicated axiom remote development laptop
12:42
se6ast1an
that SDL_GL_CONTEXT_PROFILE_COMPATIBILITY doesnt work is extra weird because thats exactly what it was before the latest commit
12:42
se6ast1an
is it about those functions being called earlier?
12:42
panintended
se6ast1an: can you go to AXIOM-Remote/AXIOM_Remote_Firmware_Visualizer/3rdParty/imgui/examples/example_sdl_opengl3, run make and the run ./example_sdl_opengl3
12:43
BAndiT1983
in my VM this also works fine
12:43
se6ast1an
panintended: done, I see the menus and windows, so I guess that works
12:44
panintended
ok, so I guess it's back to the drawing board for me then :)
12:44
panintended
I'll compare the imgui example with the visualiser opengl/SDL setup
12:45
panintended
can you pastebin a screenshot just in case though?
12:45
BAndiT1983
what about newer ubuntu version?
12:50
se6ast1an
https://lab.apertus.org/T1181#16999
12:50
se6ast1an
this machine runs latest linux mint
12:51
panintended
:) sorry *I meant if you can paste a screenshot of the imgui example running (externally no need to spam the bug tracker)
12:51
se6ast1an
sure
12:53
se6ast1an
https://lab.apertus.org/T1181#17000
12:54
panintended
yeah, this one looks alright. thanks
12:54
BAndiT1983
i've meant for VM
12:55
se6ast1an
I can instell newer ubuntu vm if that would help
12:56
BAndiT1983
we need to check this, like i said, my VM with ubuntu 16.04 is working properly, but i had also problems before, when i'Ve tried to move line panintended has analysed
12:57
BAndiT1983
which version of GL does your visualiser tell you in the terminal?
12:59
se6ast1an
2.1
13:00
BAndiT1983
already suspected thaat
13:00
se6ast1an
was 3.3 before when it worked
13:04
BAndiT1983
have to checkout again, as my repo lost the remote branch
13:07
BAndiT1983
now it also fails for me again, crazy times
13:08
se6ast1an
:O
13:09
BAndiT1983
but only in VM
13:23
BAndiT1983
panintended: have you seen any bigger difference with init of GL in the imgui example and visualiser?
13:45
panintended
yes, there are some. Let me try to concisely put them in the bug tracker
13:45
panintended
although I don't know how much difference they'll make
13:45
BAndiT1983
also trying at the moment, as it's really suspicious
13:46
BAndiT1983
moving the attributes after window and renderer, but before gl context says 3.3, but before render 2.1
13:47
BAndiT1983
but both cases are still giving black image, looks like context is not there, as the font atlas (the texture which occurs) is registered at wrong texture id, so it interferes with following operations
13:52
panintended
In the imgui example: [a] there is no SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, 0) [b] there is a SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, 0) before setting the GL version [c] SDL_GL_MakeCurrent(window, gl_context) comes right after SDL_GL_CreateContext() [d] right after SDL_GL_CreateContext() there is a SDL_GL_SetSwapInterval(1); // Enable vsync
13:52
BAndiT1983
they use core profile
13:53
BAndiT1983
#else // GL 3.0 + GLSL 130 const char* glsl_version = "#version 130"; SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, 0); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
13:53
panintended
ah correct! sorry for that
13:53
BAndiT1983
no problem
13:53
panintended
it's unfortunate that I can't reproduce it on my setup. Can you guys please have a look with these ?
13:54
BAndiT1983
checking at the moment if there is any difference
13:55
BAndiT1983
but probably the old ubuntu version is just not up to the task
13:55
BAndiT1983
and in VM
13:55
schmoggie1
joined the channel
13:56
schmoggie
left the channel
13:58
BAndiT1983
very funny, i've disabled the creation of SDL renderer and it worked
13:59
BAndiT1983
se6ast1an: please try to comment out the block with renderer = SDL_CreateRenderer(*win, -1, 0);
13:59
BAndiT1983
lines 69-76
13:59
panintended
yes, the imgui example does not have a rendeder object
14:01
BAndiT1983
IMGUI is used for everything, so SDL renderer won't work there like this and probably they are interfering with each other, as the context is not shared
14:03
BAndiT1983
cannot reproduce again, as soon as it works one time, it works also afterwards
14:03
BAndiT1983
wanted to check shared context, but just out of curiosity, as we can get along with only IMGUI drawing
14:05
se6ast1an
ok
14:06
se6ast1an
indeed it works :P
14:06
BAndiT1983
the lines can be placed before gl context init, as the tutorials are relying on the SDL renderer
14:07
BAndiT1983
so both renderers collided without context sharing
14:07
BAndiT1983
alright, then the code can be simplified and attributes including GL context init moved to SetupGL, before gl3wInit() line
14:08
BAndiT1983
panintended: would you be so kind?
14:10
BAndiT1983
we should also remove commented out code, to reduce clutter, git stores the history and if something has to be looked up, it can be done there
14:11
panintended
yep, let me see if I can redo what you did.
14:12
BAndiT1983
i can create a patch, if you need
14:21
panintended
no need
14:23
BAndiT1983
just remove any reference to the render, it should reduce also overall code
14:23
panintended
So, I've removed the renderer (and all it's references) as well as removed commented-out lines. And it starts fine (and I've now got OpenGL 3.3)
14:23
BAndiT1983
*renderer
14:23
panintended
I beat you to it :)
14:23
BAndiT1983
:D
14:24
panintended
is that all? anything else?
14:26
panintended
I'll push to my fork in the meantime
14:27
BAndiT1983
great, and please create a PR, then i can check the code
14:30
comradekingu
joined the channel
14:35
BAndiT1983
changed nick to: BAndiT1983|away
14:35
BAndiT1983|away
changed nick to: BAndiT1983
14:37
se6ast1an
great, you guys are the best!
14:37
panintended
https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/13
14:38
BAndiT1983
thanks, checking
14:38
panintended
BAndiT1983: I've also replaced Shutdown() with SDL_Quit(), make sure you go through everything. Thanks
14:39
panintended
*not all calls to Shutdown() just one :)
14:40
BAndiT1983
looks good, just needs a bit of grouping of parts
14:40
BAndiT1983
this is my version of SetupGL() -> https://pastebin.com/raw/zUmDvpYC
14:47
panintended
ah! you're right
14:47
panintended
let me amend
14:47
BAndiT1983
just some icing for the cake ;)
14:47
BAndiT1983
no need, just push the new commit
14:49
BAndiT1983
this is the advantage with pull requests, that git is intelligent to concatenate automatically
15:07
panintended
BAndiT1983: hmm, I guess I should also move the SDL_Window initialization in SetupGL. That was how all of this started right? :) [https://wiki.libsdl.org/SDL_GL_SetAttribute#Remarks]
15:07
panintended
i.e. the window should be initialized after the SDL_GL_SetAttribute() calls
15:07
panintended
(even though it still happens to work on my system)
15:09
BAndiT1983
nah, it works fine without, the other way was intended for SDL way, but now we use plain GL, more or less
15:10
BAndiT1983
it works on my side -> https://pastebin.com/raw/gT6c2WYZ
15:10
BAndiT1983
just the methods should also be grouped at some point, but this is not important right now
15:20
panintended
ok, almost done. btw you've removed SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
15:21
panintended
is there any use for this in our context
15:22
BAndiT1983
not really, as we don't have high-end animations ;) this is probably the reason i've removed it while testing
15:23
panintended
ok, I'll remove it then
15:28
panintended
done. I've also cleaned up some unused variables and changed cout to cerr in the updated functions
15:28
BAndiT1983
great!
15:29
panintended
have a look and let me know if you have questions. thanks
15:29
BAndiT1983
nope, no questions, looks like what i've expected, good work, merged already
15:29
panintended
cool
15:30
BAndiT1983
now it's up to se6ast1an to test ;)
15:30
panintended
let's see if this is the end of the saga xD
15:30
BAndiT1983
if only game producers would care about fixing their black screens
15:31
panintended
meaning? :)
15:32
BAndiT1983
had quite some games which were just black at the start, but probably because they've used some initialization which were no possible on newer systems already
15:32
BAndiT1983
sometimes developers use too specific OS features and when OS version is newer it doesn'T work that well
15:32
panintended
haha, nice bit of trivia :)
15:34
BAndiT1983
best thing is, that wine allows to start the games sometimes better than windows, e.g. back when processors were starting to change the frequency dynamically, some games haven't taken it into account and ran slower or faster, so i had to start the windows calculator and enter big number then click factorial calculation, CPU usage went up and i could start the game normally, then kill calculator
15:35
se6ast1an
finished cooking & eating, will test now
15:35
BAndiT1983
and i won't even mention old interfaces like directdraw and games which struggle to run on win10 without it
15:35
panintended
bon appetit
15:37
se6ast1an
it works!
15:37
panintended
BAndiT1983: yep, I've been expiriencing this myself. I dug up some old games that I hoped to be able to play online against friends running Windows. My experience was much smoother than theirs
15:37
panintended
awesome
15:38
BAndiT1983
now the task can be finally closed and we are a bit smarter
15:40
panintended
:)
15:40
panintended
I think I'm going to call it a day for today guys
15:41
BAndiT1983
hope we can continue tomorrow or so
15:41
BAndiT1983
have a nice evening, am a bit off to get some groceries
15:41
BAndiT1983
changed nick to: BAndiT1983|away
15:41
panintended
you too, thanks
15:44
se6ast1an
see you
15:44
se6ast1an
will continue with parametermenu now
17:10
danieel
left the channel
17:22
danieel
joined the channel
17:30
panintended
left the channel
17:30
panintended
joined the channel
18:19
BAndiT1983|away
changed nick to: BAndiT1983
18:26
panintended
left the channel
19:24
BAndiT1983
changed nick to: BAndiT1983|away
19:25
BAndiT1983|away
changed nick to: BAndiT1983
22:19
schmoggie
joined the channel
22:21
schmoggie1
left the channel
22:26
BAndiT1983
changed nick to: BAndiT1983|away
23:19
ashok_singh[m]
left the channel