01:01 rhyskidd: cleaned up a couple of Sphinx warnings coming through on rtd
01:01 imirkin: fyi i pushed the gl compat enablement changes -- both nv50 and nvc0 should now expose the same compat and core GL versions
01:02 imirkin: i haven't checked too carefully if there are any unexpected differences between them, let me know if you encounter any compat-specific issues
01:06 imirkin: there's a slight chance that i might pick up a late-model nvidia gpu with displayport to figure out dp-mst on xf86-video-nouveau...
01:07 imirkin: which would also mean i could look into hdmi 2.0
01:07 imirkin: man, even stupid gt 1030's are expensive though :(
01:17 karolherbst: imirkin: :(
01:17 karolherbst: imirkin: do you even have a display with HDMI 2.0?
01:17 imirkin: i do
01:17 karolherbst: okay
01:17 imirkin: and i recently picked up a couple of new monitors to replace this one from 2006
01:17 karolherbst: ahh
01:18 imirkin: the hdmi 2.0 thing is a 4k tv, so should be able to test it properly
01:18 imirkin: only downside of new monitors is no more s-video / vga
01:19 imirkin: which means testing old gpu's just got harder
08:11 SmallR2002: imirkin, the intel as primary seems to massively help
10:49 Tentacles: Hey guys! does nouveau support Vulkan?
10:50 Tentacles: in particular ver 1:1.0.15-2
10:51 HdkR: No
10:51 Tentacles: :(
10:51 Tentacles: but planned?
10:51 HdkR: eh, Karol said something about thinking about it
10:52 chithead: I gues the ddx will never support vulkan anyway
10:52 Tentacles: all time I have problem with proprietary drivers Nvidia :(
10:54 Tentacles: as great Linus said, "Fuck you Nvidia"
10:54 HdkR: What problems are you having with the proprietary driver? :)
10:55 Tentacles: randomly hangs environment all except the mouse cursor
10:55 HdkR: Ah, that issue
10:55 Tentacles: and does not react to any action
10:56 Tentacles: helps only hot reboot
10:56 HdkR: You had the six monitors right?
10:57 Tentacles: no, only one
10:57 HdkR: oh
10:57 Tentacles: gtx 1060
11:00 HdkR: Pascal has issues with reclocking under Nouveau. Might not be a great experience regardless :P
11:01 HdkR: Does the environment hang when the cursor changes to a loading animation typically? There was a wacky race condition a while ago that maybe effects it...?
11:01 HdkR: Could enable the SWCursor to see if the hanging stops at least
11:02 HdkR: (and all the disgusting things that happen with SWCursor)
11:04 Tentacles: how can I check? it happens randomly, I did not find any dependencies if I could check the logs, but I'm not an expert in this
11:05 HdkR: Myself I saw the cursor change its image periodically when it would hang. Then changing to the SWCursor made the hangs go away :P
11:06 Tentacles: sort of it has not changed, just a static picture
11:07 Tentacles: not one combination of hot keys does not work at this time
11:09 Tentacles: I do not even know what to do
11:09 Tentacles: go to Windows but I do not want this
11:10 Tentacles: you do not know on BDB the same problem?
11:10 Tentacles: BSD*
11:11 Tentacles: with proprietary drivers?
11:11 HdkR: I've never run BSD to know
11:12 Tentacles: I can communicate on the job in video chat and at this time the system hangs I just go out in window
11:31 RSpliet: Tentacles: there's a couple of problems that need to be squashed before Vulkan is viable on Nouveau. I *think* some of these issues are on the various devs' todo lists, but it's a slow process as there's also Turing bring-up general quality development (plus occasional DVFS baby-steps) in the works. Nouveau is understaffed, overworked and has a learning curve a bit higher than your average OSS project (so hard to attract meaningfu
11:33 HdkR: You got cut off at "so hard to attract meaningfu"
11:35 RSpliet: meaningful contributions from fresh blood)
11:36 RSpliet: Karolherbst's NIR-to-NV50IR transformation is probably a step in the right direction (as this will make it easier to support SPIR-V encoded shaders in the future)
11:38 Tentacles: RSpliet: I'm writing a little on C ++ can I somehow get to you in team?
11:43 karolherbst: well our compiler backend is written in C++
11:45 Tentacles: karolherbst: can you give a direction where I can try start?
11:47 RSpliet: Tentacles: programming language is the least of all challenges. It's about understanding at least two of 3D rendering, computer architecture, microelectronics and compilers in the greatest possible detail. And then being proficient in C or C++ ;-)
11:49 Tentacles: RSpliet: it is impossible to master this alone?
11:50 Tentacles: I just wanted to work with Vulkan and here it is :)
12:00 Tentacles: so is problem on side of Nvidia? they do not want to work with community?
12:07 pendingchaos: imirkin, karolherbst, mwk: the current version of envysched and such can be found here: https://github.com/pendingchaos/envytools/commits/envysched
12:07 pendingchaos: I think I'll be creating a preprocessor like mwk suggested and see how that works out
12:13 HdkR: "nouveau 0000:01:00.0: unknown chipset (00000000)\nnouveau: probe of 0000:01:00.0 failed with error -12" Hm. Wonder if this kernel version 4.4 doesn't understand this GT 710
12:16 HdkR: "01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 710B] (rev a1) (prog-if 00 [VGA controller])"
12:21 karolherbst: pendingchaos: yeah, probably a good idea
12:22 karolherbst: Tentacles: currently is a bad idea to start with vulkan as we kind of have to make changes to the kernel module API and when this is settled we should already have some more or less functional vulkan library, until then I advise to wait
12:25 Tentacles: karolherbst: but approximately how soon will the support of Vulkan be achieved?
12:27 Tentacles: and I understand that when the support of Vulkan is reached, then a free driver can even compete in performance in games with proprietary?
12:27 HdkR: That's optimistic
12:28 Tentacles: but dreaming is not harmful haha
12:29 Tentacles: behind-the-scenes contracts not who did not cancel
12:32 HdkR: Obviously getting the 2080ti running in Nouveau should be higher priority than Vulkan :P
12:35 Tentacles: I just think or I need to wait for support or go to Windows for a while, free driver does not support the work Vulkan and proprietary does not work correctly it is sad
12:39 Tentacles: companies earn billions on Linux and BSD including Nvidia and can not make candy for these systems
12:46 imirkin: HdkR: unknown chipset 00000000 means something went horridly wrong
12:46 imirkin: since that's just the printout of the BOOT0 reg (i.e. mmio 0)
12:46 imirkin: SmallR2002: glad you got things going
12:47 imirkin: Tentacles: you need to get off nvidia, not wait for nouveau.
12:50 HdkR: imirkin: Ah. I guess that's because I'm on a wacky device :P
12:54 HdkR: One that its kernel configuration is probably half broken for anything connected to its pcie bus
12:58 Tentacles: imirkin: it's a problem, I did not think to upgrade my PC earlier than the 20th I think I'll wait for which GPU Intel will show us
13:01 Tentacles: and I hope that AMD will revive already processed its dual graphic
13:02 karolherbst: dual graphics have inherent issues
13:02 karolherbst: I don't think that SLI and co are relevant in the future at all
13:02 karolherbst: Tentacles: or what did you mean by dual graphic?
13:03 karolherbst: intel+AMD on laptopts?
13:03 karolherbst: *laptops?
13:03 Tentacles: AMD APU + AMD GPU together
13:04 karolherbst: ahh
13:04 karolherbst: yeah dunno, I think this only makes sense on AMD CPUs anyway
13:04 karolherbst: but is also pointless if there is no power efficiency benefit
13:04 karolherbst: you can just run the faster card slower if it makes 0 difference for power consumption
13:05 HdkR: NVLink will solve all the issues with dual-GPUs of course ;)
13:06 Tentacles: yes, something similar uses Vulkan
13:06 Tentacles: it creates a virtual device
13:07 karolherbst: vulkan doesn't create a virtual device
13:07 karolherbst: that is just how they did they API
13:07 karolherbst: and the application is doing that
13:07 karolherbst: but
13:07 karolherbst: it doesn't mean that on the driver level you have any kind of seperation
13:07 imirkin: HdkR: well, it means that the mmio read returned 0. that's a bad sign.
13:09 Tentacles: karolherbst: dual graphics has a good implementation already can look at the results of A10 7870k + R7 250
13:09 HdkR: I'll have to look at the kernel config and see if something is mangled
13:10 HdkR: Sadly I don't have any pcie devices laying about that aren't nvidia video cards
13:12 karolherbst: Tentacles: okay sure, but I was heading toward another direction. What if one GPU with the power consumption of both GPUs would be still be 1. generally faster and 2. more power efficient?
13:12 HdkR: imirkin: This is of course me plugging a video card in to a RockPro64 because I love wacky hardware mixtures :P
13:13 karolherbst: the point of having a low power GPU is to save power if you don't need it, but if big GPUs can achieve the same if they are designed carefully enough, there is no point in having two GPUs at all
13:13 karolherbst: (and basically spare you all the troubles with those dual GPU setups completly)
13:15 RSpliet: karolherbst: One of the problems is that you wouldn't be able to shut down the graphics RAM like that. It would take a lot of HW and SW engineering to be able to pull that off, as it's not just the compositors framebuffers that would have to reside in shared DRAM
13:16 RSpliet: I bet a lot of other problems could be managed with tight power management (like... actually power-gating unused SMs under desktop loads and such)
13:16 karolherbst: or having two VRAMs which can be used based on application profile or something
13:16 karolherbst: or making VRAM more power efficient when on lower clocks
13:16 karolherbst: or something
13:17 karolherbst: I am sure there are "cheaper" ways than having two GPUs
13:17 linkmauve: HdkR, like that one time when I plugged an ivb into an AArch64 qemu? :D
13:17 Tentacles: karolherbst: 2 graphics in the system is always plus for example, one I can throw in KVM
13:17 karolherbst: also it sounds like that "dual graphics" doesn't do much besides benchmarks really
13:18 Tentacles: plus compactness of the system
13:18 RSpliet: RAM requires periodic refreshes and sufficiently high voltages to maintain their load. I think that's at 1.2V right now, more than the voltage no the GPU itself.
13:18 karolherbst: Tentacles: 2 GPUs more compact than 1? how so?
13:18 Tentacles: I can also buy vidyuhu a year after the assembly of the PC and get a powerful system
13:18 karolherbst: RSpliet: yeah... allthough I think with GDDR5X stuff has changed a bit?
13:19 Tentacles: 1 GPU in APU
13:19 RSpliet: Every generation tries pushing it down further, but that tends to come at the cost of a higher refresh rate
13:19 HdkR: linkmauve: It's madness from top to bottom
13:19 linkmauve: I love it!
13:20 karolherbst: RSpliet: GDDR5X seems to have dropped the max voltage to 1.35V
13:20 karolherbst: from 1.%
13:20 karolherbst: *1.%
13:20 karolherbst: ...
13:20 karolherbst: 1.5
13:20 karolherbst: but yeah, no idea how low you can actually go
13:21 RSpliet: karolherbst: There's development, but it'll always be more than the 0V that you need to apply if you really put the GPU in it's deep sleep state:-)
13:21 karolherbst: sure
13:21 RSpliet: Another unfortunate effect is that for performance reasons, address-to-DRAM mappings try to interweave all chips as much as possible. Would've been nice to shut down some of the chips, but that goes at the cost of maximum throughput
13:21 karolherbst: mhh, maybe disabling unused VRAM parts could be a thing?
13:21 SmallR2002: Question imirkin, would it be sane/possible/stable to have my two nVidia (nouveau) cards drive most of the monitors and the intel card drive one/two? Right now I'm somewhat juggling outputs to make it work.
13:22 imirkin: SmallR2002: yeah... but the more monitors the intel gpu doesn't drive, the more laggy things will be
13:23 SmallR2002: If I had to rate the lag right now it's about the same with modesetting+nouveau as it was with nouveau+nouveau but without the total crash every few hours.
13:23 SmallR2002: I might risk it and see just for fun
13:24 RSpliet: that address-to-DRAM mapping is why it's so difficult to disable unused VRAM parts. That would have to happen on a very fine-grain level (rows), because data is spread over banks, ranks and channels as evenly as possible.
13:25 Tentacles: karolherbst: in principle one powerful APU can solve the problem but then in DRAM it is necessary to use HBM2 and there is a question with APU cooling
13:25 Tentacles: there are many other nuances
13:26 Tentacles: so that the dual graphic is a good idea but not for everyone :)
13:26 SmallR2002: Serious thanks to everyone though, stability is great for just monitoring stuff and the odd video. I don't need super performance for Steam or the like from this box.
13:27 SmallR2002: Tentacles, what about the stuff nVidia did where they used the SLI link to allow the BIOS to basically see the two GPU's as one (as I understand it)?
13:27 SmallR2002: I appreciate I am way over my depth of understanding when it comes to most of this :)
13:27 RSpliet: The real question is wherther NVIDIA could design their GPUs to shut down the entire DRAM system when you're running desktop workloads, doing everything from shared RAM (over the PCIe bus). Not the most efficient rendering, but for 3D loads where performance is key you render in VRAM. The problem is all the auxiliary structures that are kinda-standard allocated in VRAM. It's not impossible, given how Tegras exist, but it'll take s
13:29 karolherbst: yeah...
13:29 RSpliet: Although Intel is unlikely to start producing CPUs without a GPU now anyway, they want to serve the thin-and-light and mid-range market with the same chips as much as possible (because every variation on the chip will cost them a couple extra millions of development cost), and the majority of those machines don't have a discrete GPUs. So if there's an Intel GPU in the machine anyway, why bother with such a tricky engineering probl
13:29 karolherbst: but keep in mind that we always compare here intel+nvidia vs nvidia having a GPU which can fit both workloads
13:30 karolherbst: mhh, true
13:31 karolherbst: RSpliet: but imagine nvidia bringing a GPU on the market, which is more power efficient than intel on low loads and OEMs start seeling laptops with fused of intel GPUs as those reach higher battery times?
13:31 karolherbst: I could imagine that this could really stress out intel
13:31 karolherbst: as going to AMD+Nvidia wouldn't be _such_ a bad idea if AMDs gets their power efficiency problems under control on their CPUs
13:32 karolherbst: allthough with their recent CPU gens they are already close
13:32 RSpliet: Why would Intel stress about that? They sold the chip, they got their money. See if they care whether people use the GPU or not...
13:32 HdkR: 7nm should help with that :)
13:32 karolherbst: 7nm is a hoax
13:32 karolherbst: it won't come in 2019
13:33 karolherbst: Globalfoundries already said they won't do 7nm
13:33 Tentacles: the technological process has long gone into marketing
13:33 karolherbst: and TSCM has serious issues from what I've heard
13:33 karolherbst: sure
13:33 HdkR: hehe
13:34 karolherbst: but marketing is always pushing even if there is no working sample
13:34 karolherbst: 9nm was already quite a mess
13:34 karolherbst: I mean, wasn't 9nm promised and they back downed to 10nm in the end?
13:34 imirkin: less nm = more better
13:34 imirkin: otherwise what would be the point of upgrading
13:35 RSpliet: NVIDIA isn't interested in the low-end market, too little money to be made. That hypothetical super-efficient NVIDIA chip would just make the laptop more expensive for that little bit of extra battery life, unlikely that many OEMs are particularly interested.
13:35 HdkR: I'd be more interested in a higher end Intel part that was similar to Intel-G *cough*
13:35 imirkin: and if people don't upgrade, that'd make them sad.
13:36 karolherbst: allthough I guess if you ignore bad yields and production costs, you can actually do 7nm
13:36 RSpliet: Process nm indication is already watered down from what it used to be, It's the feature size of "some" component, not necessarily all of them* anymore.
13:37 karolherbst: true
13:37 RSpliet: TSMC 7nm is roughly equivalent to but a teensy weensy better than Intel 10nm
13:37 karolherbst: yeah
13:37 karolherbst: intels 10nm "Interconnect Pitch " is even smaller than the TSMC 7nm one
13:38 karolherbst: 7nm means that a single transistor is 7nm "big", right?
13:38 karolherbst: or not even that?
13:38 RSpliet: Well, there's p-mos and n-mos transistors which are of different size
13:39 Tentacles: they call it 14nm+ 12nm+ 10nm+ 7nm+ haha
13:39 RSpliet: Generally within the same chip there is a variety of different transistor sizes (roughly ranging from high perf to low power...)
13:39 RSpliet: So you can optimise your critical path for high perf, save power on the paths where there's more leeway
13:41 RSpliet: Then there's transmission gates (not sure if they're comprised of regular transistors, I presume they're slightly differently engineered), power lines, and all the other funky shit in your standard library (think capacitors, PLLs etc...)
13:42 Tentacles: and after 5 years at some of the conferences you can hear "in general, now we will release a full 14nm processor this is the first of its kind"
13:48 Tentacles: heard that Valve did not abandon the idea of making a game platform with Linux? truth looks strange
13:48 karolherbst: gabe hates windows, so yeah
13:48 karolherbst: theyr Steam linux beta ships a wine fork now to run windows games through vulkan
13:48 karolherbst: *their
13:48 Tentacles: yes
13:49 karolherbst: and you can use this for any windows game in your steam lib if you enable it and accept that some games won't work
13:49 karolherbst: windows is done for anyway
13:49 RSpliet: Like all of them on nouveau? :-P
13:49 karolherbst: or at least windows in its current form
13:49 Tentacles: and here Nvidia sticks in the wheel HAHA
13:51 linkmauve: “15:35:04 RSpliet> NVIDIA isn't interested in the low-end market, too little money to be made.”, didn’t seem to be the case with Nintendo. ^^
13:51 RSpliet: Well the other side of the story is that nouveau (and other mesa drivers) can do native DirectX 9... although I'm not sure if Steam enables that
13:51 karolherbst: RSpliet: this is boring and will pretty much die with vulkan
13:52 karolherbst: ;)
13:52 karolherbst: or maybe not, who knows
13:52 karolherbst: anyway
13:52 karolherbst: you have dx9 on vk implementations
13:52 karolherbst: you have dx10 on dx11
13:52 karolherbst: you have dx11 and dx12 on vk
13:52 karolherbst: and this all works really fast and good
13:52 karolherbst: *well
13:53 RSpliet: linkmauve: Tegras are targeted mainly at automotive, escaping their "on-board entertainment" sandbox slowly into autonomous vehicles. That's not the low-end market but the embedded market.
13:53 Tentacles: Nvidia will spoil all your plans
13:53 linkmauve: Oh, yeah, indeed.
13:53 karolherbst: Tentacles: huh? how so?
13:53 RSpliet: Selling those chips to Nintendo was cheap money, they didn't redesign anything :-)
13:53 karolherbst: RSpliet: uhm, actually they did
13:54 karolherbst: they kind of had to write all the software stuff
13:54 karolherbst: as the switch has their custom os with custom software for everything
13:54 Tentacles: karolherbst: as well as my environment hangs
13:54 karolherbst: but yeah, the hw is basically the same with a few changes
13:55 Tentacles: no drivers do not have money from games under Linux
13:55 Tentacles: multichode from MS with Nvidia
13:56 RSpliet: karolherbst: You sure? Apparently they took parts from FreeBSD and the userspace is part copy-paste from Android. I bet that took them less effort than it sounds
13:56 karolherbst: RSpliet: they have to do IPC with their push buffers
13:56 karolherbst: and have their custom switch graphics API
13:57 karolherbst: sure, you can pretty much copy most of the stuff, but still you need to write that IPC stuff
13:57 karolherbst: and apperantly they validate all the push buffers as well
13:57 karolherbst: in software
14:00 Tentacles: how are things with open hardware at desktop?
14:00 linkmauve: RSpliet, the OS is a proprietary microkernel based on the 3DS one, the parts from FreeBSD aren’t many, I do know of the socket API (the same as Windows’s ^^) but there may be more.
14:00 linkmauve: And technically everything but the kernel is in userland.
14:00 linkmauve: Armada651 would know more.
14:01 karolherbst: linkmauve: the application can't open fds on the nvidia kernel thing
14:01 RSpliet: Yeah that's common for microkernels. For a long time NVIDIAs blob already existed mainly in userland. I guess they re-used lots of their generic ARM driver...
14:01 karolherbst: linkmauve: so they have a system service the application has to do IPC with
14:01 linkmauve: Yes.
14:01 karolherbst: and that service talks with the kernel on behave of the application
14:02 karolherbst: RSpliet: the thing is, games don't link dynamicaly against the graphics lib
14:02 karolherbst: sooo
14:02 karolherbst: you kind of have to split things into that service and whatever you put into the static libs
14:03 karolherbst: you don't want to allow applications to have that much freedom, so you basically put everything important into that serivce (like push buffer validation, or maybe that's inside the kernel? dunno) and only keep that basical graphic stuff inside the application
14:04 RSpliet: Anyway, software is relatively cheap to do. 10 devs, 6 months, under half a million dollars. A dedicated chip would be multiples of that, even amortised over the 20 million-ish sold devices
14:08 Tentacles: CPU from Nvidia will be?
14:12 Tentacles: Inter makes its GPU, Apple starts to switch to their processors...
14:16 Tentacles: do not know or had problems with Polaris in the first versions of the drivers?
14:17 Tentacles: it can not be that in 2 years did not fix this bug
14:17 karolherbst: it is safe to ignore apple for any kind of "desktop" related progress anyway
14:18 Tentacles: karolherbst: you do not know open-hardware projects for desktops?
14:19 karolherbst: they won't be successful
14:19 karolherbst: as they are either super expensive or not very usefull
14:20 Tentacles: yes and China all the time has boiling plastic
14:23 Tentacles: Intel has open drivers? hope for their GPU
14:24 Tentacles: although the last APUs can be seen that the AMD head is higher than Intel in the graphics
14:26 Tentacles: although if take them Iris graphics then the difference seems to be no
15:04 Tentacles: new Iris 655 inferior to Vega 10, what do you think about the future GPU from Intel?
19:16 adya: Hi imirkin, nikk_ and I were working on the fbo-blending-formats task from trello board. Sorry for the very late response, we had our exams going on. We have shared our piglit results in a doc: https://docs.google.com/document/d/19ifBXylDF0LyrzoB06rQ7gsBqkida08__aZqVEZUNV0/edit?usp=sharing and we are unable to find RGB10X2 results in this . What would you suggest?
19:16 adya: Also we have thought of a line up of code in nvc0_state.c file, as the else condition corresponding to if(blend_en), the pseudo code of which is also in the doc. Please guide us on these! Thanks
19:22 adya: imirkin: We went through the piglit test results for nvc0 shared at 'https://people.freedesktop.org/~imirkin/nvc0-comparison/problems.html', and also ran the test case on Fermi GPU. We have a query regarding this. We are unable to reproduce the 'fbo' failure on our system. Could you please clarify why this is happening? We could really use your suggestions.
19:27 adya: imirkin: Also, as the RGBX means that the alpha channel contains a 255 value by default, does setting the DST_ALPHA value to 1 mean that the values are normalized between 0 and 1?
19:46 orbea: there is a strange issue with the libretro port of reicast (dreamcast emulator) during certain parts of soul calibur. It renders broken graphics during the intro or garbage on the screen during the startup. Its reproducable with nouveau and reported to happen on the windows nvidia blob too. However the windows intel drivers as well as the llvmpipe are unaffected. Maybe nouveau somehow supported one of
19:46 orbea: nvidia's bugs? Or is it hardware specific rather than driver? here is a small trace. http://0x0.st/st9G.xz
19:47 orbea: additionally replaying the trace with llvmpipe prints major api errors while no visual bugs, while with nouveau there is no such errors, but it shows the issue. An image can be found in this issue. https://github.com/libretro/reicast-emulator/issues/94
19:48 orbea: i suppose intel on linux is unaffected too, but I havent tested that.
21:00 karolherbst: orbea: would be nice to track down the draw which is causing this
21:00 karolherbst: maybe some alu inaccuracy where nvidia behaves differently?
21:00 karolherbst: or indeed some application bug?
21:02 karolherbst: orbea: uhm... it uses GL_NV_vertex_array_range?
21:06 karolherbst: mhh, seems to be some startup sequence though
21:08 HdkR: ew, register combiners
21:09 karolherbst: HdkR: hu?
21:11 HdkR: I just saw it throwing an error in the github issue linked
21:12 karolherbst: HdkR: yeah... I think this is just checking for features or something
21:12 karolherbst: HdkR: call number is quite low
21:13 HdkR: That sounds gross as well :P
21:13 karolherbst: right
21:13 karolherbst: because why checking extensions
21:13 karolherbst: I am sure this is some stupid issue
21:13 karolherbst: there was even this fix to "fix divide by inf"
21:15 orbea: karolherbst: yea, reicast has lot of bugs, but I found that how it was producible with only nvidia/nouveau interesting, I'll look in qapitrace to see if I find a bad draw
21:16 karolherbst: orbea: undefined behaviour
21:16 HdkR: Does it repro on the non-retro version of reicast? :)
21:16 karolherbst: or well, defined in the glsl way
21:16 karolherbst: orbea: anyway, if you tell us which draw is causing it and which shaders are bound, we could tell you what _might_ cause issues
21:17 orbea: HdkR: no idea, that one is broken last I tried
21:17 orbea: and no save states so no interest in making traces :P
21:17 HdkR: Double broken
21:24 orbea: karolherbst: not all that familiar with qapitrace, but looking at teh surfaces tab the first call with this in the textures is glBindTexture(GL_TEXTURE_2D,1)
21:30 karolherbst: orbea: the api error doesn't matter
21:30 orbea: karolherbst: is this what you mean the the shaders? http://dpaste.com/0M4K8D7.txt
21:30 karolherbst: I meant the first draw showing the wrong image
21:31 orbea: that is the first draw showing https://user-images.githubusercontent.com/11428910/42136130-5e0ae3fa-7d56-11e8-900f-205e366b4556.png
21:31 orbea: or am I looking at the wrong tab?
21:31 orbea: I am looking at the surfaces and shaders tab
21:37 orbea: karolherbst: the first call with this texture https://i.imgur.com/RJr7VhL.png
21:39 karolherbst: orbea: okay, and where was this texture generated?
21:39 orbea: what do you mean?
21:39 karolherbst: as this image just show some useless draw
21:39 karolherbst: what do you need is to find the draw sequence, which is drawing the actual result
21:40 karolherbst: there might be more draw calls doing some prep work
21:40 karolherbst: or some draw calls drawing textures
21:41 karolherbst: orbea: so "that is the first draw showing https://user-images.githubusercontent.com/11428910/42136130-5e0ae3fa-7d56-11e8-900f-205e366b4556.png" is the very first draw call doing _something_?
21:41 karolherbst: orbea: also, why is there only one frame?
21:42 karolherbst: in the trace I mean
21:42 orbea: not sure
21:42 orbea: i tried to make it short
21:42 karolherbst: don't tell me.... it just draws over the previous frame?
21:43 karolherbst: uhm glXSwapBuffersMscOML
21:43 orbea: reicast is in poor state and finally getting some attention now, so anything is possible...
21:46 karolherbst: orbea: can you verify that 12101 shows the bug, but 10519 doesn't?
21:48 orbea: checking, qapitrace froze up here...
21:51 orbea: karolherbst: seems right, lot of these calls seem to show video ram so its misleading until you try them a few times in a row
21:51 karolherbst: yeah
21:51 karolherbst: orbea: best is to check the glXSwapBuffersMscOML calls
21:51 karolherbst: and backtrack
21:52 karolherbst: usually you can just do that from the end of a frame... but without frames you need somehting else
21:57 orbea: I think 12101 is the first one is the first event that really shows it, replaying 12100 does show it if I run something else graphical first to see something else in my video ram...
21:59 orbea: 12090 seems to be the first one with the issue in the surfaces tab under Textures.
22:33 karolherbst: orbea: fun, the texture is already crap
22:33 orbea: figures...
22:34 orbea: if only reicast had devs like dolphin :P
22:34 karolherbst: call 11611 looks fun
22:36 HdkR: orbea: Did you report the issue to Stef? :)
22:36 karolherbst: mhh 11072
22:37 karolherbst: 11126 is the first bad draw
22:37 HdkR: Although he's pretty much a Windows dev only, doesn't really touch mesa
22:38 orbea: HdkR: he never fixed anything I reported to him :Shrug:
22:38 karolherbst: ohhhh
22:38 karolherbst: crap
22:38 karolherbst: depth24_stencil8 attachment is wrong
22:38 HdkR: haha. I'm probably better off than other people since I have a direct line to his ear :P
22:39 karolherbst: ohh wait, probably just unused memory
22:39 karolherbst: ahh no, this is actually the issue
22:40 orbea: HdkR: last time I talked to him I told him I can help debug better with save states, it was now someone else who implemented save states in the libretro port :P
22:40 HdkR: karolherbst: Bug driver side?
22:40 karolherbst: don't know yet
22:40 HdkR: Not many people use D24S8? :)
22:41 orbea: really, I just want to see working dreamcast emulation finally... :)
22:42 karolherbst: HdkR: I had some fixes...
22:42 karolherbst: but that was for d32fs8
22:43 karolherbst: I think d24s8 is fine actually
22:43 orbea: karolherbst: its the first bad call beacuse its the first one where the issue is shown under the Framebuffer in the Surfaces tab?
22:43 karolherbst: imirkin: do you know of anything broken regarding d24s8?
22:43 karolherbst: orbea: basically
22:43 orbea: okay, I will remember that. I'd like to know qapitrace better :)
22:44 karolherbst: this is some weird issue though
22:47 karolherbst: orbea: you see that "if (isinf(vpos.z))" code inside the vertex shader they use?
22:47 karolherbst: make the next line vpos.w = 0
22:47 karolherbst: ohh wait
22:47 karolherbst: mhh
22:47 karolherbst: new trace
22:47 karolherbst: but can you check how the output changes with that?
22:50 orbea: line 51?
22:51 karolherbst: orbea: what file?
22:51 orbea: i meant in the vertext shader
22:51 orbea: looking for the file now
22:51 karolherbst: and I have no idea from which file they actually pulled the shaders
22:51 karolherbst: yeah
22:51 karolherbst: but you need to fix it inside the sources
22:51 orbea: core/rend/gles/gles.cpp i think
22:51 karolherbst: well
22:52 karolherbst: you will find many places with the same code
22:52 karolherbst: ...
22:52 orbea: same issue for the OIT core, but that needs a 4.3 compat profile so that doesn't matter now
22:52 karolherbst: I don't know from where it gets loaded
22:52 karolherbst: you need to verify that
22:52 karolherbst: orbea: duh, it does
22:52 karolherbst: orbea: https://cgit.freedesktop.org/mesa/mesa/commit/?id=a608e5cc9fdaf459757c98d09861dd3d2f2f0f9f
22:56 orbea: my mesa is not new enough for that
22:56 orbea: basically reiast has a GL3 path, a newer GL4 path which needs a new compat profile and an older GL2 path. I'm using the GL3 one.
22:57 karolherbst: ahh, okay
23:00 orbea: i tried this and found no difference http://dpaste.com/31S8XF8.txt
23:00 orbea: i can make a new trace if you still want it?
23:00 karolherbst: mhh
23:00 karolherbst: wait, actually
23:01 karolherbst: "if (isinf(vpos.z))" -> "if (abs(vpos.z) > 1000.0)"
23:02 karolherbst: if this doesn't change anything, make it > 1.0
23:03 orbea: do you want the previous change too?
23:04 karolherbst: test both
23:04 orbea: alright
23:04 karolherbst: I just want to know what this part of the code changes
23:05 orbea: hmm that is better, but still happens a little
23:05 orbea: let me try with both changes
23:05 karolherbst: interesting
23:05 karolherbst: with > 1000.0?
23:06 orbea: yes
23:09 orbea: adding the 'vpos.w = 0' just reintroduced it and made it worse, missing/black textures
23:09 karolherbst: okay
23:09 karolherbst: sooo this is indeed the part
23:09 karolherbst: but why is 1000.0 a good threshold?
23:09 karolherbst: try with > 100.0
23:09 orbea: trying now
23:12 karolherbst: mhh
23:12 karolherbst: this just ends up being a rcp instruction call
23:12 karolherbst: I don't think this is the real cause of the issue?
23:12 orbea: 100 is about the same as as 1000, but more missing textures
23:13 karolherbst: ahh
23:13 karolherbst: okay, wait a sec
23:13 karolherbst: orbea: > 1.0e30
23:14 orbea: testing
23:18 orbea: karolherbst: best one yet, the missing textures are back and the issue in that spot is too, but still happens a bit later on in the intro.
23:18 karolherbst: orbea: reduce the exponent until it is fine, but before that, adjust the fallback result
23:19 karolherbst: 1 / 1.0e30 = 1.0e-30
23:19 karolherbst: and then reduce until it looks good
23:19 karolherbst: and if it is perfect at like 24 or so, post that patch on the issue and see what they say
23:20 karolherbst: I think the issue might be somewhere else though
23:21 karolherbst: "vpos.xy=vpos.xy*scale.xy-scale.zw; " and "vpos.xy*=vpos.w;"
23:21 karolherbst: this _might_ cause more inaccuracy later on
23:21 orbea: ah
23:22 karolherbst: well more like only vpos.xy*=vpos.w;
23:23 karolherbst: if vpos.w is quite small and vpos.xy even smaller, you might end up with 0
23:23 karolherbst: in xy
23:23 karolherbst: which should be okay though...
23:23 karolherbst: or maybe not?
23:23 karolherbst: I really don't know
23:24 orbea: I'll have to see if one of the guys working on the core know better
23:24 orbea: this gave a good starting places, thanks!
23:42 orbea: karolherbst: looks perfect with the exponent at 10
23:43 karolherbst: orbea: that is quite low actually
23:43 karolherbst: but maybe it makes sense
23:43 karolherbst: dunno
23:43 orbea: 15 was too high, I should check the ones in between