ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<cmarcelo>
jekstrand: any progress on thinking about the volatile load_deref? one alternative for the two MRs there is to go even more specific and handle just load_deref+volatile for GCM + CSE(instr set).
<cmarcelo>
Kayden: ^
ybogdano has joined #dri-devel
iive has quit [Quit: They came for me...]
ybogdano has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
ds` has quit [Quit: ...]
ds` has joined #dri-devel
off^ has joined #dri-devel
mhenning has joined #dri-devel
yuq825 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
oneforall2 has quit [Read error: No route to host]
<HdkR>
Was hoping this would have been solved by now :(
egbert has quit [Ping timeout: 480 seconds]
egbert has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
gawin has joined #dri-devel
<dcz_>
does the vivante hardware support 2-byte textures even in principle? it should for YUV2:0:0, right?
<dcz_>
2-byte-per-pixel, that is
kts has joined #dri-devel
zx2c4 has joined #dri-devel
<zx2c4>
any clever way of getting the connector/encoder current associated with the calling console/VT?
<emersion>
what do you mean?
<emersion>
a VT is not associated with a single connector
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Company has joined #dri-devel
<haasn>
I'm trying to figure out how the VkDisplayKHR code in mesa works but I really don't understand it at all
<haasn>
It seems to get away without ever deciding on or configuring a plane?
<haasn>
the concept of 'planes' in vulkan terminology seems to just map to connectors in mesa, which is confusing
<haasn>
(and redundant with VkDisplayKHR)
<haasn>
I don't see any call to drmModeAtomicAddProperty(), nor any call to drmModeSetPlane(), nor drmModeGetPlane() or anything else related to planes
<emersion>
haasn: it uses the legacy uAPI iirc
<lynxeye>
dcz_: Vivante GPUs support all the usual 8/16/32 bit RGB formats + can directly sample from YUYV textures
<emersion>
so drmModeSetCrtc and drmModePageflip, iirc
<dcz_>
lynxeye: oh, thanks. I couldn't find a definite confirmation
<LaserEyess>
emersion: really? ... why?
<emersion>
which implicitly configures the primary plane
<emersion>
LaserEyess: some drivers don't support atomic
<haasn>
oh, I see
<emersion>
I guess?
<haasn>
emersion: is there any way to figure out which plane gets implicitly configured by this process?
<emersion>
tbh these don't support vulkan
<emersion>
I think
<haasn>
context: I want to know what formats are supported
<LaserEyess>
what is the overlap of drivers that don't support atomic but do support vulkan?
<LaserEyess>
yes ol
<emersion>
haasn: nope, it's the primary plane of the connector, always
<dcz_>
lynxeye: currently, GBM fails to create a R16 texture, I'll try to add that
<emersion>
LaserEyess: maybe amdgpu on older but not too old GPUs?
<dcz_>
*a R16 buffer
<emersion>
pretty niche
<LaserEyess>
and they'd be using VkDisplayKHR? I mean, very niche...
<emersion>
basically anything before GCN
<haasn>
emersion: what API can I use to determine the "primary plane of a connector"?
<haasn>
`drmModeConnector` doesn't seem to contain anything related to planes
<LaserEyess>
I thought pre GCN wasn't supported by amdgpu?
<emersion>
haasn: list planes, check possible_crtcs
<emersion>
filter by type
<dcz_>
lynxeye: now that I think of it, maybe I phrased the question wrong. What I'm looking for is a 16-bit depth grayscale texture as a sampler source
<haasn>
is `possible_crts` a bitfield or what?
<emersion>
sometimes a primary plane is compatible with multiple CRTCs
<emersion>
haasn: yyp
<emersion>
yup*
<emersion>
the kernel docs explain that
<haasn>
so the first plane on the list that satisfies (possible_crtcs & (1 << crtc_id)) is the primary plane?
<emersion>
but no libdrm docs
<LaserEyess>
haasn: based on this new information, I woudl say that writing a vulkan drm interop would be far, far easier than fixing mesa to use the atomic API for VkDisplayKHR
<haasn>
yeah probably
<emersion>
haasn: hm, doesn't work always
<emersion>
why do you need to know?
<emersion>
LaserEyess: why?
<haasn>
emersion: I wanted to implement vkGetPhysicalDeviceSurfaceFormats2KHR
<emersion>
haasn: oh, I see
<haasn>
or rather, I wanted to extent it to support more than just bgra8888
<LaserEyess>
emersion: first of all, would such a patch be accepted in mesa?
<emersion>
LaserEyess: I'd review it
<haasn>
so at the time of this call I need to know what formats are supported by a VkSurfaceKHR
<haasn>
a VkSurfaceKHR is already associated with a unique connector (and associated crtc)
<emersion>
haasn: I don't remember how one lists formats with the legacy uAPI
<LaserEyess>
emersion: right, but my question is more: is supporting the niche usecase of no atomic API, but vulkan support what mesa wants to support?
<haasn>
but to query the list of supported formats I need the right `uint32_t plane_index` to pass to `drmModeGetPlane`
<emersion>
maybe something under CRTCs?
<haasn>
I can't find anything else in xf86drm.h that lists formats
<haasn>
besides this call
<emersion>
LaserEyess: I'd say its fine to drop, maybe we can ask other contributors and see
<emersion>
then maybe there was no way to list formats
<haasn>
amazing :)
<haasn>
I guess my pet project is doomed until somebody else (tm) rewrites the VkDisplayKHR code to support the non-legacy API
<lynxeye>
dcz_: 16 bit per channel is a very different thing than 16bit per pixel ;)
<haasn>
and until then I suppose I agree with LaserEyess that we should stop using VkDisplayKHR
<LaserEyess>
haasn: or, you could do it in mpv
<LaserEyess>
yes
<lynxeye>
dcz_: I don't think R16 is supported for texturing.
<LaserEyess>
most of the context_drm_egl code could be reused, most likely
<LaserEyess>
you'd just have to change the egl bits to some common abstraction
<LaserEyess>
and, truthfully, I was gonna work on that because I think that's required to set --drm-format at runtime in mpv
<haasn>
fair
<haasn>
leaves open the question of how to handle HDR metadata hinting when using the vulkan code
<dcz_>
lynxeye: how can I find out? etnaviv_format.c has R16_UINT listed for "vertex + texture", but I don't know yet where that is used
<LaserEyess>
I was also going to drop the legacy uAPI in mpv because the drivers that don't support atomic are oooooooooold
<haasn>
because we now also no longer have the vulkan-based pl_swapchain
<haasn>
so maybe what we need to expose is the ability to create a fully custom pl_swapchain that is driven entirely by the user
<dcz_>
(I'm looking at mesa/src/gallium/drivers/etnaviv/etnaviv_format.c)
<haasn>
either that or we create a new abstraction on top of pl_swapchain (like ra_swapchain) but without the ra baggage
<haasn>
I guess I'm back to not caring about the issue, unfortunately
<LaserEyess>
damn
<lynxeye>
dcz_: Nope, it has R16I supported for texturing, which is a integer format. But since it's a EXT_FORMAT it will only work on GPUs with at least halti0 feature level, which is GC2000.
kts has quit [Quit: Leaving]
<dcz_>
lynxeye: I seem to have Vivante GC7000 rev 6214, is that enough to have that feature?
<dcz_>
when I tried to register the integer extension for use in the shader, I failed though
<lynxeye>
dcz_: Yes, the GPU supports the texture format, but integer support isn't hooked up in the shader compiler, yet. :/
<dcz_>
lynxeye: is this easy to hack in? I'm considering whether I should go back to patching my pixels manually for now :P
<dcz_>
also, should GBM be failing to allocate a R16 buffer? that sounds like it shouldn't be very involved to fix
rasterman has quit [Quit: Gettin' stinky!]
itoral has quit [Remote host closed the connection]
yuq8251 has left #dri-devel [#dri-devel]
apinheiro has quit [Ping timeout: 480 seconds]
<mattst88>
emersion: ah, I'll do both of those
<emersion>
cool
fxkamd has joined #dri-devel
<dcz_>
what does UNORM mean in formats? that it's converted to floats with 1 as maximum?
<tango_>
yes
<tango_>
it's converted to [0.0f, 1.0f] by dividing by dividing by the max of the bitwidth
jlawryno has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
Akari has joined #dri-devel
<dcz_>
thanks
<MrCooper>
"unsigned normalized"
<dcz_>
UNORM or I doesn't even seem encoded in fourcc codes, so when importing a dmabuf, the driver can't make the decision to reject that yet
<dcz_>
I'll move my questions to the bug tracker
<emersion>
dcz_: i think fourcc are unsigned unless specified otherwise
<MrCooper>
emersion: amdgpu supports atomic KMS with all supported GPUs, not sure it (i.e. DC) is enabled by default for Southern Islands yet though
<dcz_>
yes, but that is the data format, and there seems to be another layer of format specifiers directing usage
<emersion>
the only signed fourccs are floating point
<emersion>
MrCooper:
<emersion>
err
<emersion>
MrCooper: oh i was under the impression that DCE was used on older GPUs
<dcz_>
on my Intel GPU I use R16 but to the shader it's a float
<MrCooper>
emersion: it is, but DC supports DCE, remember :)
pendingchaos_ has joined #dri-devel
<emersion>
MrCooper: hmmmm. there's DCE-the-hardware, and DCE-the-impl-in-amdgpu, right?
<emersion>
so DCE hw is supported by atomic DC?
<MrCooper>
yes, no DCE-the-impl-in-amdgpu I know of though
<emersion>
i didn't know!
<emersion>
would be nice to have it on by default
ybogdano has joined #dri-devel
<MrCooper>
I guess you mean the non-DC display code copied from radeon
pendingchaos has quit [Ping timeout: 480 seconds]
<emersion>
right
<MrCooper>
just checked, DC still isn't enabled by default for SI or CIK, because it doesn't support some of their connector types yet
<emersion>
it's under a "dce" dir iirc
<emersion>
oh, analog iirc
<MrCooper>
the files are called dce_v<version>.c, they're in the amdgpu/ directory though
<eric_engestrom>
emersion: "the only signed fourccs are floating point" -> but they don't _use_ the sign, do they?
<eric_engestrom>
it's just a quirk of C
<MrCooper>
emersion: right, analog and LVDS
<emersion>
right, "dce" in the filename
pendingchaos has joined #dri-devel
<MrCooper>
well, all HW specific code in that directory is in files named after the HW blocks :)
pendingchaos_ has quit [Ping timeout: 480 seconds]
warpme____ has joined #dri-devel
<agd5f>
MrCooper, LVDS is working. It's just analog that is missing
<MrCooper>
agd5f: cool, the comment in amdgpu_device_asic_has_dc_support is outdated then
<agd5f>
yeah, I should fix that
<agd5f>
well, I guess it may be sort of true. I'm not sure if some of the old DP to LVDS bridge chips are supported or not
sysescool has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
sysescool_ has quit [Remote host closed the connection]
sysescool_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
xyb has joined #dri-devel
xyb has quit []
xyb has joined #dri-devel
xyb has quit []
slattann1 has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
off^ has quit [Remote host closed the connection]
elongbug has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
<zx2c4>
emersion: what i mean is i'd like to create a dumb FB over whichever terminal currently just executed my program
jkrzyszt has quit [Remote host closed the connection]
<emersion>
zx2c4: in multi-output setups, fbdev displays the terminal emulator on all outputs, mirrored
<zx2c4>
oh, interesting
<zx2c4>
so... not trivial to do i guess
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zx2c4>
currently i just take the first card in /dev/dri/card*, and then choose the first connected connector
<zx2c4>
would like that process to be somewhat more automatic
jkrzyszt has joined #dri-devel
heat has joined #dri-devel
Duke`` has joined #dri-devel
<karolherbst>
mhhh.. I we'll need a vec8/16 to vec4 lowering pass
<karolherbst>
rusticl on v3d basically runs perfectly ewll
<jenatali>
karolherbst: scalarize then vectorize?
<karolherbst>
uhhhh...
<karolherbst>
I'd rather not
<jenatali>
Fair
bgs has joined #dri-devel
<karolherbst>
just wondering if there is a quick way out or if that needs to be a new pass
<karolherbst>
it's mostly like lowering to scalar
aravind has quit [Ping timeout: 480 seconds]
<pcercuei>
I'm writing a DMABUF importer. After I create and add my (read) dma_fence to the dma_resv, can I start the device DMA process directly, or do I need to do something to make sure there is no write fence active?
<jenatali>
I think the lower to scalar pass is actually just a specialization of lower to vec size
<jenatali>
Like, in the source file I think it just uses a lower to vec size pass
<jenatali>
(not in front of a PC)
<karolherbst>
yeah and I have no idea how that stuff is even called... :D
<karolherbst>
ehh..
<karolherbst>
ohh, it's called nir_lower_io_to_scalar
<karolherbst>
right..
<karolherbst>
and nir_lower_alu_to_scalar
<karolherbst>
jenatali: it was nir_lower_alu_width
<jenatali>
Ah right
<karolherbst>
yeah okay, so that one we can probably use to lower all vec8/16 alu ops to vec4
<karolherbst>
still doesn't solve the io problem
<karolherbst>
I think I'll need it for v3d, which seems to be vec4 and zink
<jenatali>
Yeah we do io by lowering to 16-byte loads and stores (vec4 32bit) regardless of the original vec/bit size
<jenatali>
Since that's what DXIL supports, though they did add 32-byte (vec4 64bit) at one point
<karolherbst>
ahh.. right
<karolherbst>
then I guess I can just copy paste
Leopold has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<jenatali>
Heh it's a pretty messy pass...
<eric_engestrom>
we keep talking about the "amber branch" but its actual name was `staging/21.3`, not `amber`, so I've made a branch called `amber` with the stuff that was added on top of 21.3, and reset `staging/21.3` to its last release. The docs should now be clearer on that regard as well (!19507).
<eric_engestrom>
tl;dr: don't send MRs against `staging/21.3` anymore, `amber` is now the amber branch :)
<eric_engestrom>
(I have also redirected the currently in-flight MRs to the correct branch)
<illwieckz>
oh thanks, I never found that so called amber branch
<jenatali>
eric_engestrom: Good idea
<illwieckz>
there was like, no branch, no tag, no folder named amber…
<illwieckz>
ah a docs/amber.rst file had been added in september, I guess it can be updated to mention the new branch name
<illwieckz>
the Building instructions are ambiguous
<illwieckz>
I cannot guess by reading it if -Damber=true is for when building ambre branch or when building main branch
<eric_engestrom>
amber=true on amber :)
<eric_engestrom>
but I guess we should drop the option and hard-code that path on the amber branch
<illwieckz>
or make it behaves that way by default
<illwieckz>
I guess that people building amber without compat with main are even less than those building amber with compat with main (typically, distros)
<eric_engestrom>
ah right, it can be turned off to provide the old versions of gallium & vulkan drivers
<eric_engestrom>
ok, so not removing the option, but I'll post an MR to set it to `true` by default
<illwieckz>
I may have bugs to report, I haven't tried recently but in my memories it was so broken that it was almost unusable. I'll have to test with latest main to check if that's still broken.
<eric_engestrom>
if accepted I'll also update the docs on main
<illwieckz>
also in my memories nv30 had EXT_framebuffer_object but no ARB_framebuffer_object and I wondered if the later could be implemented. I'll check those again.
kts has joined #dri-devel
<gawin>
nv30 is prone to hardlocking, no idea from where it comes (super random and without errors in logs)
<ajax>
illwieckz: from the code it looks like ARB_framebuffer_object support is a function of PIPE_CAP_MIXED_FRAMEBUFFER_SIZES, which nv30_screen.c sets to false
<ajax>
which i think would be tough to work around if the hw support isn't there
swalker__ has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<illwieckz>
ah, because the nvidia driver for nv30 implements it
<illwieckz>
(requires old distro though)
<illwieckz>
(and is even more unstable than nouveau)
tzimmermann has quit [Quit: Leaving]
mvlad has quit [Remote host closed the connection]
fab has joined #dri-devel
<illwieckz>
that would be surprising if nv30 didn't have hw support while ati r300 competitor had
<illwieckz>
but on the other hand, it looks like nv30 drives both Rankine (GL 1.5) and Curie (GL 2.1)
<illwieckz>
so maybe the disablement is for Rankine?
<illwieckz>
and for some reason it was never enabled for Curie?
<jenatali>
Porting the shader to HLSL, our old compiler fails to compile it because uniformity analysis says the barrier's not in uniform control flow... but DXC compiles it fine and validates my transpiled version too
<jenatali>
Just our software rasterizer assumes the old rules
<jenatali>
Which means I get to go learn another part of their compiler stack to go fix it I guess
<jenatali>
I'm surprised llvmpipe doesn't choke on that
<jekstrand>
Ugh... Modifiers drama just gets worse... Built Mesa 22.2 (the version my system claims to have installed) and it has the right modifiers
<jekstrand>
Is Fedora carrying patches?!?
<airlied>
jekstrand: karolherbst I think had some reverts to make tegra work
<karolherbst>
airlied: yeah.. and I think it got fixed now
<airlied>
not sure why fedora is carrying them, it's against policy to have them in the tree this long
<karolherbst>
ohh right.. those patches need to be dropped now
<karolherbst>
with that MR
* jekstrand
really doesn't want to install Mesa system-wide so X11 will pick it up.
<jekstrand>
Grrr...
<karolherbst>
I can do a build later as I want to verify it on tegra anyway
<karolherbst>
(through a copr)
<airlied>
karolherbst: so we can drop them for 22.3 or did that patch go into a 22.2 release?
<jekstrand>
It's got a fixes tag
<jekstrand>
Looks like it's in 22.2.2
<Sachiel>
that's a lot of 2s
<karolherbst>
yeah.. let me try that out locally first so we don't regress tegra again, because that will only give me last minute blockers assigned to me
<jekstrand>
hehe
<karolherbst>
honestly, that already happend twice, and I'm not looking forward of that happening a third time 🙃
<jekstrand>
Well, I don't particularly like spending several hours trying to figure out why my system mesa is bonkers only to discover Fedora is carrying bogus patches. :-P
<karolherbst>
yeah.. that's on me and I totally forgot
<karolherbst>
but I am also inclined nuking the tegra driver and use kmsro, but....
<jekstrand>
But now that I know, I can start hacking blindly and hope there's a koji package for me to pull soonish.
<karolherbst>
I'll build it on a copr and let you know once it's triggered
<jenatali>
Git question: is there a way to bisect changes to a certain part of the tree only?
<karolherbst>
like a subdirectory?
<mattst88>
jenatali: yeah, git bisect ... [<paths> ...] allows you to consider only commits that touch files in <paths>
<jenatali>
Perfect, thanks
<mattst88>
git bisect start, I mean
<mattst88>
yw
<karolherbst>
sadly using that in the kernel made me traumatized, so I'll never use it again :'(
<Sachiel>
how?
<karolherbst>
everything I used it with paths, I ended up with nonsense commits
<karolherbst>
so I always had to do a full bisect afterall
<jenatali>
Trying to bisect a regression in a part of Windows, and it was hanging trying to find revisions to test because our history is insane for the whole tree
<karolherbst>
ahh yeah, the more reason to not use paths
* karolherbst
never ever will use paths on git bisect ever again
ybogdano has quit [Ping timeout: 480 seconds]
<karolherbst>
imagine you spend the entire day git bisecting your kernel to only find out it bisected to something entirely arbitrary not even removing one step in a full bisect
<agd5f>
yeah, bugs can come from surprising places
<karolherbst>
always expected the unexpected
ybogdano has joined #dri-devel
<karolherbst>
jenatali: _but_ there is a cool thing about git bisect, and that's git bisect run, which allows you to ahdn in a script which decides good/bad based on the return code
<karolherbst>
and if you mix that with compiling and handle broken build systems, it's even reliable
<jenatali>
Yeah, I don't have the time/willpower to write a script to run a Windows subtree build and test this component, I'll just do it myself
<jenatali>
Only 4 bisect steps with this subtree
<karolherbst>
ahh.. not too bad
<karolherbst>
as long as it doesn't take like 20 minutes to compile
<jenatali>
I know the regression is a change I made, it's just over the course of a large chunk of feature work, and the crash is in jitted code with no symbols, so......
<jenatali>
~5 minutes :P
<karolherbst>
you are a very luck person
<jenatali>
Eh sometimes
<karolherbst>
well at least this time
elongbug has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
lygstate has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ickle has joined #dri-devel
ickle_ has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
apinheiro has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
Guest69 is now known as frytaped
<karolherbst>
jekstrand: build is done
gouchi has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jenatali>
\o/ finally got a packaged version of WARP that fixes my issues and doesn't regress, and I can finally land !19178
<karolherbst>
nice
<karolherbst>
jenatali: also, what do we want to do about the subpass stuff from !19381 ?
<jenatali>
I'm fine with a subpass-dimension texture type
<karolherbst>
right... but what about lower_input_attachments or should we just make it work? dunno if adding subpass-dimension texture type makes all that much sense
<karolherbst>
dunno
<karolherbst>
but I can try it first and see how that goes
Haaninjo has quit [Quit: Ex-Chat]
<illwieckz>
ajax, what are the big differences between EXT_framebuffer_object and ARB_framebuffer_object that may explain a driver provides first one but not second one?
bgs has quit [Remote host closed the connection]
<airlied>
illwieckz: the cap pretty much summarises it
<airlied>
you have to be able to support different color and depth sizes
<jenatali>
karolherbst: Doesn't lower_input_attachments just convert the custom intrinsics to tex ops? But leave the var types the same?
<jenatali>
IIRC that's how we get into this mess...
<karolherbst>
mhhhhhh... probably?
<jenatali>
Our driver has special logic for still handling read-only images as textures, even though we should've converted all read-only images to textures using your nir pass, specifically because of this subpass case
<illwieckz>
do we actually know if nv30 Curie doesn't have the hardware for ARB_framebuffer_object meaning the nvidia driver would emulate it (given it is known it provides it on such hardware)?
<karolherbst>
illwieckz: caring to try out?
<illwieckz>
karolherbst, what do you mean?
<karolherbst>
I mean.. nobody probably knows this and one would have to try it
<illwieckz>
so, how I can try it? =)
<illwieckz>
I have a hardware set up and ready to test
<illwieckz>
is there any risk for the hardware?
<karolherbst>
1. own a nv30 era gpu 2. cry because nothing works
<illwieckz>
gnome-shell is completely broken on this XD
<karolherbst>
I have like 5 of them and always try them all out, because 4 of them always break randomly
<karolherbst>
not anymore!
<karolherbst>
once I got my nv4x gpu to start gnome fine, but glxgears killed it ¯\_(ツ)_/¯
<illwieckz>
so karolherbst how can I try ARB_framebuffer_object ? =)
<illwieckz>
(I've forced PIPE_CAP_MIXED_FRAMEBUFFER_SIZES to return 1 and it was not enough XD)
karolherbst_ has joined #dri-devel
karolherbst is now known as Guest381
karolherbst_ is now known as karolherbst
danilo has joined #dri-devel
Guest381 has quit [Ping timeout: 480 seconds]
dakr has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
danilo has quit [Ping timeout: 480 seconds]
dakr has joined #dri-devel
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #dri-devel
krushia_ has quit []
<jekstrand>
karolherbst: Subpass dimension texture ops make sense if drivers need to be able to detect those variables after the fact.
<illwieckz>
ajax karolherbst I'm running Unvanquished with GL 2.1 and ARB_framebuffer_object on GeForce 6150 LE (Curie, NV4E)
<jekstrand>
I think ANV does
krushia has joined #dri-devel
dakr has quit [Read error: No route to host]
dakr has joined #dri-devel
<karolherbst>
okay, nothing against adding them, it's just something which sounds like work in random places until it all works :) though maybe I really just need the types and handle the conversion functions
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Ok, looks like I may have correct modifiers via EGL now. Time to see if other stuff breaks.
<karolherbst>
have fun, I'm fighting with my jetson nano who doesn't want to finish booting :'(
<illwieckz>
with some luck the only reason why it wasn't enabled is that this driver also supports nv30 that doesn't support the feature and no one tried to enable it on nv40 before today