benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
gnuiyl has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
gnuiyl has joined #dri-devel
gnuiyl has quit [Read error: Connection reset by peer]
alane has quit []
alane has joined #dri-devel
gnuiyl has joined #dri-devel
sassefa has joined #dri-devel
gnuiyl has quit []
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
quantum5 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sassefa has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
neobrain has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
neobrain has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
LeviYun has joined #dri-devel
gnuiyl has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
Duke`` has joined #dri-devel
LeviYun has joined #dri-devel
bmodem has joined #dri-devel
goutersean has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<goutersean>
Well GUD could do second display connector too or clone to any of the crtc's. But i think this patent/license jam is more related to driver signing and so called HDCP hw crypto, which is to say is creapy at best or malicous event to start with, considering project ultraviolet and such. Probably cable contains a flashable controller hw under the umbrella to protect media or content. But
<goutersean>
judges they build precedences as to how they want. But the code or IR of entire program that lives in registers will without cloning dump the key in none verbatim form though with a lot of effort but laws there are missing to blame anyone who did such event in theory, however during my life i learned that judges interpret the things however they want during trials i.e from the POV of who
<goutersean>
pays more.
plutoneum has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
LeviYun has joined #dri-devel
fab has quit [Quit: fab]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
goutersean has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
travisgordon has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
warpme has joined #dri-devel
<travisgordon>
and your logs at cbrill... on desktop browsers malfunction, they display at raw logs, but on android browsers also at main logs. The theory was fundamentally approved juridically correct in practice taken from Shors work, although your guys did not develop this method, however shor himself seems fine person,but I did, your quasimodo old farts stalked people , placed bombs, threattened to
<travisgordon>
knock me down, and suicidally scared away female and male customers from travelareas. I do not have to kill them off , chain of procecution could be ordered and place them closed doors, where they get anal so bad where their asshole is size of watermelon.
sghuge has joined #dri-devel
smpl has joined #dri-devel
f11f12 has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
cascardo_ has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
benjaminl has joined #dri-devel
kts has quit [Quit: Leaving]
jfalempe has joined #dri-devel
fab has quit []
travisgordon has quit [Remote host closed the connection]
fab has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
fab has quit []
fab has joined #dri-devel
sima has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
LeviYun has joined #dri-devel
rgallaispou has joined #dri-devel
kts has joined #dri-devel
siak has joined #dri-devel
The_Company has quit []
jsa has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
LeviYun has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
impertin has joined #dri-devel
impertin has quit []
bmodem has quit [Ping timeout: 480 seconds]
kxkamil has joined #dri-devel
LeviYun has joined #dri-devel
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
LeviYun has joined #dri-devel
kts has joined #dri-devel
rasterman has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
bmodem has joined #dri-devel
coldfeet has joined #dri-devel
kts has quit [Quit: Leaving]
mripard has joined #dri-devel
karenw has joined #dri-devel
kts has joined #dri-devel
warpme has quit []
cascardo_ is now known as cascardo
pcercuei has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
karenw has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
karenw has joined #dri-devel
jsa has joined #dri-devel
kts has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
kts has quit [Quit: Leaving]
guludo has joined #dri-devel
jsa1 has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
<karenw>
Is there a "dummies guide to using libdrm" anywhere on the internet? (Dummy being relative, I know a lot of GL/VK stuff, but very little drm/dri stuff)
coldfeet has quit [Remote host closed the connection]
<karenw>
Ermine: Thanks. Ill take a look! Like most low level things, documentation is scattered about and half my problem is not knowing what questions to ask of google.
jsa1 has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
epoch101 has quit []
<Ermine>
karenw: you may want also to read mesa code and how they utilize libdrm, for rendering side of things
<bbrezillon>
zmike: nope, sorry, I'm looking at it now
<zmike>
thx
<zmike>
bbrezillon: fwiw PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY is the cap
<nano->
zmike: Hope you're the correct person. Is it possible to statically link a native macOS (non-X11) application with zink and moltenvk to gain access to higher OpenGL version with -framework Metal as the dynamically linked part? Where does the gl-prefixed function versions come from? Is there any sample project that utilizes this?
<zmike>
I have no idea
<zmike>
I know nothing about macs, sorry
<nano->
Ah, maybe the wrong zmike then :) Thought someone earlier pointed to a zmike :)
<zmike>
I'm the only one
<zmike>
but the person earlier might have assumed
jsa has joined #dri-devel
<karenw>
nano-: AFAIK you really shouldn't statically link to MoltenVK and should get it working via the vulkan loader. (I have no idea on the zink side of things though, sounds like it would work in theory, but a lot of things work in theory)
<nano->
Currently my entire app is statically linked with the help of vcpkg to avoid the bs with bundling stuff, so was hoping to keep it that way.
warpme has joined #dri-devel
<nano->
With mesa now building, in addition to libzink.a I also get a libglapi.dylib with all the gl symbols without the gl prefix which sounds a bit like loader-territory. A bit in the dark in this corner.
<nano->
Not sure what parts I need to link to, no matter if dynamic or static :)
<bbrezillon>
zmike:that one is set to 1, but it doesn't seem to be the one you're testing
<zmike>
hmmm
<bbrezillon>
you seem to test PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY now
<karenw>
nano-: By the loader I lean libvulkan.so (or whatever the equivlent of a .so is on macos). Staticly linking libvulkan is not supported. Linking directly to drivers link MoltenVK is also not supported. But "not supported" and "doesn't work" aren't the same thing so do whatever you think best. (If you need help with the moltenvk/vulkan setup side, you could pop onto the khronos discord. Although we know little about GL and Zink)
<karenw>
*drivers like
<soreau>
nano-: I have no idea about your setup but maybe you can dlopen the .dylib and look up the functions minus the prefix or something
MTCoster has left #dri-devel [#dri-devel]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MTCoster has joined #dri-devel
<travisgordon>
it really does not matter what the platform like OS for any of the drivers is, because they stuffed EGL to the kernel, where all OSes collaborated to implement it. Arguably some desktop extensions would not work where as ES would , but api translation is easy, in my world, i am underwent huge depression and have not been productive enough on this code, but it is very simple.
<travisgordon>
am/have
LeviYun has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
LeviYun has joined #dri-devel
<zmike>
bbrezillon: no, wait, the check for attrib_component_unaligned is above that
<zmike>
it is checked
warpme has quit []
davispuh has joined #dri-devel
<travisgordon>
the compression i developed is out of this world, it works very nicely, the idea was to keep the capacity of the hash hierarchies to yield invariant results of smaller weighted powers format. This puts the design of EGL based vulkan or openglES into prime position. Why angle so far does not translate this way around is ES glsl precision qualifiers being lower that of desktop GL, but
<travisgordon>
there is core exension texture float , and mixed with real code of mine that way translation is desirable, so technically it's very simple to get all vulkan opengl directx games running ontop of EGL and opengl ES or vulkan. To store a compressed format variable , there is a proof system and triple error avoidance by summing 440+443=883 adding third time index 115 to measured preallocated
<travisgordon>
power gives 26 and there is a table where linear algebra of 3 samples taken gives opportunity to eliminate one value of two previously separated, so that way millions of high precision values can be stuffed into hash and sent to display controller through a texture instruction.
vsyrjala_ is now known as vsyrjala
siak has quit []
<travisgordon>
It's just the technology is legit, but i do not want to piss off game companies, EA sports or whatever companies invest millions into gaming strategies, and it's really their choice if they want to offer their games on smartphones or not, not mine.
warpme has joined #dri-devel
<vsyrjala>
pinchartl: did list_is_null() die in a bikeshed?
LeviYun has quit [Ping timeout: 480 seconds]
<pinchartl>
vsyrjala: I think so. I still like it though
<pinchartl>
if you'd like to resurect it, please be my guest :-)
<pinchartl>
maybe it's been long enough and whoever disliked it will have forgotten their opinion
<vsyrjala>
i thought i had a use for it, but after second thought maybe not. sounds like a reasonable thing to have though
LeviYun has joined #dri-devel
<karenw>
So, if I am a normal X/Wayland application, and I want to create a drm buffer to pass to the compositor... If I understand right this can't be done in a gpu-driver agnostic way? (well, there's dumb buffers, but that looks like SHM with extra steps)
<nano->
karenw: MoltenVK build system supports static linking at least. I'll mess around with some smaller test app to get more familiar. Thanks for the comments.
<nano->
And should dig around a bit in the khronos discord as well, ty for that, didn't know of it.
travisgordon has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<Ermine>
karenw: from what I understand there's some part of GEM API which is shared among drivers, but more sophisticated stuff will be GPU-specific
<Ermine>
(And I guess that sophistication will involve rendering, which is GPU-specific anyway)
vliaskov has joined #dri-devel
<emersion>
karenw: normal X11/Wayland apps shouldn't use dumb buffers
<emersion>
dumb buffers are designed for KMS
<Ermine>
karenw: btw there's drm-memory(7) man page
chinyunming has joined #dri-devel
<karenw>
emersion: Yeah, like I said, wl_shm exists for that
<MrCooper>
karenw: what's the motivation for allocating directly from DRM, instead of from Vulkan/EGL/GBM/... ?
<karenw>
MrCooper: Purely academmic
<karenw>
*academic
<MrCooper>
then yeah, there's no generic DRM API for this
<emersion>
there are driver-specific IOCTLs to allocate GPU memory
<emersion>
it's basically what GBM/Vulkan/etc end up doing
chinyunming has quit [Remote host closed the connection]
tsygam has joined #dri-devel
<linkmauve>
What does /dev/udmabuf improve over that btw?
<MrCooper>
nothing really?
<linkmauve>
Why did it get merged then?
<MrCooper>
it's just a generic way to get a dma-buf backed by system memory
<MrCooper>
it's useful for software rendering
<linkmauve>
So exactly like dumb buffers?
<MrCooper>
except usable for APIs which require a dma-buf fd
<linkmauve>
Ok.
<emersion>
dumb buffers are not necessarily system memory
<MrCooper>
right, in fact they normally aren't if the device has local memory
<pq>
I'd even say that dumb buffers are rarely ever system memory, and can often be slow for CPU access, especially for read access. The dumb buffer memory pool may also be more limited than others.
<pq>
I think even for UMA systems, they may have different CPU caching that normal system memory?
<pq>
*than
<MrCooper>
possibly, since they're primarily intended for KMS scanout
kzd has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<karenw>
Exactly what is DRM, what is DRM-mode, what is GEM, and what is KMS all seems to blur a little the more I learn. All interlinked. :)
<Ermine>
So, all common APIs (dumb buffers, common part of GEM) can only allocate system RAM?
Calandracas__ has quit [Ping timeout: 480 seconds]
<karenw>
Seems accurate to what I know so far, with the bigg exclusion of not mentioning Wayland at all. (Also links have bitrotted, I don't think the author wanted to linux-fbdev.org to be gambling ads)
LeviYun has joined #dri-devel
edolnx_ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
<Company>
karenw: an important thing from the client side is that dmabufs are the handles that clients use to exchange references to VRAM
<Company>
both in-process between different libraries and inter-process (the Wayland example but also VMs and browsers)
<Company>
which has been a development in the last 1-2 years I think
<Company>
where it is replacing GL texture ids for in-process and shm (mostly I think) for inter-process
LeviYun has joined #dri-devel
Calandracas has joined #dri-devel
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<karenw>
But there's no device-agnostic way to create those buffers. But from e.g. a wayland compositor's pov they are device agnostic to be scanned out to the screen/composited image?
<nano->
This time around I tried to replicate https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/.github/workflows/macos.yml .. it unfortunately depends on a number of x11 things, but I'm just exploring. It first failed due to a bad include guard around dri_common.h in glxext.c which was easy enough to fix given the guards on function calls further down, but later on it fails in kopper_allocate_textures which
<nano->
calls missing loader_dri3_get_pixmap_buffer which source file is not enabled on macos. Also feels like a bad corner, I don't want x11, but I somehow want gl-prefixed functions and this configuration would produce egl according to config output which I think would do that.
<karenw>
(At least with common formats, there could be device-specific formats or modifiers but an application can only make those with consent)
LeviYun has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Company>
karenw: yes, you need some kind of device to create them - there's /dev/udmabuf these days that we recently started using in Gnome CI after llvmpipe gained support for it
karenw has quit [Remote host closed the connection]
<Company>
dj-death: I am curious about the Intel GL driver, maybe you can tell me: I did an optimization to avoid flushes to speed up llvmpipe in GTK - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7753 - and did some general benchmarking afterwards
<Company>
dj-death: and the Intel driver was one that saw absolutely no change, even though radeonsi and asahi do see slight gains. Have you guys optimized flushes so much?
gouchi has joined #dri-devel
karenw has joined #dri-devel
LeviYun has joined #dri-devel
jsa has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
aljazmc has joined #dri-devel
Haaninjo has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
vliaskov_ has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
phire_ has joined #dri-devel
phire is now known as Guest5036
phire_ is now known as phire
Guest5036 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<dj-death>
Company: not really the area I'm most familiar with
<Company>
you know who might know?
<Company>
in the end I'm just curious, it's not important in any way
<dj-death>
maybe Kayden
<dj-death>
not quite sure why uploading causes flushes tbh
gouchi has quit [Remote host closed the connection]
<dj-death>
as long as you don't read back you can keep everything pipelines
<dj-death>
pipelined
<airlied>
not sure llvmpipe handles buffer replacement that well
<Company>
no idea, that's a question for you guys
<Company>
but it benefited radeonsi and asahi, too
LeviYun has quit [Ping timeout: 480 seconds]
<Company>
this is just my attempt at replacing VkPushConstants
<dj-death>
but this is GL?
<Company>
yeah, it's my GL emulation of push constants
<dj-death>
ah okay
<dj-death>
oh yeah
<Company>
I think the original code was copied from some website where people claimed it should just work with small buffers
<dj-death>
Kayden did a bunch of work for suballocations
<dj-death>
maybe that helps
<Company>
so I was wondering if Intel maybe optimized that
<dj-death>
we suballocates 2MB buffers in Iris I think
<dj-death>
but that was for a different reason
<Company>
but I have no idea how many engines use push constants and want a GL equivalent
<Company>
because the few Vulkan people I've talked to in recent times all went "omg, don't use push constants, nobody optimizes them"
<dj-death>
huh
<dj-death>
you spoke to AMD people?
<Company>
hehe, no
<Company>
Android and GStreamer people
<dj-death>
Intel has special bits of HW for push constants
<dj-death>
it's only on DG2+ where compute/mesh/ray-tracing doesn't have it
<dj-death>
but the other stages still do
<airlied>
nobody optimises them because they are already fast :-P
<Company>
I might be looking into doing that buffer thing for Vulkan, too - maybe that speeds things up on some drivers
<Company>
airlied: in that case, maybe gallium should use them for small buffers?
<airlied>
the problem isn't the small buffers, it's the overwriting of the contents of the small buffers
<airlied>
while those contents are in use
<airlied>
I think we often try to pipeline those operations, but I'm guessing we don't always
<airlied>
the hw that is used for push constants is used by GL drivers for UBOs usuall
LeviYun has joined #dri-devel
<Company>
that is a UBO
<Lynne>
is there still no way to trigger an rgp trace for compute-only programs?
<ccr>
somehow I read that as "RGB trace" and wondered what that could be
<Company>
airlied: apparently llvmpipe doesn't spawn enough threads to make the M2 Ultra go into performance mode
<Company>
airlied: with LP_NUM_THREADS=32 on the 8 + 16 core machine, llvmpipe does 120fps instead of 80fps
<Company>
is that an llvmpipe problem or a kernel power management issue?
LeviYun has quit [Ping timeout: 480 seconds]
<jannau>
does the benchmark application take a significant amount of time for submission? i.e. is the CPU utilization of the llvmpipe threads significantly less than 100%
LeviYun has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
<airlied>
Company: likely a bit of both
glennk has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
LeviYun has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mattst88 has joined #dri-devel
jhli has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
smpl has quit [Ping timeout: 480 seconds]
<Kayden>
Company: hmm. that is a bit surprising
<Kayden>
asahi doesn't seem to have u_threaded_context unless I'm missing something
<Kayden>
iris and radeonsi both use that, and u_threaded_context has some promotion of things to async maps
<Kayden>
and automatic replacement of the backing storage when you overwrite the entire buffer
<Kayden>
iris should do that with GALLIUM_THREAD=0 too, since I'd implemented it first
LeviYun has quit [Ping timeout: 480 seconds]
<Kayden>
radeonsi has fancier buffer handling than iris - it has callbacks for detecting idle buffers and reusing objects. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18880 implemented that for iris 2 years ago but nobody ever reviewed it
<Kayden>
not sure I ever saw any improvements from it either
<Kayden>
radeonsi also has CPU-side storage for buffers in some cases, which...I remember alyssa and I looking at a few corner cases of, and being uncomfortable with the idea, so we never did it
<Kayden>
so I guess I could see the results being different between the three drivers, at any rate
<Kayden>
but yeah if you were overwriting an entire buffer object, we've long allocated new storage to avoid stalls there
<Kayden>
or even a range you had never written anything to (so the existing contents cannot matter)
<Kayden>
(in that case we'd promote to async mappings)
<Company>
makes sense
<Company>
any idea what the best emulation for vk push constants is with GL?
<Company>
in a general GL sense I mean, not specific to any drivers (or even Mesa)
<dj-death>
ubos should be promoted to push constants
LeviYun has joined #dri-devel
<Company>
yet apparently only Intel gets that right
<Company>
(or I suck at measuring, which is also a possible option, because my benchmarks are nowhere near perfect and I'm basically just looking at GALLIUM_HUD)
LeviYun has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
<Kayden>
hmm, yeah, Intel promotes UBOs to push constants
<Kayden>
but maybe others don't
<Kayden>
I know i965 did better for regular glUniforms because it had to upload them
<Kayden>
so it could just decide to go push
<Kayden>
whereas UBOs are already uploaded
LeviYun has joined #dri-devel
<Kayden>
but I don't think I'd recommend using those, they're kinda legacy and terrible
<Kayden>
not sure what other drivers do for push constants. we have a dedicated thing that pre-loads registers with data on thread spawn
sima has quit [Ping timeout: 480 seconds]
Schrostfutz__ has quit [Remote host closed the connection]
Schrostfutz__ has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
LeviYun has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
<karolherbst>
at least on nvidia none of this matters, because there are only ubos
Schrostfutz__ has quit [Remote host closed the connection]
guludo has quit [Quit: WeeChat 4.4.2]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
pcercuei has quit [Ping timeout: 480 seconds]
<Company>
karolherbst: does that mean on Vulkan I might want to use that one-buffer-for-all-globals thing, too and avoid push constants?
<karenw>
Disclaimer: I am a hobby vulkan dev and not a dri dev. My understanding is on nvidia you have UBOs which are faster than read-only SBOs, and push constants are just implemented as UBOs. On other hardware you do have push constants (small but extremely fast) but UBOs have no perf advantage over readonly SBOs.