03:06 imirkin: skeggsb: weird. so it looks like something's messed up with 30bpp on GF119+. when i stick colors like 0x300 into each component it works. with 0x301 it doesn't. this leads me to believe that the bit layout is wrong. i messed around with other layouts, and ... well ... it's all a bit unclear since there's also a lut involved.
03:07 imirkin: skeggsb: GF119+ has the 1025-entry LUT that I think we should probably move to. (why is there the extra entry on all those?)
03:08 imirkin: and while we're at it, move to the "new" gamma stuff with legacy hookup. that might make some of the logic simpler as well
03:08 imirkin: and enable "reasonable" userspace to just not have a lut enabled at all
12:57 __Chris: Hello, is it the longterm plan to support real 2D EXA for nouveau instead of emulating it with glamor? Maybe some dev can make a statement to that.
15:23 rhyskidd: quick straw dev poll: any devs have cmake less that 3.5? `cmake --version` re: https://github.com/envytools/envytools/pull/114
15:30 mwk: not me
15:57 pmoreau: not me either
16:12 rhyskidd: mwk: any comments on this before i merge it to master? https://github.com/envytools/envytools/pull/114
16:13 mwk: no, ship it
16:14 rhyskidd: thanks
20:23 imirkin: tagr: do you know anything about the LUT in tegra hw?
20:24 imirkin: (i'm hoping it's similar to the one in desktop GPU display hw)
20:24 imirkin: _Chris_: were you asking about EXA earlier?
20:35 _Chris_: imirkin: Yes, right.
20:37 imirkin: _Chris_: not sure i understood your question... what's wrong with the existing DDX?
20:39 _Chris_: I like the way you think.
20:39 imirkin: e.g. https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nvc0_exa.c
20:41 _Chris_: I ask because I read about that the Nouveau project started a glamor based driver, but instead of switching completely to it, it seems nouvea cancelled it. Many other projects or distributions are all the way killing their DDX driver, just emulating 2D completely with glamor.
20:41 imirkin: dunno what you read...
20:42 imirkin: there was a short period of time where xf86-video-nouveau had a glamor-based backend in addition to the EXA one which it's had since the dawn of time
20:42 imirkin: however it was removed because the integration with glamor was broken and not seen as "worth fixing"
20:43 _Chris_: This behaviour will in long term allow the xorg project to remove EXA. They will destroy a lot of older and historical worthfull drivers like TDFX, OpenChrome, Savage, SIS and so on. I don't like that. Linux was and is about choice. At least it was 10 years ago. Now it seems all going to abstract more and more functionality, killing of old drivers, removing code. Mesa killed the old DRI1 drivers for example.
20:44 imirkin: i can't tell if you're reading my replies or not.
20:44 imirkin: anyways, if you want to complain about the directions that various distros are taking, this is not the proper forum for that.
20:44 _Chris_: I know that at some point of hardware generation at least in the Radeon series, from hardware point of view, there is only some 3D core. But for older generation the 2D functionality should be keept the EXA-way.
20:44 imirkin: you can vote with your "wallet" and just not use them
20:44 _Chris_: I have read your replies :-)
20:46 imirkin: tl;dr: nouveau has always had and continues to have an EXA backend.
20:46 _Chris_: I just wanted to share my motivation to ask this question. So nouveau project has no interest to kill EXA. That's very polite.
20:46 imirkin: projects don't have interests, people do
20:46 imirkin: i have no interest in doing it
20:46 imirkin: some others might.
20:48 imirkin: EXA of course has its own limitations. it doesn't seem like it's fixable to make it fully work with DRI3. and it doesn't accelerate (X) font rendering, as i recently found out.
20:48 _Chris_: From reading latest news I was expecting that, because of they trend to kill DDX and switch to xf86-video-modesetting universal driver. I understand what you mean. Good that this is not going on already. Thank you.
20:48 _Chris_: Why do you think it will not work with DRI3?
20:49 _Chris_: Was font rendering accelerated with XAA?
20:49 imirkin: because people with a keener understanding of this stuff than me said so
20:49 imirkin: it's unclear that there's enough communication between the EXA backend and the X clients in case that the X client is also doing direct rendering on the pixmaps
20:50 imirkin: not sure about XAA
20:50 imirkin: this recently came up in a "xterm burns a lot of CPU time" bug
20:50 imirkin: [which i had also previously observed]
20:51 _Chris_: The point is: In days when hardware is more powerfull than before, there is the question if it's worth to kill some real 2D acceleration in favor for something like font rendering in hardware. Glamor just emulates 2D with opengl from what I have read.
20:52 _Chris_: DRI3 should be able to make EXA possible in co-existence with alternatives like glamor. Just my personal point.
20:52 imirkin: glamor implements X drawing APIs on top of opengl, yes.
20:53 imirkin: "2d" and "3d" are often misnomers
20:54 _Chris_: Okay, if chips only have some 3D unit anyway, than that makes sense more or less. But I am sure you will notice a difference also in power consumption, if you don't use the 2D functions which are native of some chips. But I am no dev.
20:54 imirkin: it's a single engine in the gpu, sometimes it just has separate "apis" at the hw level
20:54 _Chris_: Ah, I see. I am just refering to something some radeon dev said.
20:54 mwk: eh, nvidia has a good chunk of 2d-only circuitry still
20:54 imirkin: in my view the benefit of the nouveau ddx is simplicity
20:54 imirkin: and stability
20:55 imirkin: it doesn't do anything fancy and is less likely to fuck things up
20:55 imirkin: mwk: G80+?
20:55 imirkin: mwk: i'm not talking NV4 here :p
20:55 _Chris_: Also I like the fact that you can seperate between mesa and DDX (2D only) still. That's something important for Unix too.
20:56 sooda: surely the 2d engine is still there, not sure how higher-level gfx apis use it though
20:56 _Chris_: I like the fact nouveau project is taking care also for chips like riva TNT. I still have some cards here.
20:56 imirkin: sooda: all part of PGRAPH though -- different class objects, same underlying hw, no?
20:57 sooda: some 2d rendering doesn't need the massive context setup that 3d does, so i'm assuming that it's different. or same hw, but something in the middle to route commands to the render hw differently
20:57 _Chris_: At least if something works, this work should be preserved. At least at long possible.
20:57 mwk: imirkin: yeah, still there on Maxwell
20:58 imirkin: ok, well i guess i dunno - i figured it was just a frontend for the hw. perhaps there's also some special hw there too.
20:58 imirkin: _Chris_: we try to. unfortunately some people have the expectation that new software should run just as well on old hardware as on new
20:58 mwk: there's a blit controller that just sits unused in 3d mode
20:58 imirkin: _Chris_: and those people end up getting disappointed.
20:59 mwk: as well as 2d rop pathways
20:59 _Chris_: Does the GF 5600Go still have some 2D circuit? That chip I have in some old Laptop. I still have this problem with kernel segfault if starting without noapic, but in all other way the nouveau driver works wonderfull for me.
21:00 mwk: probably a solid shape rasterizer too
21:00 imirkin: _Chris_: you're thinking of radeon, which starting with GCN got rid of the 2d dedicated logic
21:00 _Chris_: imirkin: Yes, but I am not stupid. I am not expecting opengl 2 or something like that with this kind of hardware. There are still people simply beeing happy about that they can work still today. With the logical limitations which are existent in 2017 with that.
21:00 imirkin: _Chris_: nvidia has some dedicated 2d logic on all of their chips so far. i just see it as more of a frontend to the underlying hw. but it's still a good chunk.
21:01 _Chris_: imirkin: Ah, yes. I am know a bit more about radeon. I was not knowing that Nvidia still has some 2D logic in the circuits.
21:01 _Chris_: So EXA makes sense to use anyway.
21:02 _Chris_: Too sad, that the mesa3d project don't seems to have some open channel. Just some dev channel which is not open for public talk.
21:04 imirkin: #dri-devel
21:04 _Chris_: I still have some CM64P card here. TNT2. Smile.
21:04 _Chris_: Right, but I can't speak public.
21:05 imirkin: register your nick.
21:05 _Chris_: Ah, that's the reason. Thank you.
21:08 _Chris_: imirkin: You are sure about that statement about GCN? I was sure it was much before.
21:08 imirkin: positive.
21:09 imirkin: r600/r700/eg/ni all have the 2d stuff.
21:09 _Chris_: Thank you. That is nice to know.
21:11 glennk: r600 and onwards is all shaders
21:13 _Chris_: That would make sense if you look at this table: https://www.x.org/wiki/RadeonFeature/ all under R600 are lacking glamor support. So what's true? :-)
21:13 glennk: the xorg _driver_ for r600 uses the exa interface, but the hardware is all shaders
21:14 _Chris_: But r600 is having EXA and glamor support. With DRI3 only glamor is working it seems.
21:23 glennk: dri3 in usable form came along after the radeon driver moved to glamor afaik so thats probably not too surprising
21:24 _Chris_: I see. So the price vendors are working torwards open source today is that these companies are ruling open source projects more or less.
21:29 glennk: i'm sorry, but that statement doesn't really parse
21:32 imirkin: glennk: erm, really? i thought pre-gcn they had 2d hw that the EXA stuff used
21:32 imirkin: glennk: was that all shader-based?
21:33 glennk: all open coded shaders
21:34 glennk: and stalls galore between draws compared to glamor
21:35 imirkin: huh, ok. that's news to me!
21:35 imirkin: will try to remember that.
21:37 _Chris_: glennk: What do you mean with "stalls galore between draws"?
21:38 imirkin: unnecessary waits for previous work to complete
21:39 _Chris_: But using glamor will translate 2D calls also to shader/opengl calls, or not?
21:39 imirkin: i think you have a simplistic view of how hardware works, and how things like GL and others are implemented.
21:40 glennk: glamor does less state transitions for the actual hardware compared to exa
21:40 glennk: so the hardware ends up spending more of its time drawing triangles vs setting up hardware register state
21:43 _Chris_: So glamor speeds up this at least for chips without dedicated 2D.
21:45 glennk: in general yes, but as always reality is more complicated, there's cases where glamor hasn't gotten around to implementing a fast path for some obscure combination of legacy xlib draw calls, where exa can still be faster
21:49 _Chris_: Would be interesting to test LLVM software rendering for opengl with a general xf86-video-modesetting driver. Emulated 2D on emulated 3d. Smile.
21:51 glennk: thats glamor with mesa llvmpipe
21:53 _Chris_: Right, llvmpipe. Does this specific combination work? Is there a generic modesetting driver now in the kernel?
21:57 glennk: i think you may be mixing up xorg modesetting which is a x ddx which uses the kernel's modesetting api to configure the displays, and the kernel modesetting implementation which is a pile of helpers and all the specific hardware drivers
22:00 _Chris_: Right Glamor can work also without KMS.
22:01 imirkin: no.
22:01 imirkin: er ... i guess yes.
22:03 glennk: i guess both answers are correct and it depends on the specific xorg driver
22:04 _Chris_: Interesting talks here.
22:04 _Chris_: At least you can use KMS without glamor.
22:16 supermart: so hello!
22:19 supermart: listen i am fed up and appearing here for kinda last times, i gonna go ahead by myself finally , i really still wanted you to belive how powerful are pointers still though, please read the fibonacci https://community.amd.com/thread/159507
22:20 supermart: i could find something similar for nvidia too though, whoever you are , please read that code through
22:21 supermart: but the catch is actually they describe on devgurus how they point 256 regs 4x64 array with single call in parallel
22:23 supermart: max is 64x64x64x4bits array
22:34 supermart: those typses of functionalities on chip are meant to backtrackingly solve all the performance problems , on any hw, it's made by taking the full control of the address space
22:36 supermart: i ain't give the code to start with, but just give clues, if you call things correctly it will perform massively well, and second clue is that it is very thin
22:36 supermart: bye