02:39hansg: Hi All, after a bit of a detour cleaning up acpi/video_detect.c backlight handling I'm back to working on nouveau, and specifically back to:
02:39hansg: Which is about nv46 sync-to-vblank not working
02:40hansg: I've just build the standalone nouveau version from http://cgit.freedesktop.org/~darktama/nouveau and something weird is going on, that version works ...
02:41hansg: Going back to the linux-3.20 tag in that repo things still work, where as the module from the Fedora kernels (upto 4.1-rc7) does not work ...
02:42hansg: I'm going to do a full kernel build using Linus' latest master now, and see what that does.
07:29imirkin_: hansg: note that ben's branch has *only* nouveau, not the rest of drm. sometimes changes don't break the ABI but are still logical changes.
07:29imirkin_: hansg: also there are patches from... someone, on dri-devel, re nouveau's vblank logic iirc
07:32imirkin_: hansg: ah, from danvet. "drm/nouveau: Use drm_vblank_on/off consistently"
07:33imirkin_: and looks like it's re suspend/resume, so... probably not what you're seeing.
11:08briocalter: using mesa 10.5.4 on fedora 22, trying to run gzdoom 1.8.10, getting only garbled graphics
11:09imirkin_: what gpu?
11:09briocalter: any hints? also, all games on steam hangs tho PC
11:09briocalter: VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 660 Ti] (rev a1)
11:10briocalter: very, using default X configs
11:10imirkin_: pastebin dmesg + xorg log + glxinfo -- just in case something's awry
11:11briocalter: lots of INVALID_BITFIELD on dmesg
11:12imirkin_: yeah just pastebin all the logs :)
11:13briocalter: sure, sec
11:15briocalter: oh, exceeded size
11:16imirkin_: wtf are you pasting
11:16imirkin_: dmesg shouldn't be THAT big
11:16imirkin_: feel free to cut off the errors after a short while
11:16imirkin_: i'm more interesting in the first errors than the last (which are often a direct result of the first ones)
11:20imirkin_: erm... wtf?!
11:20imirkin_: 2380 == CB_SIZE. how does it get up to 0x9c400? hm :(
11:21briocalter: no idea, I've used this card with nvidia proprietary before
11:22imirkin_: aha, it might happen via nvc0_cb_push
11:22imirkin_: are you proficient at editing and/or building code?
11:22imirkin_: 0x9c400 = 640000 ... i tend to find such round numbers suspicious :)
11:22briocalter: never done with anything video related, but I can try
11:23imirkin_: not necessarily video-related, but if i e.g. ask you to make a small edit to mesa and build it, will you be able to?
11:23briocalter: btw I'm not on mesa upstream
11:23imirkin_: yeah, but that code hasn't changed in ages
11:24briocalter: I can do that, sure
11:24imirkin_: ok, in mesa, in nvc0_transfer.c, comment out the line in nvc0_init_transfer_functions that says "nvc0->base.push_cb = nvc0_cb_push;"
11:25imirkin_: (i.e. prefix the line with //)
11:25imirkin_: and rebuild/install
11:25briocalter: haha, that's funny, I know how to comment :)
11:25imirkin_: i like to be thorough :p
11:26imirkin_: make sure to build with --enable-texture-float otherwise you don't get GL3
11:26imirkin_: this is what i do: ./configure --prefix=~/install --with-dri-drivers=i965 --with-gallium-drivers=nouveau,swrast --enable-gallium-llvm --enable-gles1 --enable-gles2 --with-egl-platforms=drm,x11 --enable-texture-float
11:27imirkin_: and then use LD_LIBRARY_PATH=/home/me/install/lib to use my versions
11:28avph: hi is that bug possibly related to this: https://bugs.freedesktop.org/show_bug.cgi?id=90276 ?
11:29imirkin_: which bug is "that bug"?
11:29avph: the one your talking about
11:36briocalter: goddamn, does mesa requires python-mako module to build?
11:38imirkin_: it might, i'm a bit annoyed at all those dumb deps =/
11:38Karlton: I know the latest git does
11:38Karlton: 5.7 shouldn't
11:38briocalter: yea, fedora has 404ed me on python-ipaddress
11:38briocalter: can't install mako easily
11:39Karlton: use pip or easy_install if you have pyhton2-setup-tools installed
11:40Karlton: I think for me it was 'easy_install-2.7 -U mako'
11:43briocalter: nice, that did it
11:43imirkin_: briocalter: ok cool. obviously that's not a proper fix, i'll put something together
11:44briocalter: no wait
11:44briocalter: just building
11:44imirkin_: Karlton: just pushed a change to fix terasology
11:45Karlton: imirkin_: it is in mesa now?
11:45imirkin_: Karlton: not any release, but i just pushed it upstream like 30s ago
11:46Karlton: imirkin_: nice, thanks! ^^
11:47briocalter: imirkin_, is X restart needed?
11:47imirkin_: briocalter: nope
11:48hakzsam: imirkin_, Hey, welcome back :)
11:48imirkin_: hakzsam: thanks ;)
11:49hakzsam: imirkin_, did you see this patch http://lists.freedesktop.org/archives/mesa-dev/2015-June/085921.html ?
11:50imirkin_: hakzsam: yeah, but i forgot about it. are drv stats not a thing at all on nv50?
11:50imirkin_: hakzsam: nouveau_buffer also collects stats fwiw
11:51briocalter: imirkin_, didn't work, same behaviour
11:51hakzsam: imirkin_, we collect some of them but they are not exposed through the HUD
11:51imirkin_: briocalter: bleh ok. so it must just be creating a huge constbuf using the "usual" methods, despite the fact that the driver doesn't allow it
11:52imirkin_: briocalter: in nvc0_state_validate.c:nvc0_constbufs_validate
11:52imirkin_: briocalter: can you print out nvc0->state.uniform_buffer_bound[s] and nvc0->constbuf[s][i].size ?
11:52imirkin_: (right before the PUSH_DATA's that send them into the fifo)
11:53briocalter: need more arcane mana to cast that
11:53briocalter: just tell me how :)
11:53imirkin_: so you can comment out lines, but this is getting too heavy? :p
11:53briocalter: hehe ya
11:53briocalter: do we need gdb here?
11:54imirkin_: printf("************ ubo size: %x **********\n", nvc0->state.uniform_buffer_bound[s]);
11:54imirkin_: and the obvious thing for the other vlaue
11:54imirkin_: actually give them slightly diff prints so that we know which is which
11:54briocalter: that will print on dmesg?
11:56imirkin_: you're looking for prints with anything >= 0x10000 in it
11:58imirkin_: briocalter: btw, can i run this application myself? that might speed up debugging
11:59briocalter: sure, rebuilding
12:00imirkin_: do i also need some sort of map/etc file?
12:01briocalter: yea, you need a wad
12:01briocalter: can get the shareware
12:02imirkin_: ok. so one other thing you can do is make an apitrace that includes the failure and make it available somehow
12:02imirkin_: that will allow me to see all the GL calls being made
12:03briocalter: ok, but first answer me this: console is not outputting the printfs after running the app
12:04imirkin_: but you're still seeing those errors in dmesg?
12:04briocalter: I do
12:04imirkin_: must mean it's something else
12:04imirkin_: or you messed up
12:05imirkin_: at this point the apitrace might be easiest
12:05briocalter: ok lemme try that
12:11Karlton: imirkin_: I wonder if FlightGear does the same thing that Terasology does: http://i.imgur.com/i49R1Dn.png :)
12:11imirkin_: Karlton: maybe. does it get fixed with master?
12:12Karlton: i'll see...
12:14briocalter: imirkin_, got a trace here
12:14briocalter: is it pastable on pastebin?
12:14imirkin_: gdrive... or filebin or something
12:14imirkin_: xz -9 it
12:15imirkin_: first verify that replaying the trace (with glretrace) causes the same problems
12:15imirkin_: otherwise it's all moot :)
12:19briocalter: yea, apitrace is not able to replay the trace...
12:19briocalter: lemme try something here
12:21briocalter: nope, dunno what to do =/
12:23imirkin_: uhm, what does it say?
12:24briocalter: it just shows black screens
12:24imirkin_: is that not what you "normally" see?
12:24imirkin_: most importantly, do you still see errors in dmesg?
12:24briocalter: no, it shows garbled graphics, I can imgur it
12:24imirkin_: it might just be clearing its textures first
12:25briocalter: yes, replaying the trace shows the same errors on dmesg
12:25imirkin_: ok perfect
12:25imirkin_: make it available somewhere
12:25briocalter: ok sec
12:27imirkin_: cool thanks
12:27briocalter: thank you, hope it helps
12:28imirkin_: hmmm... i get all black replaying it on i965
12:28briocalter: yes same here
12:29imirkin_: ok, so i see the same errors here. yay.
12:33Karlton: imirkin_: Terasology is fixed now but FlightGear has some other issue: http://i.imgur.com/i49R1Dn.png
12:34imirkin_: Karlton: yeah, not too surprising
12:34imirkin_: Karlton: make an apitrace ;)
12:40imirkin_: briocalter: hm, looks like they're just feeding regular ubo's that are just bigger than what the driver allows
12:40imirkin_: briocalter: there's a commit floating around that will enforce that sort of thing at the state tracker level, but i guess the driver should also be defensive
12:40briocalter: uh, nice to known
12:41imirkin_: so it's a gzdoom bug
12:41imirkin_: but that doesn't really make it ok for nouveau to do bad things, so i'll fix that up shortly
12:42briocalter: glad to help
12:42imirkin_: not sure why this would work on the blob driver, it has the same limits
12:42imirkin_: perhaps gzdoom takes a different path internally
12:42imirkin_: or perhaps it doesn't REALLY want a 640k buffer
12:42imirkin_: and the blob driver gracefully discards everything past 64k
12:42briocalter: yea that sounds reasonable
12:45imirkin_: briocalter: http://hastebin.com/uyadafofah.coffee
12:45imirkin_: that "fixes" the errors for me, but it still doesn't work
12:50briocalter: imirkin_, it seems that applying that patch, compiling and installing isn't replacing old mesa
12:50briocalter: that's why I can't printf earlier
12:51imirkin_: briocalter: LD_LIBRARY_PATH=/path/to/new/install/lib
12:53briocalter: same, libs have been installed on /usr/local/lib/dri
12:54imirkin_: pushed that fix out btw
12:54briocalter: no dice =/
12:54imirkin_: Karlton: how's that flightgear trace coming?
12:55imirkin_: briocalter: did you "make install"?
12:55briocalter: checked the folder, all there
12:55imirkin_: is it a 32-bit game whereas you built 64-bit libs?
12:55briocalter: nope, full 64
12:55Karlton: imirkin_: I got the trace but I suck at making it >50MB
12:55imirkin_: how about
12:55imirkin_: LD_LIBRARY_PATH=/usr/local/lib glxinfo
12:56imirkin_: Karlton: filebin :)
12:56imirkin_: don't worry about reducing it
12:56imirkin_: it's hard and error-prone
12:57Yoshimo: i guess there is still no word from nvidia about the firmware needed for the 980 model yet?
12:58briocalter: yea, glxinfo shows mesa 10.7.0-devel no prob
12:58imirkin_: briocalter: hmmmm
12:58tobijk: whereas we'd start to need it, more and more people have those cards showing up here :/
12:58imirkin_: are you sure you applied the patch?
12:58briocalter: yep, rebuild and install
12:58tobijk: btw, imirkin_, wb! :)
12:58imirkin_: tobijk: thanks :)
12:59Yoshimo: tobijk: i didn't expect that, i mean such a highend card is usually for people running demanding games that don't run on linux that well
12:59tobijk: Yoshimo: its not that is the final step, its the first to get those cards woking sadly
13:00Yoshimo: sad decisions of that company, but well, buying amd isn't gonna fix this
13:08hakzsam: imirkin_, are you going to have some time to review my series which implements nouveau-perfkit, btw?
13:16imirkin_: hakzsam: mmmmm... i know nothing about that stuff
13:17imirkin_: hakzsam: it was all st work, right?
13:17hakzsam: imirkin_, yeah, it's a gallium state tracker
13:18imirkin_: i've never used cupti beyond running your test programs :)
13:18hakzsam: this series implements perfkit not cupti ;)
13:19imirkin_: i think i've aptly demonstrated my lack of familiarity with the situation
13:22hakzsam: mupuf, you are going to be the only one guy who wants/can review this series :)
13:26imirkin_: hakzsam: is there a short synopsis of what it is, are there applications that use it, etc?
13:26hakzsam: imirkin_, otherwise, I'll submit a RFC which exposes global performance counters for nv50 and nvc0 in few weeks. I'm pretty sure you'll be able to review it ;)
13:27imirkin_: only at a high level
13:27imirkin_: i have no idea how all that stuff works
13:27hakzsam: no problem
13:28hakzsam: imirkin_, well, you can find a GL sample which uses the API if you download nvidia-perfkit
13:29imirkin_: what does it do?
13:29imirkin_: (the api, not the sample)
13:29hakzsam: http://cgit.freedesktop.org/~hakzsam/libperfkit/ --> this is the wrapper library (like libvdpau) with lot of unit tests to understand how the API works
13:30imirkin_: how is this different than glQueryStuff?
13:30hakzsam: the api allows to monitor graphics performance counters
13:31hakzsam: what do you mean by glQueryStuff?
13:31imirkin_: i mean i don't forget the exact gl calls :p
13:33imirkin_: i guess it's not great for large quantities of counters
13:34hakzsam: yes probably, and glQueryStuff does't support multi-passes events I think
13:34hakzsam: this api is designed for NVIDIA's hardware only
13:35hakzsam: and according to the license/copyright, we have to use it only with nvidia products...
13:40hakzsam: imirkin_, but I don't know if other applications use it, except the GL sample provided by NVIDIA
13:40hakzsam: anyways, it seems to be the only way to expose multi-passes events because both the HUD and AMD_perfmon doesn't support them
14:00Karlton: imirkin_: FlightGear trace: http://expirebox.com/download/4e13b6d4e688e5c618c6e548d973d4c3.html
14:01imirkin_: Karlton: that's some pretty major fail :(
14:02Karlton: imirkin_: major fail?
14:02imirkin_: looks like total ass
14:03airlied: imirkin_: btw I fixed some of the worse missing prime features :-)
14:03airlied: and got i915 to fix the rendering problems
14:03imirkin_: airlied: awesome, i saw some of those
14:03imirkin_: airlied: now just need to be able to slave multiple outputs from a single gpu
14:03Karlton: imirkin_: I just see green stuff
14:03imirkin_: Karlton: oh, i don't see green at all. but i have a GK208.
14:03imirkin_: Karlton: i see what looks like compression fail, but i thought we fixed that :)
14:03airlied: imirkin_: that should work
14:04imirkin_: airlied: i thought it didn't...
14:04airlied: I slaved hdmi and DP on nvidia from an intel
14:04imirkin_: is it "new" that it works?
14:04airlied: imirkin_: no it worked in X server 1.17
14:04imirkin_: 1.17 is pretty new
14:04airlied: to be it's ancient hitsory :-P
14:04imirkin_: hw cursors is definitely very appreciated
14:05imirkin_: rotation is a nice little cherry on top
14:05airlied: now if someone could find out why kwin still givs black windows with offload sometimes
14:05airlied: though maybe dri3 will solve that
14:05imirkin_: dri2 fail
14:05imirkin_: driN+1 will fix all those problems
14:05imirkin_: and introduce a whole lot more new ones :)
14:06imirkin_: but don't worry -- driN+2 is on its way!
14:07imirkin_: Karlton: well on the bright side, disabling compression doesn't fix things.
14:07imirkin_: i hate debugging issues like that
14:07imirkin_: of course on the down side is that i have no clue why it's having issues
14:08Karlton: imirkin_: do you remember off the top off your head what the variable is to play it using software rendering?
14:08imirkin_: it renders ok with i965
14:08imirkin_: althought it complains *very* loudly about incorrect fog
14:09imirkin_: so i suspect it's something relating to that
14:09Karlton: okay, ty
14:09imirkin_: of course fog belongs to those things i haven't the foggiest idea about
14:10imirkin_: seems to work fine with llvmpipe
14:11Karlton: it shows up when I turn Atmospheric Light Scattering on
14:12imirkin_: that sounds like fog :)
14:28kisisten: hi, i have an issue with connecting an external monitor to my laptop, as soon as I connect the external monitor the system freezes up
14:32imirkin_: kisisten: you have the nv3x right?
14:32kisisten: one sec, I can tell you the exact model
14:33imirkin_: can you ssh into the system?
14:33imirkin_: meh, don't really care about exact model
14:33kisisten: one sec I can try that also
14:33kisisten: i doubt it though
14:33imirkin_: if you can ssh in after the screens die, may be some interesting messages in dmesg
14:34kisisten: there is a some nouveau errors even without the screen
14:34kisisten:rebooting the laptop
14:36imirkin_: a lot of "errors" can be innocuous though
14:39kisisten: this is my dmesg before external monitor >>> http://pastebin.ca/3028955
14:41imirkin_: yeah, that's not strictly-speaking bad
14:42imirkin_: i should fix that error once i figure out a proper way of doing it
14:42imirkin_: apparently you can't have width=1 height > 1 render targets.
14:51kisisten: this is after I attache the external monitor >> http://pastebin.ca/index.php
14:51imirkin_: wrong link?
14:52kisisten: this should be it, ssh still works
14:52imirkin_: that's just super... looks like it goes into a loop calling the same scripts over and over :(
14:53imirkin_: can you file a bug including these logs as well as your vbios (/sys/kernel/debug/dri/0/vbios.rom)
14:54kisisten: sure, this is on debian jessie
14:54kisisten: do I fire it to debian or nouveau?
14:54imirkin_: yeah, i doubt that's related. although mention the kernel version you're using
14:55imirkin_: bugs.freedesktop.org xorg -> Driver/nouveau
14:55imirkin_: [not really an xorg issue, but there's no DRM/nouveau component]
14:56kisisten: a few more lines just came it
14:56kisisten: came in
14:58kisisten: after a few minutes of being kind of frozen, KDM resets back to the login screen
14:59imirkin_: do you get use of your 2nd screen?
15:01kisisten: meaning, do I see things there?
15:01imirkin_: actually a boot with like
15:01imirkin_: nouveau.debug=debug drm.debug=0xe would be interesting
15:02imirkin_: it won't fix anything, but would likely provide additional info
15:02kisisten: sure, it's in span more i believe, so if I boot with the screen attached, I can see both screens, I can see the KDM login screen, but when I put in the password KDE never loads to the end
15:02kisisten: it just sits there with the fancy icons
15:03imirkin_: i guess that's a little shy of perfection...
15:03imirkin_: i'm guessing the two issues are related
15:03imirkin_: kwin tries to do something that greatly upsets nouveau
15:04imirkin_: do you have compositing enabled?
15:05kisisten: sry, not sure what that means in this context
15:05imirkin_: in kwin
15:05imirkin_: there's an option
15:05imirkin_: "enable gl compositor" or something
15:05imirkin_: make sure it's disabled
15:05kisisten: in KDE settings?
15:05kisisten: one sec
15:05imirkin_: sorry, not sure exactly where or what it's called, i don't use kde
15:07kisisten: let me see if i can find it
15:07imirkin_: you want to flip to xrender
15:08kisisten: comes to think of it, i think it's default for kde i think
15:09kisisten: xrender that is
15:11kisisten: nope, it's set to OpenGL 2.0
15:12kisisten: what about Qt graphics system? Native or Raster?
15:12imirkin_: that's most unfortunate since nv3x doesn't actually expose GL 2.0, only GL 1.5
15:13imirkin_: (although it's questionable whether it couldn't easily be made to... i need to re-check what all ARB_texture_npot requires and what the hw has support for)
15:15kisisten: ok, i think I got it set to xrender, it complained about some things failing
15:18kisisten: well it's not freezing now, but I don't get the second screen either
15:18kisisten: xrandr shows two monitors but KDE shows only one
15:19imirkin_: can you pastebin xradnr output?
15:21kisisten: one sec
15:25kisisten: I'll be back, need to reconnect from the laptop in question, for some odd reason xrandr is complaining about putty
15:25imirkin_: DISPLAY=:0 xrandr
15:28kisisten: back now
15:28imirkin_: you could have done DISPLAY=:0 xrandr
15:28imirkin_: chances are the display wasn't set when you ssh'd in
15:34kisisten: hmm, now kde sees the second monitor , but it's blank now
15:34imirkin_: well it thinks that it's supplying a 1280x1024@60 mode to your monitor
15:35kisisten: that's fine, it's a 19" dell lcd
15:35kisisten: the problem is, it's not supplying anything :)
15:36kisisten: the screen is blank
15:36imirkin_: does the lcd say "no signal"?
15:36kisisten: in powersave mode
15:36kisisten: nope, it's not
15:36kisisten: the lcd is getting something, but it just sits in powersave mode
15:36imirkin_: is it literally a vga connector?
15:37kisisten: let me rboot i guess
15:37imirkin_: or is it a combo dvi connector (i.e. analog + digital)?
15:37kisisten: imirkin_: yes it is a blue vga connector
15:37kisisten: this laptop only has vga out and the lcd dell screen only a vga in
15:38imirkin_: well there's a phantom DVI-D connector
15:38imirkin_: i figured it might be a misdetected situation where it's actually a single DVI-I connector
15:38imirkin_: but i guess not
15:39kisisten: could be, it's a laptop so, the card might have a dvi also, but there is no phisical out
15:43kisisten: how can I set this up to be a mirror not a span?
15:43imirkin_: xrandr --output VGA-1 --same-as LVDS-1
15:51kisisten: thanks imirkin_
15:51kisisten: after the reboot I have both monitors working
15:51imirkin_: heh ok
15:51imirkin_: just have to reboot enough times ;)
15:51kisisten: the quetion is, what to do now, should I file a bug to nouveau maintainer in debian?
15:52imirkin_: well there are a bunch of diff issues here...
15:52imirkin_: like why does the GL compositor shit its pants
15:52kisisten: to make sure composition is set to xrender?
15:52imirkin_: well, you don't want to do that for all nouveau
15:52imirkin_: just the super-crap-old gpu's
15:53kisisten: how can I help then, do you still need me to open a bug?
15:54imirkin_: your issue is resolved
15:54imirkin_: that width/height situation thing is on my to-do list to fix
15:55imirkin_: (virtual to-do list and it's of infinite length, so...)
15:55kisisten: got you, so there should be a note somewhere, well maybe there is already, that for crap old kind please set the compositor to xrender or opengl 1.5
15:55imirkin_: you could see if debian has some sort of list like that
15:55imirkin_: check if the GL1.5 thing works
15:55kisisten: one sec
15:56kisisten: is there a difference with xrender or opengl 1.5?
15:56kisisten: i mean performance wise
15:57imirkin_: i don't use kde
15:59kisisten: sorry, thre is 3.1, 2.0 or 1.2 opengl settings
16:01imirkin_: made a card for that rt size issue: https://trello.com/c/rSkJkO0m/104-nv30-can-t-render-to-width-1-height-1
16:04imirkin_: tobijk: didn't you add OP_CVT support for constant folding? did i never push your patch??
16:06tobijk: imirkin_: uhm i added it, why it was never pushed, dunno, maybe there where outstanding issues...i really cant remember
16:06tobijk: let me dig the patch out of my pile of mess ;-)
16:08tobijk: imirkin_: https://git.thm.de/tjkl80/mesa/commit/6d4dc24fe0703454753d2f88478c661f195bce5c
16:08tobijk: it would need a rebase though
17:19imirkin: tobijk: did you at any point verify the saturate behaviour with non-float dest types?
17:20imirkin: tobijk: i know we generate such converts, but i don't remember ever personally verifying that such behaviour "worked"
17:21imirkin: tobijk: either way, i think it should be moderately simple to not have quite so much code there... i'll play with it
17:23tobijk: imirkin: mh does it get usable now in any way?
17:23tobijk: i try to remember which path would hit that
17:23imirkin: oh, there are some float->u16 conversions
17:23imirkin: which have saturate turned on
17:24imirkin: or float->u8? i forget
17:24imirkin: anyways, seems like you could easily handle it all in just 4 cases
17:24imirkin: float->float, float->int, int->float, int->int
17:25imirkin: (float to float can happen with f64, but you can't deal with an f64 dest at this point)
17:25imirkin: i guess i know what most of the constraints are, so i should just write the code
17:26imirkin: you probably feel like you're wading in a sea of arbitrary rules coming out of nowhere that i keep throwing at you :)
17:26tobijk: kind of, yeah
17:27tobijk: i found the old thread about it :D
17:29tobijk: the saturate was hit with:
17:30tobijk: uniform sampler2DArray foo;
17:30tobijk: texelFetch(foo, ivec3(1, 2, 3));
18:03briocalter: imirkin, sorry to bother you, I got the game running with the compiled mesa just fine now (was a problem on the executable script). The warnings on dmesg are gone, but I still only see garbled graphics. The earlier values that you requested are BOUND: ubo size: 100 and CONSTBUF: ubo size: 10000, dunno if still relevant